I think it is not a secret for anyone that all popular JavaScript engines have a similar code execution pipeline. It looks something like this. The interpreter quickly compiles JavaScript code into bytecode "on the fly". The resulting bytecode starts executing and is processed in parallel by the optimizer. The optimizer needs time for this processing, but in the end, highly optimized code can be obtained, which will work much faster. In the V8 engine, Ignition acts as the interpreter, and Turbofan acts as the optimizer. In the Chakra engine, which is used in Edge, instead of one optimizer, there are two - SimpleJIT and FullJIT. In JSC (Safari), there are three Baseline, DFG, and FTL optimizers. The specific implementation may...

From a developer's perspective, objects in JavaScript are quite flexible and understandable. We can add, remove, and modify object properties on our own. However, few people think about how objects are stored in memory and processed by JS engines. Can a developer's actions, directly or indirectly, impact performance and memory consumption? Let's try to delve into all of this in this article.

The issue of state management in React applications has always been very relevant. React itself, when it first came out, did not offer any comprehensive approaches to state management and left this task to the developers. The technical tools available were the classic component properties and the internal state of components. The standard basic concept was extremely primitive and involved storing data in the component's state. Thus, global data could be stored in the state of the top component, while more specific data could be stored in the states of lower components. The only built-in way to exchange data between components was to use component properties.

In this article, we will delve into the process of garbage collection by the V8 engine in detail. We will familiarize ourselves with the concepts of generations, Minor and Major Garbage Collections, see how objects are allocated, traced, and marked in memory. We will also explore what happens to empty spaces after cleaning and how garbage collection is performed in the background.

The Chromium engine from Google consists of a vast number of internal mechanisms, subsystems, and other engines. In this article, we will delve into the process of composing and rendering web pages directly on the screen, as well as get a little closer acquainted with the Blink engine, the composer (or, as it is also called, the content collator), and the task scheduler.

In this article, we will look at the mechanism of iterators. What they are, how to apply them and how to create your own.

In this article, we will thoroughly explore working with events, including their dispatching, capturing, bubbling and termination. Especially for this article, I have created a small interactive demo script that vividly illustrates all the phases of an event. The script will be published at the end of the article.

There is a lot of information about the strict mode. However, there are very few articles covering the full range of features of the strict mode. Therefore, I have decided to compile my own guide of all restrictions, exceptions, and differences in the execution of "strict" code from "non-strict", in full compliance with the ECMA-262 specification.

There are numerous publications on the web about the Event Loop and how it works, and new articles continue to appear on popular resources to this day. Unfortunately, not all the information provided in these materials is verified or reliable. As a result, the concept itself has become surrounded by a number of myths and speculations. Sometimes, even experienced developers require a great deal of attention and experience to discern the truth from pure fiction. In this article, let's attempt to determine where the truth lies.

Gone are the days when developers wrote Frontend in "pure" JavaScript (up to ECMAScript 5). Everything changed with the release of ECMAScript 6 in 2015. A year earlier, in 2014, Microsoft published TypeScript 1.0. It's been a long time since then. Both languages developed in parallel. In some ways they are similar, in some ways they are radically different. Each developer and each team is free to decide which one to use. In this article, we will try to find the points of intersection and divergence of these two languages and compare their approaches.