DEV Community: Dmitry Shatokhin

When changes are too expensive: JavaScript and data change performance.

Dmitry Shatokhin — Mon, 02 Oct 2023 02:35:27 +0000

Approaches to data processing and manipulation remain one of the key aspects of software development.
Immunability, reactivity, and mutability are key strategies in data state management, and choosing between them can significantly affect application performance.,

In JavaScript, the importance of choosing an approach to data processing is closely related to the features of this language and the scope of its application. JavaScript is primarily used to develop the client side of web applications, where performance is a key factor. The user experience directly depends on how quickly and efficiently the application processes and displays data.

Immunability in JavaScript can be quite expensive. Every time the state changes, a new object is created, which leads to increased memory usage and load on the garbage collector. In a language with dynamic typing and automatic memory management, such operations can affect performance significantly more than, for example, in languages with static typing and manual memory management.

In front-end JavaScript, the problem of immunability is getting worse. The user interface often requires a lot of state updates, which in the case of immutability can lead to the creation of a large number of objects and, accordingly, to an increased load on the processor and memory. Such resource costs in the context of a browser, where available resources are usually limited, can lead to lower performance and a worse user experience.

Nevertheless, despite its "cost", immutability continues to be popular in the JavaScript world. One example is the Redux state management library, where immunability is used to ensure predictability and simplify tracking of state changes. Immunability can facilitate the development process by providing clear and unambiguous rules for changing the state, which can be very valuable in complex applications with a large number of interdependencies.

And what about the mutable approach? For example - MobX. This library is regarded by many as an analogue of Redux, but from the camp of a mutable approach. However, you can often hear that Redux has more performance than MobX, which contradicts what we talked about. After all, in a mutable approach, we simply change the value in memory.

For example, I wrote 2 versions of a simple React application. One using Redux, the other with MobX. In all other respects, they are completely identical. The application is a background counter that is updated 1 time per second. A button that changes color by hover. And a simulation of sending N files to the server. When sending information changes, it should be updated in the interface. Sending occurs asynchronously and starts at different times for everyone, with random file size. This application lacks a complex interface and so on, but it demonstrates well the user's need to use the application while something is being done in the background (I will provide access to each application at the end of the article).

Here is the result when sending 50 files.

There are no differences in performance here. The main counter changes 1 time per second. The color change and text highlighting are triggered. Updating information is not lagging.

When sending 100 files, the lags are already noticeable.

When sending 500 files, the application can no longer be used, and it makes no sense to test with a larger number of files.

If you look to measure the execution time of the update function, it turns out that Redux is really faster than MobX. But with the increase in the number of files, this difference is greatly reduced.

It turns out that mutability is no faster than immunability? What is the point of realizing that an application with MobX works faster than the same application with Redux, if both of them cannot be used?
In fact, MobX has tried to combine reactivity and mutability and performs too many calculations for this. In MobX, a state change can cause side effects in other parts of the application through mechanisms such as observables and reactions. This means that when a state changes (mutates), all parts of the system that depend on this state automatically react to these changes. In addition, the observer function imposes additional costs and in console or server JavaScript - MobX will be more productive than in the frontend.

Then how to make it better? How to make sure that our application does not lag, and we can send 500 files without harm?

Let's take into account the development environment, in our case, JavaScript. Many argue for immutability, and they have valid points. However, it is foolish to disregard the impact it has on performance in JavaScript. Therefore, it may not be the optimal solution to the problem.
And the problem is a safe state with a clear data flow.
Mutability - does not guarantee that some value in the code will be accidentally redefined, etc. And it's true. But JavaScript is a language that actively uses mutability within itself. It turns out there is a way to track changes in entities. This method is a Proxy. Proxy is used to define user behaviors on objects and allows you to create various types of traps for objects. But MobX uses a Proxy! Yes, but with reservations. Let's just say Proxy is used there more for other things than for state control.
Libraries for state management are often regarded as a place where you need to shove all the business logic. From this, the vector of the library's purpose shifts from the original one - state management.

Before proceeding to the details of what should be taken into account in the state management library in the first place, let's look at another example of an application we know, but with a different library. Statemanjs.

50 files.

100 files.

500 files.

Even 1000 files without lags.

And only when sending 5000 files there are lags, and then because of React. Nevertheless, even with lags, the application can still be used, unlike Redux and MobX when sending 500 files.

Is this some kind of lite version of MobX? So it's even less secure and functional?
This is not a lite version of MobX and with MobX, statemanjs - binds only Proxy. But Proxy is used here in a radically different way. More native to the language itself. Providing monitoring and security of the condition.
Statemanjs uses the concept of references for reading, and you can change the state only with built-in methods. This makes it predictable, secure and, as we have seen, faster.
I will not talk in detail about statemanjs. You can read the official documentation - Link, there are also benchmarks and comparison with other state management libraries. In this article, I wanted to draw your attention to how important it is to understand the design of the development environment. Data structures and data modification methods.

Thank you all and have a good coding!

redux codesanbox
mobx codesanbox
statemanjs codesanbox

Efficient State Management in JavaScript Apps with Statemanjs

Dmitry Shatokhin — Thu, 12 Jan 2023 01:04:48 +0000

When developing JavaScript applications, it is important to consider its limitations such as the lack of thread support, single-threaded execution model, limited support for large numbers and high-precision arithmetic etc. These limitations can narrow the scope of the language, but it remains the premier language in modern web development. As web applications become more complex, developers may encounter performance issues. There are various ways to optimize a web application, but one aspect to consider is state management.

State management is a critical aspect of building modern JavaScript applications. It allows developers to manage and manipulate the data that drives their applications, and helps ensure that the application is reliable, scalable, and maintainable. There are many state management libraries available, each with its own set of features, trade-offs, and limitations. In this article, we will focus on Statemanjs, a framework-agnostic state management library for JavaScript and Node.js applications. We will explore the key features and benefits of Statemanjs, and I explain why it is the best choice for state management in JavaScript applications.
But first, let's see which approaches of state management we have.

Approaches to state management:

There are several approaches to state management in JavaScript - immutable, reactive, and mutable. Each with its own set of benefits and limitations.

Immutable approach: The immutable approach involves creating new copies of the state whenever it is updated, rather than modifying the state directly. This can provide a higher level of security and reliability, as it prevents accidental or unauthorized changes to the state. However, the immutable approach can be inefficient in JavaScript due to the single-threaded execution model and event loop.

Reactive approach: The reactive approach involves defining dependencies between state updates and automatically re-executing updates when the dependencies change. The reactive approach may be slower in other cases, and it can be more complex to learn and use than other approaches.

Mutable approach: The mutable approach involves updating the state directly, rather than creating new state copies or tracking dependencies. This can be faster and more efficient than the immutable or reactive approaches, and it can be simpler to understand and implement. However, the mutable approach may provide a lower level of security and reliability, as it allows developers to modify the state directly.

Quick Overview:

Statemanjs is a framework-agnostic state management library for JavaScript and Node.js applications. It is written in TypeScript, which provides excellent support out of the box, and it has a tiny size, less than 80 KB (unpacked).

Statemanjs uses a mutable approach to state management with read-only state links, and strict API for interacting with state. Let's dive deeper.

Performance:

One of the main benefits of Statemanjs is its superior performance compared to other state management libraries. Statemanjs uses a mutable approach to state management, which updates the state directly and avoids the overhead of creating new state copies or tracking dependencies. This can make Statemanjs faster and more efficient than libraries that use immutable or reactive approaches, such as Redux or MobX.

To benchmark the performance of these libraries, we used a test case that involves adding n elements to an array a certain number of times - x. The element is an object {foo: "bar", baz: "qux"}. Between iterations, the storage (i.e., the array) is reset to an empty array.
For example: if n = 5 and x = 2, that means to add 5 elements 2 times (iteration).
The average value for iterations is calculated and written as the result.

In this benchmark, Statemanjs consistently outperforms both Redux and MobX. For example, with n = 100000 and x = 10, the results are:

Lib	Res (ms)
Redux	2354867.223542001
MobX	4473.258667119965
Statemanjs	279.83934087000785

As you can see, Statemanjs is more than 8,000 times faster than Redux and nearly 16 times faster than MobX in this benchmark. With larger numbers of elements or more complex update logic, the performance difference between Statemanjs and other libraries becomes even more pronounced.

For example, with n = 50000000 (50 million elements) and x = 1 (1 iteration), both Redux and MobX fail to complete the benchmark after more than 6 hours of execution, while Statemanjs completes the benchmark in just 14499.883542001247ms (14.5 seconds).

Simplicity:

In addition to its superior performance, Statemanjs is also simpler to understand and use than other state management libraries. It has a clear and strict API, with just seven methods for interacting with the state: set, get, subscribe, unsubscribeAll, getActiveSubscribersCount, unwrap and update. These methods allow developers to set and retrieve the state, subscribe to state changes, and update the state in a controlled and reliable manner. Statemanjs also offers read-only state links, which provide restricted access to the state and prevent accidental or unauthorized changes.

This simple and straightforward API can make it easier for developers to learn and use Statemanjs, especially if they are new to state management or have limited experience with other libraries. It also allows developers to focus on the core logic of their applications, rather than spending time learning complex APIs or writing boilerplate code.

Scalability:

Statemanjs is highly scalable and suitable for both small and large projects. It can handle a wide range of state types, from primitives to complex and multidimensional objects, and it is easy to use with any front-end framework, including React, Vue, and Svelte. Statemanjs also has a small package size, with no dependencies and a footprint of less than 80 KB (unpacked), which makes it easy to include in any project without bloating the application.

In addition to its scalability, Statemanjs also has excellent support for TypeScript out of the box. This can make it easier for developers to write and maintain type-safe code, and can help reduce the risk of errors and bugs in their applications.

Reliability:

Statemanjs also offers a high level of security and reliability compared to other state management libraries. Its strict API and read-only state links prevent accidental or unauthorized changes to the state, and its mutable approach ensures that state updates are fast and efficient. These features can help developers build more reliable and maintainable applications, and can reduce the risk of errors and bugs in their code.

By default, the state references are read-only, and you can only change the state using API methods.

Simple demo

This is the demo with TypeScript:

import { createState } from "@persevie/statemanjs";

type TransferElement = {
    speed: number;
    info: string;
    error?: string;
};

// Create a new state with initial value { speed: 0, info: "" }
const transferState: = createState<TransferElement>({ speed: 0, info: "" });

// Subscribe to state changes and log the updated state
const unsubscribe = transferState.subscribe((state) => {
  console.log("State updated:", state);
});

// Update the state to { speed: 50, info: "Transfer in progress" }
transferState.update((state) => {
  state.speed = 50;
  state.info = "Transfer in progress";
});

// Get the current state
const currentState = transferState.get();
console.log("Current state:", currentState);

// Unsubscribe from state updates
unsubscribe();

// Subscribe to state changes, but only log the updated state if the error
transferState.subscribe(
  (state) => {
    console.log("An error occurred:", state.error);
  },
  {
    notifyCondition: (state) => {
      state.error !== undefined;
    },
  },
);

// Set (create new object and replace old) the state to { speed: 0, info: "Ooops...", error: "Internet connection" }
transferState.set({
  speed: 0;
  info: "Ooops...",
  error: Internet connection,
});

console.log("Active subscribers count:", transferState.getActiveSubscribersCount());

// Remove all subscribers
transferState.unsubscribeAll();

console.log("Active subscribers count after unsubscribe:", transferState.getActiveSubscribersCount());

// Output:
// "State updated: { speed: 50, info: "Transfer in progress" }"
// "Current state: { speed: 50, info: "Transfer in progress" }"
// "An error occurred: "Internet connection""
// "Active subscribers count: 1"
// "Active subscribers count after unsubscribe: 0"

Conclusion:

In conclusion, Statemanjs is an excellent choice for state management in JavaScript applications. Its superior performance, simplicity, scalability, and reliability make it a standout among other state management libraries, and it is well-suited for a wide range of projects and frameworks. If you are looking for a powerful and efficient state management library for your JavaScript application, Statemanjs is a top choice.

Statemanjs GitHub link

Statemanjs-react GitHub link

Statemanjs-vue GitHub link

Statemanjs-solid GitHub link

Browser, DOM, JavaScript. Everything you need to know to build effective web-apps. Part one - Browser.

Dmitry Shatokhin — Sun, 14 Jun 2020 15:15:42 +0000

Initially I planned to write only about DOM and even wrote the first article. But I came to the conclusion that in order to fully understand some of the concepts, I need to touch a little bit on how the browser works. Then I decided - Why "a little"? Maybe no? That's what I've decided.
Now my article about DOM is this second article in the series. It's just like in Star Wars :)
In this article I will consider those basic things of browser work, which are most important for web developers.

How it all started

I'm not going to go into that, but to understand the context, I'll tell you a little bit about it. In the mid-90s, there were so-called "browser wars". Each company, in addition to its HTML, had its own versions of DOM and browser engines until W3C obliged all companies to standardize technology. A common standard has not yet been achieved, which is why we have to create cross-browser versions of web applications.

REMARK
Browser engine != Browser.
Often, the browser engine is equated with the browser. But that's not really true. All the engine does is parset and display the content. The browser, on the other hand, performs much more, more complex tasks. However, it is the different engine that makes us support all sites.

Browser architecture scheme

Okay, how does it all work?

While it's running, the browser runs several processes.

REMARK
The computer program itself is just a passive sequence of instructions. While the process is the direct execution of these instructions. The process can generate other processes as well as threads that share the resources of the parent process.

Since in this article we consider the browser in the context of web development, we are interested only in one process - rendering process.

IDEA
Maybe in the future, I'll take a closer look at the browser work.

For each tab, the browser launches this process. Moreover, modern browsers also run the rendering process for each iframe. This is done in order to isolate each tab and iframe. And if any child process fails, kill it, not the main process. It's called site isolation.
The rendering process runs threads. We will only consider the main thread. Almost all the work in the rendering process is done by browser engines.
The main engines at the moment are:

Blink.
Gecko
WebKit

REMARK

During development, you should also consider EdgeHTML, but soon Microsoft will completely abandon it.

Now let's take a look at what happens when drawing a page.

this is a simplified model

First of all, resources (HTML and CSS) are parsed and converted to object trees. They are combined and another tree is constructed based on them - the render tree. This tree contains only those elements that will be drawn on the screen.

REMARK
An element with the style display: none - will not be contained in this tree. Because the element does not have its own visual representation.

After that, a walk through this tree to calculate their size and location on the screen. This process is called layout (or flow in Firefox).

Then, all calculated elements are drawn onto the screen.

Let us dwell on each point.

HTML parsing.

Many parsers are based on context free grammar, which allows them to work very efficiently. But the main problem with parsing HTML is that it cannot be defined usingcontext free grammar. This is because the browser needs to keep track of how HTML is written. If the tag is not closed somewhere, then the browser will close it and so on. Even if you do not make mistakes, this feature slows down parsing very much.

Another important feature of HTML parsing is how it reacts when it encounters the <script>tag. Parsing stops until the script is executed and only after that continues to work. This is why you should place scripts before the </body> tag or use async and defer. async anddefer - allow loading scripts in parallel with parsing.

REMARK
defer differs in that it guarantees the execution order.

It should be noted that if there are very large scripts, the browser starts to allocate separate streams and tries to optimize the download.

A similar situation occurs when the parser encounters CSS. Style loading blocks parsing.

CSS parsing.

CSS parsing is free of such problems as when parsing HTML and, in principle, is no different.

Attachment

At this point, the render tree` begins to be constructed.

Layout (Flow)

After the render tree is formed, the position and geometric dimensions of the elements of this tree are calculated.

The speed of layout directly depends on the quality of the CSS you wrote.

What does it mean?

This means that each CSS rule needs to be applied to a separate DOM node. This is achieved by recursively traversing the HTML tree, another tree - the CSS tree. And the more difficult it is to write CSS, the longer it will take.

CSS - selectors are not equal in performance.
The most productive are: #(id), .(Class) Slightly less productive - type(for ex. - h1)
Combinations of attributes are not productive, and the most not productive are pseudo elements.

REMARK
There are various css methodologies which are based on productive selectors.

Painting

Here the image is constructed and sent to the GPU to draw it onto the screen.

that's how the layout process goes

REMARK
source

In browsers, in devtools you can enable a mode that will show the rendering of elements.

Conclusion

We examined the main points of the browser. In some of the following articles, we will touch upon a few more interesting points.

Afterword.

Thank you very much for your attention. I hope it was useful for you 🙏
Follow me, it makes me write new articles 😌
I'd be happy for your feedback.
C u! 😉

Browser, DOM, JavaScript. Everything you need to know to build effective web-apps. Part two - DOM.

Dmitry Shatokhin — Fri, 05 Jun 2020 22:03:09 +0000

Hi 👋
This article will talk about the DOM. This is the second article in the series.

DOM tree.

DOM(Document Object Model) is a software interface for HTML, XML and SVG documents. It provides a structured view of the document(tree) as a group of nodes and objects that have properties and methods, and defines the way in which the structure can be accessed by the program.
DOM binds web pages to scripts or programming languages.

The basis of an HTML document is tags.
According to the DOM, an HTML tag is an object and nested tags are its "children".
All objects are available with JavaScript, we can use them to modify the page.
For example, document.body is an object for the <body> tag.

REMARK
JavaScript is not part of DOM, even though it(JS) is most commonly used.

DOM example.

This is a typical HTML page:

<!DOCTYPE HTML>
<html>
<head>
  <title>About DOM</title>
</head>
<body>
  DOM...
</body>
</html>

And this is a view of an HTML document as a tag tree:

html
    head
        #text
        title
             #text "About DOM"
        #text
    #text
    body
        #text "DOM..."

Tags are node elements(elements). They form the structure of the tree: <html> is the root node, <head> and <body> its child nodes, etc.

Text inside the elements forms text nodes named #text. The text node contains only a string of text. It cannot have descendants (it is always at the lowest level).
Spaces and line breaks are also symbols. Like letters and numbers, they form text nodes and become part of the DOM tree.

REMARK

Spaces and line breaks before the <head> tag are ignored;

There are no characters after </body> tag. Anything written after this tag is moved to the end of the <body> tag according to the DOM specification;

Everything written before <head> tag is moved inside <body>.

Everything written in HTML is also in the DOM tree, even comments.

Remark
Comments is also a DOM tree node.

In this example, there are no text nodes created by spaces and line breaks:

<!DOCTYPE HTML>
<html><head><title>About DOM</title></head><body>DOM...</body></html>

REMARK
One of the reasons why minimized(single-line) code works faster.

Building a DOM.

When building a DOM, the browser automatically fixes incorrectly written HTML. For example, if a file contains only the word world, the browser will add all the necessary tags. The DOM will look like this:

html
    head
    body
        #text "world"

REMARK
For short, I don't take text nodes from spaces and line breaks into account.

REMARK
Also the browser closes all unclosed tags. But I strongly recommend closing them.

Other nodes.

There are 12 DOM nodes:

But most often only 4 of them are used: document, elements, text nodes, comments.

Here - you can see the DOM model in real time.

In the next article I will talk about shadow and virtual DOM. Don't miss it!

Afterword.

Thank you very much for your attention. I hope it was useful for you 🙏
Follow me, it makes me write new articles 😌
I'd be happy for your feedback.
C u! 😉

A small collection of useful React hooks.

Dmitry Shatokhin — Fri, 29 May 2020 20:50:28 +0000

I often have to find different implementations of the same things in projects. I singled out for myself the most common and leave links to ready-made solutions.

REMARK
This is not a typical article. Now I support the project on React and have encountered this. So I decided to share

useFetch

useFetch - Fetch API in the implementation of the hook.

useApi

useApi - Same as useFetch, only made with axios.

useWindowScrollPosition

useWindowScrollPosition - Helps to track the position of the cursor.

useLocalStorage

useLocalStorage - Various operations with local storage.

useDocumentTitle

useDocumentTitle - Allows you to set the title of the document.

useOnlineStatus

useOnlineStatus - Check the status of the network.

useClippy

useClippy - Adding to the clipboard.

useScript

useScript - Allows you to dynamically download external scripts.

Afterword.

Thank you very much for your attention. I hope it was useful for you 🙏
Follow me, it makes me write new articles 😌
I'd be happy for your feedback.
C u! 😉