JavaScript *

I'm Ivan Kopenkov, a senior front-end developer at Mail.ru Cloud Solutions. In this article, I will tell you about the approaches we have used for the UI library components customization. You will also learn how to significantly decrease bundle size, cutting off all the unnecessary modules Ant Design takes there.

In our case, we are making wrappers for original Ant Design components inside the project, changing their appearance, and developing their logic. At the same time, we import both customized and original components right from the ant-design module. That saves tree shaking functionality and makes complex library components use our wrappers instead of original nested elements.

If you are already or about to use Ant Design, this article will provide you with a better and more effective way to do so. Even if you have chosen another UI library, you might be able to implement these ideas.

UPD: When we posted this article, Uncle Bob had our conferences in his schedule. Unfortunately, the situation has changed. We updated this post on March 12, to avoid any misunderstanding.

inb4: This is not another "setting up" a new project with Vue and TypeScript tutorial. Let's do some deep dive into more complex topics!

typescript is awesome. Vue is awesome. No doubt, that a lot of people try to bundle them together. But, due to different reasons, it is hard to really type your Vue app. Let's find out what are the problems and what can be done to solve them (or at least minimize the impact).

From time to time, developers need to establish communication between several browser tabs to be able to send messages from one tab to another and receive responses. We have also faced this need at some point.

Some solutions already exist (like, for instance, BroadcastChannel API). However, its browser support leaves a lot to be desired, so we decided to use our own library. When the library was ready, that functionality was no longer required. Nevertheless, another task emerged: communication between an iframe and the main window.

On closer examination, it turned out that two-thirds of the library would not have to be changed — only some code refactoring was necessary. The library is a communication PROTOCOL that can work with text data. It can be applied in all cases in which text is transferred, such as iframes, window.open, worker, browser tabs or WebSocket.

How it works

Currently, the protocol has two functions: sending messages and subscription to events. Any message in the protocol is a data object. For us, the main field in that object is type, which tells us what kind of message it is. The type field is an enum with the following values:

In this article, I decided to describe how the functionality of selecting and displaying photos on a specific place on the map was implemented in our photo service gfranq.com. The photo service does not work now.

Since we had a lot of photos in our service and sending requests to database every time the viewport changes was too resource-intensive, it was logical to divide the map into several areas that contain information about the retrieved data. For obvious reasons, these areas have rectangular shape (although hexagonal grid was considered too). As the areas become more spherical at large scales, elements of spherical geometry and tools for it were also considered.

In this article, the following issues were raised:

• Storing and retrieving photos from the database and caching them on the server (SQL, C#, ASP.NET).
• Downloading necessary photos on the client side and saving them to the client cache (JavaScript).
• Recalculation of photos that must be hidden or shown when the viewport changes.
• Elements of spherical geometry.

With the appearance of ECMAScript 2015, an avalanche of features came; some of them make you mad, and others are pleasant surprises, like meeting an old friend after a long time.

Some features are related to metaprogramming. What is that? I'm not very eloquent, so let's turn to our friend, Wikipedia.

In 2013, while working at GFRANQ photo service, I participated in the development of an eponymous web service for publishing and processing photos. Filters and transformations were defined in the file with parameters, and all processing was carried out on the server. During service development, there was a need to support these transformations on the client side for the preview. According to Larry Wall, one of the virtues of a programmer is laziness. Therefore, as truly lazy programmers, we thought about the possibility of using the same code on both the server and client sides. The entire development was conducted in C#. After researching the libraries and a couple of attempts, we proudly concluded that this was possible and began to write the universal code.

Why is this article needed? Indeed, 6 years have passed since 2013, and many technologies have lost their relevance, for example, Script#. On the other hand, new ones have appeared. For example, Bridge.NET or Blazor based on the fancy WebAssembly.

Nevertheless, some ideas can still be used. In this article I tried to describe them as detailed as possible. I hope that the mention of Silverlight and Flash will cause a smile with a hint of nostalgia, and not a desire to criticize the old solutions. Anyway, they have contributed to the development of the web industry.

I am Shalitha Suranga from Sri Lanka. I started Neutralinojs project with other two members as our research project at university.

Cross-platform application development is extremely useful among software development organizations because a large end-user audience can be targeted. Earlier there were several approaches, such as writing multiple codebases per each platform, writing a single codebase using conditionals for platform selection, or using a programming language which has a cross-platform virtual machine at run-time. There were drawbacks of each like complexity of design, limited low-level accessibility and slow learning rate. Cross-platform application development with web technologies came [1] after. Electron and NW.js are most popular frameworks which allow developers to make cross-platform applications using Javascript. Basically, these popular frameworks combine embedded chromium browser and node run-time [2], [3].

These frameworks are being used to create numerous cross-platform applications. Whereas the community pointed out several unseen drawbacks of these frameworks. Large bundled application size, high memory consumption and long development workflow are the key things which were criticized through internet forums and websites [4], [5], [6], [7], [8]. Table 1.1 shows the advantages and disadvantages of Electron/NW.js.

Table 1.1: Advantages and Disadvantages of Electron/NW,js

When React.js 16.8 was released we got the opportunity to use React Hooks. Hooks make us able to write fully-functional components using functions. We can use all React.js features and do in in more convenient way.

A lot of people don't agree with Hooks conception. In this article I'd like to tell about some important advantages React Hooks give you and why we need to write with Hooks.

I will not talk about how to use hooks. It is not very important for the examples. If you want to read something on this topic, you can use official documentation. Also, if this topic will be interesting for you, I will write more about Hooks.