Forem: Aleksandrovich Dmitrii

Is Tailwind actually slow?

Aleksandrovich Dmitrii — Sun, 07 Dec 2025 06:00:00 +0000

Tailwind managed to conquer the hearts of many developers and at the same time become the most despised CSS framework for many others. People love and hate it for a variety of reasons, but today I want to talk about TailwindCSS performance. Some skeptical developers believe that Tailwind can negatively affect loading and rendering times. But does it?

In this article, I want to address the following allegations:

“Tailwind may negatively affect the rendering time.”: Too many atomic CSS classes may cause additional CPU load.
"Tailwind may negatively affect the loading time.": It is not efficient lazy-loading-wise.
"Tailwind may negatively affect website cache.":
- The size of generated HTML files is usually larger with Tailwind;
- Generated CSS file may reset its cache much more often with Tailwind compared to BEM or CSS Modules.

A quick remark. Some problems that many developers attribute to Tailwind are actually problems of using the atomic styling approach. Tailwind does profess it, but you are not bound to use it only this way. In Tailwind you can also create components, which are good examples of non-atomic styling.

However, many developers use this tool just for atomic styling. And even in its documentation, Tailwind first encourages developers to use ‘multi-cursor editing’ to update repeated styles fast and then talks about using components. Hereby, I will talk about Tailwind problems from the perspective of using the atomic approach only.

Tailwind may negatively affect the rendering time

Why do some developers believe so? The common understanding is that the more CSS declarations you have, the slower the browser may process them. In the atomic styling approach, most declarations contain only 1-3 CSS rules, and in order to achieve required styling developers are forced to use a relatively large number of classes.

For example, to “center a div” using flex box, we can use 3 class names from Tailwind: flex, items-center, and justify-center. Each will generate a separate style declaration.

That’s not the case in the non-atomic approach. Using CSS Modules or BEM, we could create a single CSS declaration containing all three rules.

To test this utterance’s veracity, I decided to set up a benchmark.

Create 2 sites: one is based on Tailwind, and another on CSS modules;
Both display around 5K components, 20K DOM nodes in total.
Each component has its own unique class name(s). Some styles are repeated among components, most of them not.
Both sites have the same visual styling. All the CSS rules have the same specificity. The size of CSS files is the same for both sites (1.4 MB).
In total, for Tailwind, 35K style declarations were generated, and for CSS modules, there were 10K style declarations.

Here’s an example of what a component looks like. JSX is used just for better readability. In reality, no framework was used in the benchmark.

// Tailwind Component, the value in braces [] is different for each of 5000 components
//  In addition, classnames 'underline', 'overline', 'line-through', 'no-underline', 'truncate', 'text-ellipsis', and 'text-clip', were used for some components
<article className="mt-[0.0px] mb-[0.0px] pt-[0.0px] pb-[0.0px] leading-[0.0px] z-[0] [&>header]:flex [&>header]:gap-[0.0px]">
  <header>
    <h2>Heading</h2>
  </header>
</article>

// CSS Modules Component, className is different for each of the 5000 components
<article className="egTxNhojHMGgAu4egvUQ">
  <header>
    <h2>Heading 0</h2>
  </header>
</article>

// the number of px is different for each component
.egTxNhojHMGgAu4egvUQ{
  // repeats the same styling as Tailwind
}

.egTxNhojHMGgAu4egvUQ>header{
  // repeats the same styling as Tailwind
}

The number of components is the same, so is the size of the CSS file. The only thing I am going to measure is how much the sole fact that the number of style declarations is 3.5 times greater may affect website's performance.

Alright, the difference is 3.5 times or 25,000 declarations. We surely will notice a drastic performance difference, won’t we? Let's measure how much time a browser may take to render a page. We will not take loading time into consideration and will only measure the parsing duration after the files are downloaded.

Chrome rendered the Tailwind site in 169 ms vs. CSS modules in 121 ms (28% slower).
Safari rendered the Tailwind site in 406 ms vs. 272 ms for Modules (33% slower).
Firefox rendered Tailwind in 114 ms vs. 82 ms for Modules (25% slower).

Well, that’s quite a difference. But before jumping to conclusions, let's do something extra. You may have noticed that the className in the Tailwind component is considerably longer than in the CSS modules one. Which leads to generating considerably larger HTML: 1.1 MB vs. 0.4 MB. Is there a chance that the size of HTML affects the results? Let’s try generating HTML of the same size by increasing the length of CSS modules class names.

// Tailwind Component
<article className="mt-[0.0px] mb-[0.0px] pt-[0.0px] pb-[0.0px] leading-[0.0px] z-[0] [&>header]:flex [&>header]:gap-[0.0px]" />

// CSS Modules Component
<article className="a-----------------------------------------------------------------------------------egTxNhojHMGgAu4egvUQ" />

Now, the size of HTML will be the same: 1.1MB. However, in such a case, the size of the CSS file for the CSS Modules assembly becomes significantly larger compared to the Tailwind CSS file: 2.7 MB vs. 1.4 MB. Will such a change make Tailwind faster than CSS modules?

And the answer is simple: "No". Just the length of class names adds a couple of milliseconds, but doesn't change the picture drastically. Even if the size of the HTML file is the same, even if the size of the CSS Modules' CSS file is twice as large as Tailwind CSS file, the sheer difference in the number of CSS declarations will result in the rendering time to be longer.

We can conclude that using Tailwind and the atomic approach in general may in fact affect rendering performance negatively. However! This benchmark of mine is not 100% realistic, is it.

The problem is not with the atomic approach itself, rather with the huge number of style declarations. And if you use Tailwind and only use its class names for general problems, you will not have such problems.

For example, you can add a margin of mt-1, mt-2, mt-3, mt-6, or mt-8, using Tailwind, but if for some reason you need to add a margin like mt-[7px], mt-128, or other unique number of pixels, it's better not to use Tailwind.
The same goes for other arbitrary syntax, like [&>header]:flex. The probability you will reuse such class name is always super low. And therefore it's better to avoid using such classes.

📌 Using Tailwind and the atomic approach may in fact affect rendering performance negatively. But only if you use Tailwind incorrectly. As long as you are not defining unique classnames using arbitrary syntax, you are safe.

Tailwind may negatively affect the loading time

Tailwind is designed in a way of not relying on lazy loading. If you have a page that can be loaded lazily, and you declare its styles using Tailwind, all the styles will be included in the initially loaded CSS file. If you have 100 lazy loaded pages, all the styles of 100 pages will be included into the initially loaded css files. And that's not the case for CSS modules or BEM.

Initially loaded files are the most important in the user's perspective. And it is extremely important to handle your lazy loading properly. You can read my series of articles to understand why: How to make your app indefinitely lazy: The Ultimate Guide

To illustrate the problem, let’s do a small benchmark. I will extrapolate the previous example and create 2 extra similar lazy-loaded pages and make all of them have their own unique styles.

// Page 1 components
<article className="mt-[0.0px] mb-[0.0px] pt-[0.0px] pb-[0.0px] leading-[0.0px] z-[0] [&>header]:flex [&>header]:gap-[0.0px]" />

// Page 2 components
<article className="mt-[0.00rem] mb-[0.00rem] pt-[0.00rem] pb-[0.00rem] leading-[0.00rem] z-[0] [&>header]:flex [&>header]:gap-[0.00rem]" />

// Page 3 components
<article className="mt-[0.0em] mb-[0.0em] pt-[0.0em] pb-[0.0em] leading-[0.0em] z-[0] [&>header]:flex [&>header]:gap-[0.0em]" />

With the example above:

Assembly with Tailwind generates 1 CSS file with the size of 3.9 MB
Assembly with CSS Modules generates 3 CSS files, each with the size of 1.4 MB.

Not only the size of the Tailwind CSS file will be downloaded 3 times slower, the browser will take more time to parse all the style declarations.

However, again, this problem only appears if you are missing Tailwind and are creating too many unique class names. As long as you stick to using the most general class names, even if you use up to 200 of them, the difference in loading time will be negligible.

📌 Misusing Tailwind and the atomic approach may in fact affect initial loading time negatively.

Tailwind may negatively affect website cache

There are 2 things I want to talk about here. First thing first, HTML.

Tailwind generates larger HTML

Files like JavaScript, CSS, SVG, fonts, they all might become decently cached, if you set up NginX for your static files. There are also a few caveats on how to make JavaScript files more cacheable beyond just using NginX, and you can read Part 3 of my Ultimate Guide to understand how to make them as cacheable as possible. But with HTML, it's different.

We can't just apply an aggressive cache strategy for the HTML file. HTML file is the main entry point to our website. If the file itself is taken from the cache, the entire application will be taken from it. Can you imagine you've fixed a bug, but the user cannot see the fix because they are still using the old version of the website?

Another problem is that if you are using SSR, sometimes using cache for HTML is not possible. For example, if your application is highly cautious about security, caching pages that contain personal data, might be risky. Also, misusing cache may affect your SEO optimizations.

Knowing that, developers who do work with SSR (Server-Side Rendering) or SSG (Static Site Generation) tend to be cautious about HTML cache. They often make cache time span as little as possible, and sometimes don't use any HTML cache at all.

It means that we cannot rely on HTML cache's when it comes to the loading time. And therefore, the only thing we can do to make HTML load faster, is to make the file shorter.

Now, what's the problem with Tailwind? Tailwind encourages developers to use the atomic approach, making each component contain many class names, quite often dozens of them. Just compare these 2 implementations of a button with the same styles:

// Tailwind
<button className="transition-all bg-blue-500 text-white py-1 px-2 rounded hover:bg-blue-600 focus:outline-none focus:ring-2 focus:ring-blue-500 cursor-pointer active:relative active:top-[1px]" />

// CSS modules, by default the class name is 20 characters long
<button className={styles.button} />

In the Tailwind implementation, the length of the class name might be 20 times longer. Now, imagine such a button is used 100 times on a page. And now imagine, every component on the page, has a class name that is 2-20 times longer. Tailwind may in fact generate a significantly large HTML file.

You may object by saying that we can use components in Tailwind. And that is true. But I don't know a single developer who does that, AND as I mentioned, Tailwind itself encourages developers to use the atomic approach. And if you do follow this recommendation, you should be aware:

📌 If your website uses SSR or SSG, using Tailwind CSS may result in longer HTML files, which may result in longer initial loading time.

Tailwind reduces cacheability of initial CSS files

I did mention that with Tailwind, all the Tailwind class names will be included into the initial CSS file. That means that if you start to use a new Tailwind class name, your initial CSS file will update its content. And every time a static file updates its content, we need to reset its cache in order for the browser to be able to download it.

It means that every update on your website may result in cache to be lost, which may make your initial loading time to increase.

Even if you don't use arbitrary class names, and only apply Tailwind for general styling, there's a good chance you will be adding new class names from time to time. And each time you do that, the cache of the initial CSS file will be lost.

And I'm sorry about promoting my lazy loading series again, but cache is a huge topic. It would be better if you read the 3rd part of my series to better understand on why the cache needs to be reset. And to better understand on why in fact for Tailwind it's not that big a deal.

Yes, when using Tailwind, your initial CSS file is predisposed to lose its cache often. But so are initial JavaScript files. Regardless of what change you make, initial JavaScript files will lose their cache too. And here's the thing. If a single initially loaded file loses its cache, the initial loading time increases significantly. But if 2 of them lose their cache, they will be downloaded in parallel, and the loading time will not suffer as drastically.

Knowing that, we can conclude that it's actually not that scary that Tailwind may result in your initial cache to be reset. Unless, you care about how much data users are spending to download your site. 99% of projects don't, but I do know a few cases, where developers try to make their applications work in conditions, where users are forced to use 2g Internet connection. If you are working on one of such projects, you must be aware of this problem.

📌 Tailwind generated CSS files are predisposed to lose their cache more often compared to CSS modules files. However, if you don't care about extreme cases when users use extremely slow Internet connection, you shouldn't care about this problem, because initial JavaScript files lose their case even more often.

Can using Tailwind be justified, performance wise?

I'd say yes. Objectively, Tailwind, or it's better to say the atomic approach, does have some problems with performance. Realistically, unless you really care about every tiny bit of performance optimizations, the problems it has are not that crucual.

I know projects, that have strong performance requirements, with millions users a day, tremendous beautiful projects. And such projects probably should not stick to using the atomic approach.

Although, using Tailwind might be beneficial too. Tailwind is good in providing general styling. The more it is general, the better Tailwind good at it. Thus, if you define most of your styles using CSS Modules, and limit use of Tailwind in utility classes only, you can even improve the performance of your application. For example, if a component just need margin or flex styles, Tailwind could be treated as a good fit. And in other cases you could use CSS Modules. And with such an approach, when you combine Tailwind and CSS modules, you can reduce the number of style declarations. Which will improve loading and rendering time.

But in the end, for most of the projects, it's more of the preference question. Even if you do misuse it, the impact for small or medium size projects will be small.

Alright, that's it. Thank you for reading. You are welcome to leave a comment if you have any question.

Here are my social links: LinkedIn Telegram GitHub. See you ✌️

How to make your app indefinitely lazy – Part 4: Preload in Advance

Aleksandrovich Dmitrii — Wed, 15 Oct 2025 08:31:47 +0000

Well, hello there! And welcome to part 4 of my ultimate guide! Brace yourself, because you are about to become a real pro.

⏱️ Reading time: ~15-22 minutes
🎓 Level: Intermediate+

Series Contents:

How to make your app indefinitely lazy – Part 1: Why lazy loading is important
How to make your app indefinitely lazy – Part 2: Dependency Graphs
How to make your app indefinitely lazy – Part 3: Vendors and Cache
How to make your app indefinitely lazy – Part 4: Preload in Advance

Earlier we talked about how to improve our project cacheability and correctly load vendors. And in this article, we will cover the following:

How we can utilize prefetching/preloading strategies, including:
- What Webpack magic comments are and how they can help us;
- What is speculative or manual prefetching and how to use it;
How can we request data from server without waiting for our static files to be downloaded.
As well as what third-party or our own solutions can be used for that.

Utilize magic comments

By now, we should have a good understanding of how to split our chunks efficiently and optimize the size and number of loaded files. But does it mean we optimized loading time to the maximum? Not quite. There's still room for improvement.

Imagine this scenario: you've split your app as much as possible, optimized your dependency tree, and separated your vendors. You open your website, and the initial loading time is significantly reduced, this is great! But when you navigate to a lazy-loaded page, the browser still takes some time to load it.

ℹ️ Lazy loading simply postpones the latency of loading the application.

If a component isn't used, we save time.

But if it is used, the latency happens somewhen later.

Despite this disadvantage, lazy loading is still a good optimization strategy for all the reasons I've already mentioned in this series. But we can make this strategy even better if we eliminate this delay. In order to do that, we can preload or prefetch our lazy chunks. And one of the ways to do that is utilizing Webpack's magic comments.

What are those? Throughout the article, you might have noticed that Webpack generated files named "Chapter1.chunk.js" and "Chapter2.chunk.js". These "Chapter1" and "Chapter2" bits were generated solely due to the reason I used a special "magic" comment - webpackChunkName. It doesn't affect the actual logic of our application, and it only affects the names of generated files.

const Chapter2 = React.lazy(
  () => import(/* webpackChunkName: "Chapter2" */ './pages/chapter-2/Chapter2')
);

There are actually a lot of magic comments and I recommend you take some time to investigate them in Webpack's documentation. But for the sake of this article, we will be regarding only webpackPrefetch and webpackPreload. Both of these comments will affect our assembly in a way so javascript files will automatically add <link rel="prefetch"> (or "preload") elements to the document.

const Chapter2  = React.lazy(
  () => import(/* webpackPrefetch: true */ './pages/chapter-2/Chapter2')
);

When we use these comments, we tell the browser that we want to preload chunks of our application, even if they are not currently executed. And there is some difference between using prefetch and preload.

Prefetch features

When using prefetch, the browser will request our files with the lowest priority. It will try to request these files in idle mode, i.e. when other files are not being downloaded. Also, the browser will not waste resources on parsing these files. After downloading the file using prefetch, the browser will save it to the cache.

If we add webpackPrefetch for Chapter2 and open Chapter1, we will see that the browser will download chunks to display both of these pages. However, prefetched files will have a text/javascript type, not script. This is due to the fact that the browser is not trying to parse these files.

If we have already preloaded files using prefetch, and we are trying to open the Chapter2 page, the browser will make another request for it to download Chapter2 files. However, this time the files will be taken from the cache. And the browser will only spend time parsing these files.

Thus, we have eliminated the very delay that we discussed at the beginning of the article.

You may also have noticed that Chapter 2 is mostly loaded at the same time as Chapter 1, which may be perceived as a violation of the "idle-only request". However, this is not the case. The browser is capable of downloading multiple files at the same time. And when it sees that it has the capacity, it can start preloading the file even if other files are already loaded.

Preload features

The situation with preload is slightly different:

The browser will download files with high priority. In the previous screenshots, you can see that by default, executable files are downloaded with a low priority, so the browser may prioritize preload files over executable ones.
Also, preloaded files will be downloaded with the script type, i.e. the browser will parse them immediately.
However, webpackPreload does not work when using it in entry files. But we won't go into that in detail in this article.

Using prefetch and preload can significantly improve the performance of our website, and at the same time, the UX. However, incorrect configuration of these directives can also lead to performance degradation.

The topic of using preload and prefetch is relatively extensive in itself. To fully understand the risks of misapplication of these directives, you need to:

understand the difference between HTTP/1.1, HTTP/2 and HTTP/3 protocols;
understand how the resource manager works in browsers and understand how they download files with different priorities (lowest, low, high, highest);
in high-loaded projects, it is also necessary to take into account the volume of traffic and the cost of using CDN services.
and also understand some other minor aspects.

In this article, we will not go into the details of these directives. However, I plan to write a separate article covering all these issues later. And I'll attach a link to it in this block when I do that. But still, I will slightly touch on the topic of what can be dangerous with excessive use of prefetch and preload.

In the Webpack documentation, the official recommendation is to use prefetch and preload exclusively for critical resources of our projects. For example, we can use prefetch for frequently used lazy pages, but we shouldn't use it for rarely used modal windows.

Excessive use of preload

The worst thing we can do is to configure the use of preload incorrectly. As I mentioned, preloaded scripts are loaded with high priority, while executable scripts are loaded with low priority by default. This means that by default, the browser prioritizes downloading the preloaded file over the executable ones.

Here is an example of how the browser will download files if we open the Chapter1 page, but use preload for the Chapter2 page. Despite the fact that chapter1.chunk.js is needed to display the page, the browser will download chapter2.chunk.js first, and only then will the download of chapter1.chunk.js begin. Thus, we added the use of preload to our site, but significantly degraded the loading speed for the Chapter1 page.

To give you a real world case of this problem, I'll tell you about one of my projects. I was working on a micro frontend application in which multiple applications had to be displayed on one page. Some MFE applications were less important than others in terms of business value. But because one less important application incorrectly configured its preload, the browser first performed 120 requests (yes, all with preload) and downloaded 11 MB of files before starting to download the more important application. This led to significant delays for users with poor internet connections, especially when they were using a VPN.

Of course, my case looks like an exaggeration beyond the pale, and in most projects such serious problems cannot arise. But, as you have seen, even in a tiny pet project, we managed to decrease performance by being careless.

Excessive use of prefetch

With prefetch, everything is not so terrible in terms of the loading time. Since the priority of downloading prefetched files is lowest, the browser will prioritize executable files over prefetch files. However, due to the presence of a resource manager in the browser, even the lowest-priority files may slightly interfere with downloading low-priority files.

The key difference between preload and prefetch is that in preload, the browser first downloads absolutely all the files that we specified to preload. And in prefetch, if some files have already started downloading, the browser will download them first, then download the executable files, and then it can continue prefetching the remaining prefetch files.

However, again, the download speed is only part of the problem. Therefore, try to be careful when using both prefetch and preload.

📌 Use Webpack prefetching and downloading for mission-critical chunks of your application. But do not overdo it, so as not to lower the performance of your site.

Speculative/Manual preloading

However, we can still improve it even further. First of all, even if we do use Webpack's prefetch, React will still briefly show Suspense's fallback while retrieving files from cache and parsing them. Just for a tiny bit of moment. This delay is not significant, but the visual * blink * is not ideal UX-wise. On top of that, we still need some strategy for non-critical chunks.

What we can do is try to predict (or speculate) when a component will be used based on user's actions and download it manually. And we can be really creative about it. Here's what I do in my current project:

When a user hovers their mouse over a link, we manually preload all the files for displaying the page this link leads to.
- As a matter of fact, this is the most basic strategy of speculative preloading, and some frameworks (e.g. NextJS) provide such an optimization by default.
When a user hovers over a button, or focuses on it with a keyboard, a modal window or a side sheet might be downloaded.
Some elements are loaded based on scrolling and observing when the elements enter the visible part of the site for the user.
Also, on my website there's a search bar, which leads to different pages, depending on the request the user provides. And while the user specifies their request, I already try to download the page the user might be interested in.
And there's more. I hope you got the idea.

The only drawback of this approach is that: if we consider using speculative manual preloading, we need to preload every single component manually. Which adds additional time into the development process. But don't be scared of it. Most of speculative preloading scenarios can be automized. And those that can't are still easy to introduce and maintain.

The solution is easy

Here's a HOC we can use instead of React.lazy. It is very short: just 20 lines of code. Mostly this code is just a wrapper around lazy, and it only provides the new static preload method. And this small piece of code is already sufficient for you to start using speculative preloading.

lazyWithPreloading.tsx

export type LazyPreloadableComponent<T> = NamedExoticComponent<T> & {
  preload: () => Promise<void>;
};

export const lazyWithPreload = <T,>(
  request: () => Promise<{ default: ComponentType<T> }>,
  config: TConfig = {},
): LazyPreloadableComponent<T> => {
  const ReactLazyComponent = lazy(request);
  let PreloadedComponent: ComponentType<T> | undefined;

  const Component = memo((props: T) => {
    const ComponentToRender = useRef(PreloadedComponent ?? ReactLazyComponent).current;
    return <ComponentToRender {...(props as any)} />;
  }) as unknown as LazyPreloadableComponent<T>;

  Component.preload = async () => {
    await request().then((module) => {
      PreloadedComponent = module.default;
    });
  };

  return Component;
};

Recently, I wasn't working with SSR applications much, so I don't feel any need to use full-fledged third-party solutions to load my components lazily. But if you do have an SSR application or you just don't want to copy a paste this 20-line-long piece of code, you can use a third-party solution. Such are @loadable/component or just react-lazy-with-preload.

And this is how could use it in App.tsx:

App.tsx

const Chapter2 = lazyWithPreload(
  () => import(
    /* webpackChunkName: "Chapter2" */
    /* webpackPrefetch: true */
    './pages/chapter-2/Chapter2'
  )
);

const Chapter1 = lazyWithPreload(
  () => import(/* webpackChunkName: "Chapter1" */ './pages/chapter-1/Chapter1')
);

export const App = () => (
  <HashRouter>
    <span className="loaded-at">
      Loading time: {loadedAt}ms
    </span>

    <nav className="navigation">
      <ul>
        <li><Link to="/">Title</Link></li>
        <li><Link to="/chapter-1" onMouseMove={() => Chapter1.preload()}>Chapter 1</Link></li>
        <li><Link to="/chapter-2" onMouseMove={() => Chapter2.preload()}>Chapter 2</Link></li>
      </ul>
    </nav>

    <Suspense fallback="Loading main...">
      <div className="book-grid">
        <Routes>
          <Route path="/" element={<Title />} />
          <Route path="/chapter-1" element={<Chapter1 />} />
          <Route path="/chapter-2" element={<Chapter2 />} />
        </Routes>
      </div>
    </Suspense>
  </HashRouter>
);

Now, whenever a user hovers over any of these links, the page will be downloaded manually. And when a user clicks on the link, there's a good chance that the page will be displayed instantly.

📌 Try preloading your lazy components manually, based on user interactions.

If we use speculative preloading, it does not mean that we should abandon the use of prefetch. These strategies complement each other. However, considering how dangerous preload can be, I personally try to avoid using it.

ℹ️ With a combination of Webpack's prefetch and manual preloading, we can seemingly display our components like they are not lazy at all, which resolved the only drawback lazy loading has.

How to reduce manual labour

As I already mentioned, we can automize some of the speculative preloading scenarios. For example, buttons that open modal windows or links that open pages may appear anywhere in the app. And instead of manually add the call of preload each time we use these components, we can conceal such logic inside these components.

export const ButtonWithModal = (props) => {
  const [isOpen, setIsOpen] = useState(false);

  return (
     <>
       <Button
         onMouseOver={() => ModalLazy.preload()}
         onFocus={() => ModalLazy.preload()}
         onClick={() => setIsOpen(true)}
         {...props}
       >
         Open window
       </Button>

       {isOpen && <ModalLazy {...} />)
     </>
  );
};

import { RoutePathToComponentMap } from '../somewhere';

export const Link = (props) => {
  const page = RoutePathToComponentMap[props.href];

  return (
    <a
      {...props}
      onMouseOver={() => page?.preload()}
      onFocus={() => page?.preload()}
    />
  )
};

Preload the data, not just files

So far, we've been discussing how to optimize lazy loading of static files. But real applications usually also rely on server data. In the component approach, it is considered good practice to call the API from the component which needs it. Like this:

Chapter1.tsx + API request

export default () => {
  const { data, isLoading } = useApi<{}, { ping: 'pong' }>('POST', '/api/data');

  return (
    <>
      <section className="page">
        <h2 style={{ margin: 'auto' }}>Chapter 2</h2>
      </section>

      {isLoading ? <section className="page">Loading...</section> : <Content data={data} />}
    </>
  );
}

It is an okay approach, although it has a major flaw. The data will be requested only after the chunks for displaying the page are downloaded.

However, we can do better. We can request data without waiting for the lazy chunk. And to make it possible, the code responsible for the API request must be stored in the initial chunk. It's easy. Just instead of calling the API in Chapter1.tsx, we can make this component to take the data as a prop.

Chapter1.tsx + API data as a prop

type Props = {
  requestData: { data?: { ping: 'pong' }, isLoading: boolean };
}

export default ({ requestData }: Props) => {
  const { data, isLoading } = requestData;

  return (
    <>
      <section className="page">
        <h2 style={{ margin: 'auto' }}>Chapter 1</h2>
      </section>

      {isLoading ? <section className="page">Loading...</section> : <Content data={data} />}
    </>
  );
}

You may have noticed that the content of Chapter1.tsx stayed almost the same: we changed only 1 line of code, so such the approach is mostly harmless DX-wise. The only question is where should we request data then.

We could request it in the App component, but it would be a violation of the component approach, which we also don't want to do. But what can we do in this case?

And there are actually various ways to request it. I like to use my own solution: a wrapper on top of lazyWithPreload, which is itself is wrapper on top of React.lazy.

Own solution HOC: lazyWithPreloadAndPrefetch.tsx

export const lazyWithPreloadAndPrefetch = <T, Props>(
  request: () => Promise<{ default: ComponentType<T> }>,
  {
    usePrefetch,
    ...config
  }: TConfig & {
    usePrefetch: (props: Props) => T;
  },
): LazyPreloadableComponent<Props> => {
  const LazyComponent = lazyWithPreload(request, config);

  const Component = memo((props: Props) => {
    // eslint-disable-next-line @typescript-eslint/no-explicit-any
    return <LazyComponent {...(usePrefetch(props) as any)} />;
  }) as unknown as LazyPreloadableComponent<unknown>;

  Component.preload = LazyComponent.preload;

  return Component;
};

I couldn't find a convenient third-party solution for Client Rendered Applications. However, there are solutions for loading data on the server side using SSR or React Server Components. And I'd like to talk about them too, they're not really about lazy loading, and they're going to inflate the series even more. But for the sake of decency, I'll give you an example of how to preload data using @loadable/component.

const Chapter1Lazy = lazyWithPreloadAndPrefetch(
  () => import(/* webpackChunkName: "Chapter1" */ /* webpackPrefetch: true */ './pages/chapter-1/Chapter1'), {
    usePrefetch: () => {
      const requestData = useApi<{}, { ping: 'pong' }>('POST', '/api/data');

      return { requestData };
    },
  });

// or

import loadable from '@loadable/component';

const Chapter1Lazy = loadable(() =>
  Promise.all([
    import(/* webpackChunkName: "Chapter1" */ /* webpackPrefetch: true */ './pages/chapter-1/Chapter1'),
    request<{}, { ping: 'pong' }>('POST', '/api/data'),
  ]).then(([Chapter1, data]) => {
    const Chapter1 = Chapter1.default;

    return function () {
      return <ComponentA data={data} />;
    };
  }),
  {
    fallback: <div>Loading components and data...</div>,
  }
);

This way, we also managed not to violate the component approach. Even though, the request logic is not stored in the lazy component, it's still a part of Chapter1Lazy. And the data will be requested only when the component is rendered, i.e. only when the data is actually needed.

And now, our waterfall looks like this. Noticed that data is requested almost at the same time with lazy chunks? This way we download data from the server while our lazy chunks are being downloaded. The data is requested about 200 ms earlier, therefore it's displayed about 200 ms earlier. A win.

Although, one might object that this approach pushes data-fetching code into the initial bundle, which increases its size and hurts UX by slowing down the initial load. And that's fair. But if you keep the request logic as lean as possible, the extra weight will be negligible — while the overall loading experience will improve significantly.

And this approach won't worsen cacheability either, because initial javascript files always lose their cache regardless of what changes we make.

📌 Try to request data from the server without waiting for your lazy chunk to be downloaded.

A real life example

This approach is not limited to preloading data for displaying pages only. We can be creative about it. Let me show you how I utilized this approach in my current project. This is a simplified code of one of the pages:

export default ({ roomID }: { roomID: string }) => {
  const { data, isLoading } = useApi('POST', '/api/room', {
    params: { roomID },
  });

  return (
    <>
      <section className="left">
        <VideoPlayer data={data} isLoading={isLoading} />
      </section>

      <div className="right">
        {data && (
          <>
            <Card1Lazy room={data} roomID={roomID} />
            <Card2Lazy room={data} roomID={roomID} />
            <Card3Lazy room={data} roomID={roomID} />
          </>
        )}
      </div>
    </>
  );
}

And each card used to look like this:

export default ({ room, roomID }: { room: RoomData, roomID: string }) => {
  const { data, isLoading } = useApi('POST', '/api/card/1', {
    params: { roomID },
  });

  return (...)
};

The overall timeline of rendering these cards looked this way:

The browser downloads initial JavaScript chunks
The browser downloads lazy chunks for this particular page
The browser requests data about a livestream room and waits until it gets the response.
- Each of the cards needs room data to render UI but not to request data. However, since the component cannot be rendered without room data, no card data is requested.
Then, having received the data about the room, the cards begin to be drawn, and we upload them to their lazy chunks.
Then, for each of the cards, we request data.

To display a card, users had to wait between 2.8 and 4.1 seconds, depending on card API latency.

But here's what I did:

Started requesting room data together with loading page lazy chunks
Started requesting card data right after page lazy chunks are loaded. Even though we can't render these cards, we should be able to request data.

Now, each of the cards wait for 3 parallel processes: livestream data, card API data, and card static files. Unless either of those 3 is not downloaded, the fallback is displayed. I parallelized the loading time as much as possible, and managed to reduce the display time for each of the card by approximately 1.4 seconds. Plus, video player now is displayed 0.2 seconds faster as well.

📌 Be creative.

Conclusion

Thank you for joining me once again on our journey to make our web applications indefinitely lazy. If you have any questions feel free to ask them in comments.

And to summarize this article, let's list the rules we learned today:

📌 📌 Use Webpack prefetching and downloading for mission-critical chunks of your application. But do not overdo it, so as not to lower the performance of your site.
📌 Try preloading your lazy components manually, based on user interactions.
📌 Try to request data from the server without waiting for your lazy chunk to be downloaded.
📌 And most importantly: Be creative.

A-a-and that was it. I hope some did read all the articles of this series. And I hope some of you might even catch something new from them. So, what do you think? I'm overcomplicating it, or is lazy loading more complicated than you thought? Let me know in the comments.

Here are my social links: LinkedIn Telegram GitHub. See you ✌️

How to make your app indefinitely lazy – Part 3: Vendors and Cache

Aleksandrovich Dmitrii — Wed, 15 Oct 2025 08:31:27 +0000

Well, hello there! And welcome to part 3 of my ultimate guide! Brace yourself, because you are about to become a real pro.

⏱️ Reading time: ~18-20 minutes
🎓 Level: Intermediate+

Series Contents:

How to make your app indefinitely lazy – Part 1: Why lazy loading is important
How to make your app indefinitely lazy – Part 2: Dependency Graphs
How to make your app indefinitely lazy – Part 3: Vendors and Cache
How to make your app indefinitely lazy – Part 4: Preload in Advance

Earlier we covered how to make our project's dependency tree as clean as possible and why it is important for lazy loading. And in this article, we will cover the following:

How we should download vendor files to ensure the best lazy loading.
What do "Lazy Loading" and "Cache" optimization strategies have in common, and how does using one affect another.
What is cacheability and how to make our application as cacheable as possible.
As well as how to correctly set up Webpack's cache groups and not mess up performance.

How to split your vendors

Lazy loading isn't just about splitting our own source files. It also applies to everything our website delivers, including external NPM packages. And it also applies to using cache properly.

Terms "vendors" and "cache" will be related in this article. So, let's briefly talk about what caching is first. Cache is yet another strategy to boost the loading time. In simplified terms, it works this way:

When a user opens our website for the very first time, no cache is applied; thus, all the files must be downloaded. At the same time, all the files the browser has downloaded are saved locally in cache.
Later, when a user reloads the page or opens a website a second time and onward, the files are retrieved from the local cache, which significantly reduces the loading time.

Now, let's go back to vendors. Imagine we use a few NPM packages in our project and we import different members from them in different lazy chunks.

// Title (loaded initially)
import { chunk, difference, intersection, sortedUniq, takeWhile } from 'lodash-es';
import { addDays, addHours, addYears, addMonths } from 'date-fns';

// Chapter 1 (loaded lazily)
import { countBy, partition, sample, sampleSize, orderBy } from 'lodash-es';
import { differenceInBusinessDays, differenceInCalendarDays, differenceInCalendarQuarters, differenceInHours } from 'date-fns';

// Chapter 2 (loaded lazily)
import { debounce, memoize, throttle, once, curry } from 'lodash-es';
import { isToday, isTomorrow, isAfter, isDate } from 'date-fns';

How should the browser download the members?

Common configuration mistakes

Some developers believe that creating a single vendor file for the assembly is a good approach for delivering vendors. And the reason why they do that is that:

It is easier to save and retrieve from cache a single file rather than several.

But that's actually a bad choice. Because:

The difference in the speed of downloading one and several files from the cache is negligible.
If the user does not have a cache, they will be required to download vendors during the initial download. Moreover, since none of the vendors load lazily, additional delays occur during the initial download. And, again, it is extremely important from the user's point of view.
Plus, since all the vendors are included in a single file, any time we import a new member from any NPM package, the hash code of this file changes. Which causes cache to be lost. Which causes problem #2.

Let's discuss the 3rd point in more detail. Why cache can be "lost"?

Usually, in real production applications, we need to control the cache of our files. Real websites change over time when introducing new features and fixing bugs. If we make our caching strategy too aggressive, users may stop downloading files from the server and start extracting files only from the cache. Because of this, users may miss the changes that we are implementing.

To avoid such problems, usually developers include some unique identifiers into generated filenames. So, once we deploy a new update:

filenames of our application change;
users lose their cache;
and the browser is able to download the required changes.

And there are various ways to achieve it, but the ideal way is to include file content hash into its name. And the easiest way to do this in Webpack is to add a template placeholder [contenthash] to output.filename and output.chunkName.

module.exports = {
  // ...
  output: {
    // ...
    filename: '[name].[contenthash].js',
  },
};

In output, besides [contenthash], you can also use [hash], [chunkhash], or [fullhash]. You can also provide some unique strings yourself like a date timestamp of when the build was happening. Or you can also use hash configuration from the HTMLWebpackPlugin. And none of these options, besides using [contenthash], are ideal to maintain the best cache strategy. But we will cover it a little later.

But for now, you should understand that using [contenthash] is considered the best practice to build an application. When we use this placeholder, once the content of any generated file changes, its name changes too, which results in cache being lost.

And if we store all vendors inside a single file, any additional import from any NPM library will lead this file to be changed.

So, remember: if you see something like this in your assembly, chunk groups are probably set up incorrectly.

Another similar mistake some developers make, is generating vendor chunks based on the name of the NPM package. And such an approach is actually much better in general but may have similar problems of violating the lazy loading principle, because chances are you will be downloading these files initially. Plus, again, this strategy is still not the best in terms of caching.

Correct configuration

So, how can we make our vendors load truly lazily? We need to split our vendors into lazy-loaded parts:

If any exported entities (not packages) are required to be downloaded initially, only they should be done so.
But the rest should be loaded only when they are actually in use. For the example from the very beginning, the countBy and differenceInBusinessDays methods should only be loaded when Chapter 1 is opened.

The ideal assembly for the example from the beginning of the article should look like this:

We have an initial chunk for vendors, plus we have asynchronous vendor chunks. Chapter1 would need to download only its own vendor chunk, while Chapter2 would need to download its own. As in lazy loading it should be.

I would like to additionally note that in the example above, the creation of chunks does not depend on NPM packages in any way. The content of date-fns and lodash-es is split into 3 parts: they load partially during the initial download and partially during the loading of each of the lazy pages.

In Webpack, such vendor splitting is really easy to achieve:

module.exports = {
  // ...
  optimization: {
    splitChunks: {
      chunks: 'all',
    },
  },
}

📌 Set up your Webpack to split vendor packages and load them lazily.

Make it cacheable

But what do I mean by saying "cacheability"? We do need to reset cache of our files every time we deploy an update. However, we don't need to lose cache for all the files. In fact, we can make only required files to lose their cache. And by "cacheability", I mean how many files don't lose their cache after we make a change.

Use Webpack correctly

Let's go back to how to properly configure file names in an assembly. As I said, most of the existing strategies other than using [contenthash] are not ideal to maintain a decent cache strategy.

Using [fullhash] or HTMLWebpackPlugin's hash leads to removing cache from all the files each time we make the slightest change.
Using [hash] and [chunkhash] will result in slightly more stable files. Although, they still will not be as stable as when using [contenthash].
As creating your own strategy, it's either very complicated or you will end up losing cache for all the files by the smallest change.
- For example, in my previous company for some period of time, we used Date.now() instead of the built-in hash functions. Which made all files update their names in every single build. Even if we didn't have any changes.

module.exports = {
  // ...
  output: {
    // Bad examples
-    filename: `[name].${Date.now()}.js`,
-    filename: '[name].[fullhash].js',
-    filename: '[name].[hash].js',
-    filename: '[name].[chunkhash].js',
    // Good example
+    filename: '[name].[contenthash].js',
  },
  plugins: [
    new HtmlWebpackPlugin({
      // Bad example
-     hash: true,
    })
  ],
};

📌 Use only Webpack's [contenthash] to make your application as cacheable as possible.

Clean your dependency tree

From the first glance, "lazy loading" and "caching" seem to be unrelated optimization strategies. However, they do share some commonalities. For example, in the previous article, we found out how optimizing the dependency graph can improve the number and size of uploaded files. But also the "clean" dependency graph affects how much our site cacheability.

Let's regard the following example. Due to a terrible source file dependency graph, Webpack created an entangled execution dependency graph. Like on the picture below.

Let me remind you how to read such a graph. The black lines indicate the "hard" dependencies. Every time the browser needs to download a file, the hard-dependent files will also be downloaded. That is, in our bad example, when downloading Page 1, we need to download chunks 1-5. And to download chunks 1-5, we need to download chunks 6-10.

Let's say we made a one-line change that would affect the content of [id].[hash].chunk6.js. We'd expect only this file to lose its cache. However, in reality, chunks 1-5, as well as pages 1-3, as well as main.js, - they all also update their content hash. And therefore, with the execution graph above, a single one-line change may lead most of the files to lose their cache.

Webpack is not able to change the name of just one file. The dependencies I mentioned, both "hard" and "soft", are stored inside the files themselves. Page 1 stores links to all chunks 1-5 inside itself. And if the name of one of them changes, page1.[hash].js is also required to update its content in order to be ready to download a new file.

To understand which files will be affected when certain changes are made, we can also visually analyze the execution dependency graph "in reverse order". Fragments 1-5 depend on fragment 6. Pages 1-3 depend on fragments 1-5. And main always depends on pages 1-3. And therefore, they all lose their cache.

Now, let's imagine we fixed the graph.

In reality, the number of generated files should've been changed in such a case. But to make it simpler let's imagine that the files are generated completely the same, while the number of connections became much lower.

What happens when we make exactly the same one-line change?

If we analyze the dependency graph backwards, we'll see that now only chunk1, chunk5, page1, and main, will have their hash updated. Therefore, only 5 files lose their cache.

Now, a small task for you: what files will be changed, if chunk8 is updated?

Answer

Files main, page 2, page 3, chunk 2, chunk 3, and chunks 8, will lose their cache.

📌 Keep your dependency graph clean to improve cacheability of your project. The cleaner the graph is, the fewer files lose their cache each time we make a change.

Beware: you have lost the cache of initial files.

You've already noticed that in all the examples above, main.js always loses its cache. Even when we fixed our dependency tree. This is because the main JavaScript entry file will always depend on all other generated files from the assembly. Thus, this file always loses its cache every time any change is made.

However, I repeat that cache of main and other chunks is lost in this way only when our changes affect the dependency graph, i.e. when we add or remove new imports. However, files can be modified without creating new imports. For example, you can simply correct a constant or a typo. And in this case, there will be significantly fewer files to lose the cache. But at least 2. And one of them is bound to be an initially downloadable file.

And this happens because of such a thing as runtime chunk. This is a piece of code that stores all the information about which files exist in the project. If any file name changes, the runtime chunk changes its contents to include the new file name. Therefore, if in our example with [id].[hash].chunk6.js we don't change the dependency graph, then only 2 files will lose the cache: chunk6 and main, because by default main includes runtime chunk.

This is another reason why we should pay special attention to the size of the initially loaded files. First of all, we need to reduce the loading time like there is no cache. And then, in addition to the already reduced loading time, apply caching on top.

ℹ️ Regardless of the size of our change, the main javascript file will always lose its cache. That's the second most important reason why we should make our initial javascript files as lean as possible.

Set up vendors cache groups

And now, since we already know what "cacheability" is and what defines how good it is, we are ready to continue with our vendors discussion.

You might have noticed that in our "correct configuration" example the size of the initial vendor file is quite big. And with the approach I described it may become even bigger, especially when we use multiple NPM libraries: react, react-dom, zustand, zod, axios, etc. Because even if some libraries can be downloaded lazily, quite many of them still must be downloaded initially. And the large size of the initial vendor file can negatively affect the download speed of the application. However, we can fix this issue by setting up cache groups.

With the cache groups configuration, we can tell Webpack how to generate JavaScript chunks, including what source code files and/or vendors should be included in certain chunks. By configuring cache groups, we can split one file into several or, conversely, combine them. Also, if we set them up correctly, we will improve cacheability.

In the example above, we can use cache groups to split the original vendor file into 2-3 files. Thus, these files can be downloaded in parallel, which can have a very good effect on download speed. However, the name "cache groups" implies that groups should be created to manage the cache, not to speed up downloads.

It is considered good practice to create cache groups only when we are sure that the group we are creating will be stable over time.

ℹ️ In order to make cache groups stable, we should include only "stable" vendors in the groups we create.

For example, react, react-dom, axios and zod, all must be used entirely in our application, and therefore can be included in a cache group. But date-fns or lodash-es can vary in their content based on what exported entities are used in our project, therefore we should not create cache groups for them.

It is often not worth bothering too much about cache groups. It is enough to set up groups for initially loaded vendors. Creating other groups can negatively affect caching capabilities if we don't have a complete understanding of what's going on with our build.

In order to create such groups, we should use splitChunks.cacheGroups:

  module.exports = {
    optimization: {
     splitChunks: {
       cacheGroups: {
        react: {
          filename: `react.[contenthash:8].js`,
          // it's better to create groups for initial vendors only,
          //  but don't use it in micro-fe apps
          chunks: 'initial',
          // Will include `react`, `react-dom`, and `react-router-dom`
          //  in a single chunk
          test: /react/,
        },
       },
     },
    },
  };

And voila! We killed two birds with one stone.:

Our initially uploaded vendor file is split into 2 files, which makes it load 2 times faster.
The chunk created through cache groups will be stored in the cache until the expiration date, because react, react-dom and react-router-dom will rarely change in the application.

📌 Configure Webpack cache groups for stable vendor packages to further split files to improve download speed and cachability.

Conclusion

Alright, that was long, but that's it for today. Thank you for joining me once again on our journey to make our web applications indefinitely lazy. If you have any questions feel free to ask them in the comments. And you can also read the following articles from this series.

And to summarize this article, let's list the rules we learned today:

📌 Set up your Webpack to split vendor packages and load them lazily.
📌 Use only Webpack's [contenthash] to make your application as cacheable as possible.
📌 Keep your dependency graph clean to improve cacheability of your project. The cleaner the graph is, the fewer files lose their cache each time we make a change.
📌 Configure Webpack cache groups for stable vendor packages to further split files to improve download speed and cachability.

You are almost there, just one more push:
How to make your app indefinitely lazy – Part 4: Preload in Advance

Here are my social links: LinkedIn Telegram GitHub. See you ✌️

How to make your app indefinitely lazy – Part 2: Dependency Graphs

Aleksandrovich Dmitrii — Wed, 15 Oct 2025 08:31:16 +0000

Well, hello there! And welcome to part 2 of my ultimate guide! Brace yourself, because you are about to become a real pro.

⏱️ Reading time: ~25-30 minutes
🎓 Level: Advanced

Series Contents:

How to make your app indefinitely lazy – Part 1: Why lazy loading is important
How to make your app indefinitely lazy – Part 2: Dependency Graphs
How to make your app indefinitely lazy – Part 3: Vendors and Cache
How to make your app indefinitely lazy – Part 4: Preload in Advance

Earlier we discussed the very basics of lazy loading and why it is important at all. And in this article, we will cover the following:

How bundlers (i.e. Webpack) analyze source code files, build dependency graphs and generate files for the assembly.
How they generate JavaScript files from the source code.
How browsers decide which generated files should be downloaded to display a lazy page/component.
And how we can decrease the size and number of downloaded files by correctly setting up the structure of files and correctly using static imports.

Experiments with Webpack and dependency trees

Let's begin our deep dive with a few thought experiments. We'll use the same pet app from the Part 1. Right now, the application is built into 3 JavaScript files: the initial chunk and 2 lazy loaded chunks, each responsible for each of the pages we have.

Experiment #1 - a shared component

Let's make each of the 2 lazy loaded pages use the same shared component - LargeComponent. Its worth to mention that its declaration is stored in a separate file large.tsx and the size of this file is relatively large.

Chapter1.tsx

import React from 'react';
import { LargeComponent } from '../../components/large';

export default () => (
  <>
    <section className="page">
      <h2 style={{ margin: 'auto' }}>Chapter 1</h2>
      <LargeComponent />
    </section>

    <Content />
  </>
);

function Content() {
  // 2000 lines of code
}

Chapter2.tsx

import React from 'react';
import { LargeComponent } from '../../components/large';

export default () => (
  <>
    <section className="page">
      <h2 style={{ margin: 'auto' }}>Chapter 2</h2>
      <LargeComponent />
    </section>

    <Content />
  </>
);

function Content() {
  // 2000 lines of code
}

Now, I have a question for you. What do you think: how many chunks will be generated and how will they be downloaded by the browser when we try to open these pages?

I bet this one was easy. Webpack will generate 4 files.

And the behaviour will be as follows. When we try to open page "Chapter 1", the browser will download 3 chunks: the initial chunk, "chapter1.chunk.js" and the new chunk. Likewise, it works if we first open "Chapter 2": the initial chunk, "chapter2.chunk.js" and the new chunk.

You may notice that Webpack just generated a lazy-loaded chunk on its own. However, we imported this component statically and did not use any dynamic imports. Why did it happen?

Webpack analyzed our application and found that 2 lazy components use a shared dependency and created a new shared chunk to optimize loading time. Any time the browser needs to download any of those 2 pages, it must download this additional chunk as well. But the good part is that once the browser downloads this additional chunk, it will not download it again to display the second page. For example, if we opened Chapter 1 once and now are trying to open Chapter 2, the chunk will not be downloaded again.

I also want to highlight here that sometimes developers are confused and believe that they should use dynamic imports for shared dependencies of lazy-loaded components to manually split those shared dependencies into lazy loaded chunks. They do that in attempts to additionally optimize loading time. But this is actually bad practice. Later in this article, we will discuss more appropriate ways to optimize the number of files uploaded and how we can help Webpack break the build into chunks more efficiently. But for now, you should keep in mind:

ℹ️ You should use dynamic imports only for those components which can be displayed lazily themselves, but almost never for their shared dependencies. Webpack is capable of efficiently splitting your bundle into separate chunks on its own.

Experiment #2 - how about a tiny shared component?

I mentioned several times that in the previous example everything works as described, because the common component was quite large. But what if we specifically make the common component small enough? What will be the difference?

Chapter1.tsx

import React from 'react';
import { TinyComponent } from '../../components/tiny';

export default () => (
  <>
    <section className="page">
      <h2 style={{ margin: 'auto' }}>Chapter 1</h2>
      <TinyComponent />
    </section>

    <Content />
  </>
);

function Content() {
  // 2000 lines of code
}

Chapter2.tsx

import React from 'react';
import { TinyComponent } from '../../components/tiny';

export default () => (
  <>
    <section className="page">
      <h2 style={{ margin: 'auto' }}>Chapter 2</h2>
      <TinyComponent />
    </section>

    <Content />
  </>
);

function Content() {
  // 2000 lines of code
}

It will. Now, Webpack generates only 3 files. Just like in the case, when lazy pages didn't have any shared components.

But why? What happened to the TinyComponent? The truth might terrify some of you. Webpack copied and pasted the content of TinyComponent into both Chapter1.chunk.js and Chapter2.chunk.js! That means the same code will be downloaded each time we download any of these files.

It sounds concerning, because we may end up downloading the same code twice. But that's actually a reasonable strategy. In real projects, we might have hundreds of source files used across dozens of lazy-loaded chunks. If Webpack created a separate chunk for every tiny file, we could end up with hundreds or even thousands of generated files. Can you imagine making browsers download hundreds of files to display a single page? Browsers struggle with a large number of requests. If your website still uses HTTP/1.1, every additional file will drastically affect performance. But even if you use the HTTP/3 protocol, the browser may start downloading only 6 files at a time, which will result in significant delays if you have hundreds of files.

You should be aware that Webpack may decide to create duplicates of code in your assembly. And even though you can fix, it doesn't mean you should do it.

ℹ️ For small shared dependencies, Webpack will not generate a separate chunk, and instead will copy-paste its code into other existing chunks. And it is a reasonable strategy, so you should not try to "fix" it.

Experiment #3 - two shared components: large and tiny

But what if we use both of these components in both pages?

Chapter1.tsx

export default () => (
  <>
    <section className="page">
      <h2 style={{ margin: 'auto' }}>Chapter 1</h2>
      <TinyComponent />
      <LargeComponent />
    </section>

    <Content />
  </>
);

Chapter2.tsx

export default () => (
  <>
    <section className="page">
      <h2 style={{ margin: 'auto' }}>Chapter 2</h2>
      <TinyComponent />
      <LargeComponent />
    </section>

    <Content />
  </>
);

Generated chunks are very similar to experiment #1.

The question though is there any difference to TinyComponent this time? And the answer is "yes". Now, the code of this component will be included only once: in the additionally generated chunk - 595.chunk.js.

Just like in the example #1, Webpack managed to create a separate chunk for storing LargeComponent. But this time, during the analysis of the dependency graph, Webpack understood that TinyComponent is also a shared dependency and it used exactly in same lazy components as LargeComponent. And therefore, Webpack merged them into a single file.

And what I wanted to highlight here is that Webpack is quite intelligent when it comes to lazy loading. In other words, we can rely on Webpack to handle lazy loading efficiently. But we need to help it a little bit to improve its efficiency.

Dependency Graph

So, how does it work? When we are talking about lazy loading, we must start thinking in terms of dependency graphs. Webpack analyzes our app's source files and generates dependency graphs for the code. Then it generates JavaScript files, each with its own execution dependency graph.

Let's take a look at the graph for our example: two lazy-loaded pages and two shared components.

We have 6 files in total: large.tsx, tiny.tsx, Chapter1.tsx, Chapter2.tsx, and App.tsx. And files Chapter1.tsx and Chapter2.tsx are loaded lazily. We also have 2 external dependencies: react and react-dom.
Webpack starts analysis of our application from the "entry" file: App.tsx. It sees that App.tsx has a few static imports - react, react-dom, and Title.tsx, - and includes all of them into the initially loaded chunk: main.js.
Then, it creates lazy loaded chunks for each of the dynamically imported modules: chapter1.js and chapter2.js.
And then, it analyzes all shared dependencies, and it sees that "large.tsx" and "tiny.tsx" are both used in Chapter1 and Chapter2. Therefore, it combines them into a single "shared.js" file. Alternatively, if only "tiny.tsx" is used, like in Experiment #2, its content will be copy-pasted in both lazy chunks.
In the end, Webpack creates a new execution graph. So, when the browser is able to download main.js on its own, but must download shared.js any time it needs to download any of chapter1.js or chapter2.js

Picturing such dependency graphs is very useful when we are trying to understand how many chunks our app will generate, and how many of them will be downloaded in certain conditions. But why should we care about it?

Beware of the static imports' weight

When we are implementing lazy loading, using dynamic imports is not even half the story. How we structure our files and manage the dependency tree is just as important, and sometimes even more so.

Let's extend our example. Imagine, both Chapter1 and Chapter2 use the same component. Initially, this component was used only in Chapter1, and thus it was declared inside the "Chapter1.tsx" file. To save some development time, we decided to export this component from the "Chapter1.tsx" file instead of creating a new separate file to store only the shared component. It's quite common practice to stumble across, at least in my experience.

Chapter1.tsx

import React from 'react';
import { LargeComponent } from '../../components/large';
import { TinyComponent } from '../../components/tiny';

export const AnotherCommonComponent = () => (
  <div style={{ color: 'blue', fontWeight: 500 }}>
    Another common component
  </div>
);

export default () => (
  <>
    <section className="page">
      <h2 style={{ margin: 'auto' }}>Chapter 1</h2>
      <TinyComponent />
      <LargeComponent />
      <AnotherCommonComponent />
    </section>

    <Content />
  </>
);

function Content() {
  // 2000 lines of code
}

Chapter2.tsx

import React from 'react';
import { AnotherCommonComponent } from '../chapter-1/Chapter1';
import { LargeComponent } from '../../components/large';
import { TinyComponent } from '../../components/tiny';

export default () => (
  <>
    <section className="page">
      <h2 style={{ margin: 'auto' }}>Chapter 2</h2>
      <TinyComponent />
      <LargeComponent />
      <AnotherCommonComponent />
    </section>

    <Content />
  </>
);

function Content() {
  // 2000 lines of code
}

And… now our lazy loading has become much less efficient. Despite the fact the shared component was tiny, we still managed to brake lazy loading. If we take a look at the generated files, we'll see that for some reason, now we only 3 files are generated. And for some reason, the content of large.tsx is included in Chapter1.chunk.js.

But why? Let's take a look at the dependency tree to understand it.

The graph became messier. And the more complex the graph is, the harder it is for Webpack to handle it efficiently. Webpack still generates the same main.js, and still generates files chapter1.js and chapter2.js. However, what changed is that when Webpack analyzed shared dependencies, it saw that now 3 files (Chapter1.tsx, large.tsx, and tiny.tsx) have become shared dependencies between Chapter1.tsx and Chapter2.tsx, and combines them into a single file. And since Chapter1.tsx already has a generated chunk of its own, Webpack includes all these 3 files into Chapter1.chunk.js.

Hence, the execution graph has changed significantly. When a user opens Chapter1, the browser downloads only that its chunk. However, when a user opens Chapter2, the browser ends up downloading both Chapter1.chunk.js and Chapter2.chunk.js.

Beware! Our initial intention was to boost the loading time. But in reality, for Chapter2, we didn't achieve that. The browser ended up downloading thousands of lines of code from Chapter1.tsx that will not be used on page Chapter2.

Doesn't tree-shaking help with lazy loading?

You might have a question: shouldn't tree-shaking have fixed that? The answer for that is simple: "no, it shouldn't". When we work with lazy loading, tree-shaking should be treated as a different mechanism. Its goal isn't about code-splitting, and it happens before it. With tree-shaking, bundlers are able to remove unused exports from a file. E.g. if Chapter1 exported a bunch of functions that wouldn't be used anywhere, tree-shaking would remove them. But since both AnotherSharedComponent and the default export of Chapter1.tsx were used, tree-shaking couldn't do anything.

ℹ️ Webpack operates files and cannot treat exports from a single file as separate dependencies.

Therefore:

📌 Do not rely on tree-shaking. Split your files manually to ensure effective lazy loading.

Realistic bad dependency graph examples

For now, it might feel a bit abstract. How can we use this knowledge in real projects? I will show you an example of how bad dependency tree was on a project I currently work.

This depiction is not 100% accurate. However, it does highlight its problems:

Components from “Component group 1” by design should have been used only in pages “Page1” and “Page2”.
- At the same time, Page1 and Page2 had some unique non-shared components, yet they were stored in a shared space.
Components from “Component group 2” and some related to them NPM packages should've been used only in pages “Page 3”, “Page 4”, and “Page 5”.
And each of the pages should have been as independent as possible.

However, in reality, when any of these pages was loaded, the browser had to download almost all the generated files. Even if a component from “component group 2” or “npm-package-1” was not used in “Page1”, their code still was loaded when users opened this page. And these problems existed only because architecture of this project affected dependency tree negatively.

Keeping dependency graph in a good shape

This was an example of a bad dependency graph. Lazy loading was utilized, but it didn't decrease loading time as it could, because the browser had to download and parse a lot of files. But how can we avoid such situations? Honestly, considering how many files there can be in a real project, imagining a real dependency graph won't be helpful. But we can formalize some rules to improve it.

Rule #1: Embrace the Default

Did you notice how "Page1.tsx" imported something from "Page2.tsx", just like in the example from earlier? To display the former, the browser must also download the latter and all of its dependencies. And to avoid it, we should follow this rule:

📌 Each dynamically imported file must have only 1 exported entity, e.g. only default export.

If we followed this rule, we wouldn't be able to import anything else from "Page2" other than the code for displaying this page. And therefore, we wouldn't create this extra static dependency

Rule #2: Decentralize and Avoid Bad Patterns

Next, on graph you can see files which I called "facade". What are those? A facade file is a file which imports a bunch of stuff and exposes it by applying some logic or creating objects. In my particular case, facade files were used to store render methods for dozens of components in a single object:

import { First } from './component-1/first';
import { Second } from './component-1/second';
import { Third } from './component-1/third';
// other imports

export const renderComponentsGroup1 = {
  renderFirst: (prop1: string) => <First prop1={prop1} />,
  renderSecond: (prop2: string[]) => <Second prop2={prop2} />,
  renderThird: (prop3: number[]) => <Third prop3={prop3} />,
  // other dozens of methods
};

"Facade" files may also provide utility methods, operate multiple classes, maybe even utilize diverse NPM libraries. And they are used way more often than you think. Basically, any Java-style design pattern like Factory, Orchestrator, Builder, Module, Service Layer, Repository, etc., - they all can be examples of "facade" files. And the problem with such files is that we should be extremely cautious about using them.

Let's say we take renderComponentsGroup1 from our example, and use only a single method renderFirst on Page1. As mentioned earlier, Webpack operates files, and is not able to analyze different exports separately, let alone different methods of an object. Therefore, although we do not use renderSecond and renderThird, since they are methods of renderComponentsGroup1, they will also be loaded when opening Page 1. Moreover, all the dependencies of the facade file, including Second.tsx, Third.tsx, other components that are used inside renderComponentsGroup1, as well as all the dependencies of Second.tsx, Third.tsx, etc., will also become dependencies of Page 1. And even if First.tsx itself is a tiny file, since we rendered it using renderComponentsGroup1, the browser will be required to download the entire dependency tree of this file.

And the problem here is not really with using objects, rather with centralizing your logic in a single file. Because the larger the file or its dependency tree, the worse the situation. There can be 2 scenarios of such centralization:

a single file that contains thousands lines of code,
or a relatively small file that reuses dozens of files, while each of those reuse their own files, and so on.

To deal with the first scenario we can simply follow this rule:

📌 Make your files as atomic as possible and export as few dependencies as possible.

Plus, I mentioned Java-style patterns because they may lead to the second scenario. Frankly, often developers may follow such patterns blindly, without actual purpose and only because "smart people said it's better this way". I'm not saying though that using them is essentially always bad. But for Front-End development they are not ideal. We should always ask ourselves twice whether using such a pattern really brings order to our codebase before applying them.

In my practice, using logic directly instead of wrapping it with patterns and interfaces may significantly improve your dependency graphs. Plus, usually having small files with independent function exports and sometimes re-export files is enough to cover 98% of needs in FE development.

📌 Try avoiding Java-style and other patterns that would centralize logic from several files into a single file.

Rule #3: Break It Down

I have already mentioned that Webpack is not capable of analyzing exports of the same file as different entities, and that we need to split the files ourselves to build an effective dependency graph.
I also said that the ideal way to create a clean dependency tree is to make each source file to be as atomic as possible. Ideally, to export only 1 entity. Although, it's not really convenient DX-wise. So, I doubt any developer would want to create a separate file each time they want to have a shared constant or a utility method. So, to balance developer experience with efficient lazy loading, here's a simple guideline: don't export entities of different types from the same file. And by types, I mean the very gist of an entity: constants, objects, classes, methodes, components, etc.

You can still declare utility methods, constants, classes, and components in the same file. For example, we could store some utility methods and constants inside Chapter1.tsx. But when we need to export entities of different types, we have to create separate files: utility files for functions, constant files for constants, and so on. As for components, it's better to try to have as few of them as possible per file. And if any of components should become shared, we shouldn't be lazy to create a separate file for them.

Here's an example of how I split files in my project:

There's a simple logic behind such a splitting. A file which exports constants only is more likely to be re-used by other files, but less likely to have its own dependencies. Because usually constant files may import other constants but nothing else. Utility methods are second most likely to be re-used, and they usually only import constants and other utility methods. And well, for components it's just better to have as few of them per file as possible, because they will use any other files.

📌 Don't export entities of different types from a single file. Export utility methods only from dedicated utility files. Likewise for constants. As for components, try to have as few as possible per file.

Rule #4: Avoid the Loop

And another rule would be that we need to avoid cyclic dependencies in our application. It's actually a general rule to avoid them in front-end development for a variety of reasons. And one of them, is that if you have a cycle in your dependencies, Webpack will include every single file of this cycle, and their static dependencies as well.

The deeper the cycle goes, the more code will be included in the generated chunks. Or, alternatively, the more separate chunks will a browser download to display a lazy component.

📌 Avoid having cyclic import dependencies in your application.

Re-exports do not affect lazy loading. Unless...

Contrary to what I thought, using re-export files in your code doesn't affect lazy loading. Here's an example of such a file.

export * from './component-1/first';
export * from './component-1/second';
export * from './component-1/third';

The difference between them and facade files is that the latter adds logic and wraps dependencies into objects, but a re-export file simply forwards imports without any logic. And I thought, using re-export files would have the same impact.

However, it doesn't. Webpack operates end declaration files when it analyzes dependency tree. If we do import an entity from a re-export file, Webpack will use the actual file where this entity was declared.

// So if you import an entity like this
import { First } from '@components';

// Webpack will treat it as
import { First } from '../../../components/component-1/first.tsx';

Re-export files won't break our dependency tree even if you do barrel import. Because if we use barrel imports as regular imports, Webpack is still capable of building the correct dependency tree.

import * as components from '@components';

// Only `First` will be a dependency of this file
export default () => (
  <components.First {...} />
);

But once we use barrel imports as a regular object, we are doomed. Such an object simply becomes a facade object, which we should avoid. And, with such an object, we end up downloading all the exports from the barrel import object.

In this particular example below, we tried to create a component which can display icons using their names. With such an approach, even if we use a single icon in our project, we'll end up downloading the entire package with all the icons. The same goes for our own source code re-export files.

import * as components from '@components';
import * as icons from 'react-icons/md';

// Using this component will lead to downloading all the icons
//  from react-icons/md, even if only 1 icon is used.
export Icon = ({ name }: { name: keyof typeof icons }) => {
  const IconElement = icons[name];
  return <IconElement />;
};

// Using this component will lead to downloading all the components
//  from @components, even if only 1 components is used.
export Component = ({ name }: { name: keyof typeof components }) => {
  const ComponentElement = components[name];
  return <ComponentElement />;
};

📌 Try to avoid using barrel imports and especially using them as regular objects, unless it's really necessary.

Conclusion

And to summarize this article, let's list the rules we learned today:

📌 Do not rely on tree-shaking. Split your files manually to ensure effective lazy loading.
📌 Make each dynamically imported file have only 1 exported entity, e.g. only default export.
📌 Make your files as atomic as possible and export as few dependencies as possible.
📌 Try avoiding Java-style and other patterns that would centralize logic from several files into a single file.
📌 Don't export entities of different types from a single file. Export utility methods only from dedicated utility files. Likewise for constants. As for components, try to have as few as possible per file.
📌 Avoid having cyclic import dependencies in your application.
📌 Try to avoid using barrel imports and especially using them as regular objects, unless it's really necessary.

We are only half way through. Stick around to dive even deeper:
How to make your app indefinitely lazy – Part 3: Vendors and Cache

Here are my social links: LinkedIn Telegram GitHub. See you ✌️

How to make your app indefinitely lazy – Part 1: Why lazy loading is important

Aleksandrovich Dmitrii — Wed, 15 Oct 2025 08:31:02 +0000

Lazy loading is a principle which should be known by most front-end developers. However, it is a more complicated topic than it is usually perceived to be. Therefore, even if you do use lazy loading, you might still have some gaps in your knowledge. And if you feel you know it all, it might be a good idea to freshen your grasp on this topic.

⏱️ Reading time: ~12-15 minutes
🎓 Level: Beginner+

Series Contents:

How to make your app indefinitely lazy – Part 1: Why lazy loading is important
How to make your app indefinitely lazy – Part 2: Dependency Graphs
How to make your app indefinitely lazy – Part 3: Vendors and Cache
How to make your app indefinitely lazy – Part 4: Preload in Advance

In this article, we'll cover the fundamentals of lazy loading:

What is it and why is it important;
How can we utilize lazy loading in our projects;
As well as what parts of the code should be loaded lazily.

This article covers only the basics, but starting from part 2 we will cover more complicated topics:

How bundlers (i.e. Webpack) analyze source code files, build dependency graphs and generate files for the assembly.
How we can decrease the size and the number of downloaded files by correctly setting up the structure of files and correctly using static imports.
How we should download vendor files and set up Webpack's cache groups.
- As well as how lazy loading affects caching and how to make our projects as cacheable as possible.
How we can utilize prefetching/preloading strategies, including:
- What Webpack magic comments can we use;
- What is speculative or manual prefetching and how to use it;
- And what third-party or our own solutions can be used for that.
And how can we request data from server without waiting for our static files to be downloaded.

Brace yourself, because you are about to become a real pro. But make sure you read all the articles 😅

Why Lazy Loading Matters

Let's commence. What is lazy loading and why is it important at all?

Imagine a large web application: the bigger it gets, the longer it takes for a browser to download all the static files. And the longer your app is being downloaded, the more annoyed your users may be. As front-end developers, we are responsible for making our users as little annoyed as possible. At least when it comes to performance.

"Lazy loading" could be the most basic strategy we can apply to make our application load faster if we consider FE-only mechanisms. The core idea of it is simple: if you don't need to use a piece of code immediately, you don't need to load it. And I really like this definition, but we will revisit it later. For now, let's take a look at the simplest example of applying lazy loading in an application.

Load your pages lazily

Consider, we have a simple application with 3 pages. The entire app is compiled into a single JavaScript file. Here's the code:

import { HashRouter, Routes, Route, Link } from 'react-router-dom';
import React, { Suspense } from 'react';

import Chapter1 from './pages/chapter-1/Chapter1';
import Chapter2 from './pages/chapter-2/Chapter2';
import Title from './pages/title/Title';

export const App = () => (
  <HashRouter>
    <nav className="navigation">
      <ul>
        <li><Link to="/">Title</Link></li>
        <li><Link to="/chapter-1">Chapter 1</Link></li>
        <li><Link to="/chapter-2">Chapter 2</Link></li>
      </ul>
    </nav>

    <Suspense fallback="Loading...">
      <div className="book-grid">
        <Routes>
          <Route path="/" element={<Title />} />
          <Route path="/chapter-1" element={<Chapter1 />} />
          <Route path="/chapter-2" element={<Chapter2 />} />
        </Routes>
      </div>
    </Suspense>
  </HashRouter>
);

When we open such a website, it can take about 580ms to download the only JavaScript file our application has.

We'd like to improve the loading time, but how can we achieve it? We can start loading pages lazily. Meaning that unless users want to see a certain page, they will not download its code. And this can be achieved quite easily. Instead of importing pages "Chapter1" and "Chapter2" statically, we should import them using dynamic imports. Plus, since we use React, we also must wrap those imports into React.lazy HOC:

import { HashRouter, Routes, Route, Link } from 'react-router-dom';
import React, { Suspense } from 'react';
import Title from './pages/title/Title';

const Chapter2 = React.lazy(
  () => import(/* webpackChunkName: "Chapter2" */ './pages/chapter-2/Chapter2')
);

const Chapter1 = React.lazy(
  () => import(/* webpackChunkName: "Chapter1" */ './pages/chapter-1/Chapter1')
);

export const App = () => (
  <HashRouter>
    <nav className="navigation">
      <ul>
        <li><Link to="/">Title</Link></li>
        <li><Link to="/chapter-1">Chapter 1</Link></li>
        <li><Link to="/chapter-2">Chapter 2</Link></li>
      </ul>
    </nav>

    <Suspense fallback="Loading main...">
      <div className="book-grid">
        <Routes>
          <Route path="/" element={<Title />} />
          <Route path="/chapter-1" element={<Chapter1 />} />
          <Route path="/chapter-2" element={<Chapter2 />} />
        </Routes>
      </div>
    </Suspense>
  </HashRouter>
);

And, voilà - now all of a sudden, it only takes 270ms to download the app initially. We managed to halve the time.

The sole purpose of lazy loading is postponing the load of our files by requesting them only when they are actually needed. In the case above, the code of pages Chapter 1 and Chapter 2 will be downloaded only when these pages are open.

And one of the main benefits of using lazy loading is that it allows us to decrease the initial loading time of our application. And there are a couple of reasons on why we should care about "initial" loading time a lot:

It is the most important delay in the user's perspective. Until we download initial files, users are unable to interact with our website. And if we are talking about client-rendered applications, users won't even be able to see any content until we download initial files.
Initially loaded files lose cache more often than other files and therefore caching optimizations are not as efficient for them as for other files. We will cover the root cause of this problem in Part 3

However, this mechanism helps with overall loading time as well. If we want to open a certain page from the very beginning, let's say Chapter 1, it still takes less time (~470ms) than it was before applying lazy loading (~580ms).

Therefore, to simplify, we could say that lazy loading is a win-win optimization approach that can optimize loading time and improve UX of a web application.

To give you a perspective of how useful lazy loading can be in real applications, I'll tell you about my real project I currently work on. My application is designed to display a lot of diverse data: it has tables, charts, graphs, video players, and even code editors. Therefore, it uses quite a few UI and other NPM libraries. If I sum the size of all the generated files of the assembly, the total size of my project will exceed 22 MB. Without any lazy loading, users would need to download all 22 MB initially. But if we start loading pages lazily, users will need to download 0.5-6 MB of files only to display a single page. In my case, loading pages lazily led to 77-97% improvement of how fast static files are downloaded.

And that's it. The concept is indeed quite simple, but the devil is in the details. During this series we will dive much deeper. But for now we are ready to form the first rule on our journey to make an app indefinitely lazy:

📌 In most cases, loading your pages lazily must be the default approach. Regardless of how many pages there are in a project, or how large these pages are.

Lazy loading is not only about pages

However, if we are only using lazy loading for pages, like in the example above, we're not getting the full benefits of this mechanism. We certainly can do better. Let's repeat the definition once again.

📝 If you don't need to use a piece of code immediately, you don't need to load it.

A page is indeed a good example of a React component, which isn't required to be displayed immediately. But what else can be loaded lazily? The answer is simple: almost anything!

Other components also can be loaded lazily. Modal windows, side sheets, tab sections, or pop-ups. We don't need to display them straight away in most cases. And what do we do when we don't need to use the code immediately? We don't download it. The concept of the ideal lazy loading implementation is straightforward: unless a component is tiny and trivial, it should be loaded lazily.

There are also several reasons to use lazy loading beyond just pages:

Each of these components may have unique logic. A modal window or a side sheet may have dozens of unique form field validations. A tab section might be as contentful as a full-fledged page. And they all might contain built-in data-URI or SVG images, their own styles, their own utility methods, and sometimes they may even have unique NPM dependencies.
Another problem is that there can be a lot of such components: dozens and sometimes hundreds. And sometimes they might be nested:
- a page may have tab sections, and one of them may contain its own tab sections, and so on.
- a modal window can be a wizard, or simply may be able to open another modal window, that can also open another modal window, and so on.

You get the idea. Of course, not all application has that level of component nesting. But the number of such components is also a problem. Sure, a single modal window may not affect performance that much. But dozens of non-lazy components can quickly add up.

To give you a perspective of a real application, I tell about my 2 last projects:

In my previous company, there wasn't much nesting, but about 1/5 of size of initial files was dedicated to displaying modal windows. And there wasn't any reason to do so from a business perspective. By starting to load them lazily, we managed to get a 20% improvement for the initial loading time.
However, in my current project, the level of nesting is crazy. Literally dozens of possibly lazy components can be concealed on a single page. One of the most visited pages of this app was 3.5 MB in size. And when I started to load all such components lazily, this page reduced its size to 1.1 MB, which is a 68% improvement.

But again, we can do even better. The good part about lazy loading is that we are not limited with loading lazily components only. We can also load lazily utility methods, classes, and even NPM packages.

For example, in my project, if a user has the admin role, they are able to execute some logic from Dev Tools' Console to simplify testing. And this logic is downloaded only if the role is active.
Or, if only a certain button requires to use a function from an NPM library, I download this library only when the button is clicked.

So, if you ever thought that lazy loading was just about page loading, you could explore other options to improve your performance. And now, the rule:

📌 Lazy loading is not only about page loading. You can lazily load modal windows, side sheets, pop-ups, tab sections, and even utility methods and NPM libraries.

Conclusion

That's it for today. Thank you for joining me on our journey to make our web applications indefinitely lazy. If you have any questions feel free to ask them in comments.

And to summarize this article, let's list the rules we learned today:

📌 In most cases, loading your pages lazily must be the default approach. Regardless of how many pages there are in a project, or how large these pages are.
📌 However, lazy loading is not only about page loading. You can lazily load modal windows, side sheets, pop-ups, tab sections, and even utility methods and NPM libraries.

But it was just the beginning. You can read the next article to dive even deeper:
How to make your app indefinitely lazy – Part 2: Dependency Graphs

Here are my social links: LinkedIn Telegram GitHub. See you ✌️

How can decorators simplify web form development

Aleksandrovich Dmitrii — Tue, 03 Oct 2023 14:55:35 +0000

Relatively recently, in TC39, a proposal for the implementation of decorators in ECMAScript reached the 3rd pre-final stage. A little later, MicroSoft released the 5th major version of TypeScript, where a new implementation of decorators started working out of the box without any experimental flags. Babel as well took the initiative, and in its documentation began to recommend using a new implementation of decorators. And all that means that decorators have finally begun to fully enter the lives of JavaScript developers.

And on this hype train, I decided to tell you how, using decorators, you can improve your Developer Experience when developing forms.

It is important to mention that in this article, I will write about an approach based on using the MobX library. So if you don't use it in your projects, the article may not be as useful as it could be. But you can consider reading it as a possible source of inspiration for how to develop web forms.

A little bit of background

In my previous project, I had to develop a lot of complex forms. Often, they consisted of several dozen fields.

Most of the fields had to be validated. Of course, simple validation rules, such as checking for the fullness of a field or checking for the validity of an email address, appear quite often. But sometimes these rules were incredibly complicated. For example, depending on what the user chooses in one field, the validation rules for another field could change. And in some cases, it was necessary to turn off the validation of one field with certain values of the other. And, of course, there could be several validation rules for each field, each of which had to issue its own error message.

But validation was only part of the necessary functionality. There must also be a form changes tracking. Relatively speaking, disable the submit button until the user makes some changes. But, again, there were dozens of fields on forms, so writing if's for each field was not the best solution.

The situation was aggravated by the fact that some fields could represent arrays and sets of data. And if the user deleted several values from such a field, and then entered the same values manually, the form should have understood that it had returned to its original state.

On top of this, the forms had to be able to reset the current state of the form to the original one. And of course, they had to be able to communicate with the server.

I considered using various libraries, such as React Hook Form or Formik, but these options did not suit me. At the scale of those requirements, the code, even with these libraries, turned out to be too cumbersome and difficult to maintain. So I started thinking about my own solution.

MobX Form Schema

The separation of representation and logic is where I started. It was necessary to think of a way to somehow describe the logic of the form in a separate function or object and somehow minimize the need to write repeatable code as much as possible.

In the end, I came to the conclusion that it is convenient to describe the logic of the form in a separate JavaScript class. Later in the text, I will call such a class a "form schema". Each property of such a class can represent a field in a form or perform some kind of utilitarian purpose. And with the help of decorators, you can assign the necessary logic separately for each property.

In its simplest representation, such an object is a regular MobX store. For example, the code snippet below shows the simplest example of a form schema consisting of two fields: "First Name" and "Last Name". So far, without any logic.

import { makeObservable, observable } from 'mobx';

export class BasicFormStore {
  name = '';

  surname = '';

  constructor() {
    makeObservable(this, {
      name: observable,
      surname: observable,
    });
  }
}

Form validation

What is field validation? This is one or more rules for checking the value of a field. In our case, the "field" is a property of the class. This means that several validation rules can be assigned to the corresponding property using the decorator: @validate.

import { FormSchema, validate } from '@yoskutik/mobx-form-schema';
import { makeObservable, observable } from 'mobx';
import { email, required } from 'path/to/validators';

export class LoginSchema extends FormSchema {
  @validate(required(), email())
  email = '';

  constructor() {
    super();
    makeObservable(this, {
      email: observable,
    });
  }
}

const schema = LoginSchema.create();
console.log(schema.isValid, schema.errors);
// false, { email: 'The field is required' }

schema.email = 'invalid.email';
console.log(schema.isValid, schema.errors);
// false, { email: 'Invalid email format' }

schema.email = 'valid@email.com';
console.log(schema.isValid, schema.errors);
// true, {}

You simply pass several validator functions to the decorator, and the schema validates the field value itself. If there are several validators, the schema applies them sequentially. And only if all the rules are successfully passed, the schema tells that the field is valid.

And again, we see the separation of the code. The logic of the form is kept separate from the declaration of validators. Of course, this is done on purpose. Thus, an approach to writing atomic validation functions is formed. And thanks to this, the general rules can be easily reused.

What does a validator function look like?

A validator function for a schema is simply a function that returns either a string or a boolean value.

export const required = () => (value?: string) => {
  if (value?.trim()) return false;
  return 'This field is required';
};

export const email = () => (value: string) => {
  if (/\S+@\S+\.\S+/.test(value)) return false;
  return 'Invalid email format';
};

export const minLength = (min: number) => (value: string) => {
  if (value.length >= min) return false;
  return `Should be at least ${min} characters.`;
};

If the function returns false, validation is considered successful. And if a string or true - no. Moreover, the string passed in the validator becomes an error message for the field.

As the 1st input parameter, the function receives the current value of the property. And in the case of complex validation, each validator function takes an entire schema with all the properties as the 2nd parameter.

The “confirm password” field must have exactly the same value as the “password” field. The date input field "From" must contain the date that was before the date in the "To" field. These are basic examples of when we need to use an entire schema for validation.

The example below shows a sign-up form with an example of validating the password confirmation field.

import { FormSchema, validate } from '@yoskutik/mobx-form-schema';
import { makeObservable, observable } from 'mobx';
import { email, minLength, required } from 'path/to/validators';

const confirmPassword = () => (
  // Let’s use the second argument in order to understand whether
  //  the “confirmPassword” is the same as “password”
  (confirmPasswordValue: string, schema: SignUpSchema) => {
    if (confirmPasswordValue === schema.password) return false;
    return 'Passwords mismatched';
  }
);

export class SignUpSchema extends FormSchema {
  // Email address field
  @validate(required(), email())
  email = '';

  // Password field
  @validate(required(), minLength(8))
  password = '';

  // Password confirmation field
  @validate(required(), confirmPassword())
  confirmPassword = '';

  constructor() {
    super();
    makeObservable(this, {
      email: observable,
      password: observable,
      confirmPassword: observable,
    });
  }
}

Conditional validation

As I pointed out earlier, sometimes there may be situations when validation needs to be turned off. Fields may be optional or hidden for some reason, and in some cases, validation needs to be disabled depending on the values in other fields.

Since the @validate decorator is already used for the declaration of casual validation, we cannot use it. But we can create its modifier: @validate.if. Such a modifier will work almost the same as the original one, with the only exception that, in addition to the array of validators, a predicate function needs to be passed, which tells whether validation is needed at the moment. If the predicate says that validation is not needed, the property is recognized as valid.

The example below shows a scheme of three fields:

Optional field for entering the email address.
A checkbox in which the user says that he has a pet.
And a field for entering the pet's name. If the checkbox is active, it is necessary to perform validation for the fullness of the field.

import { FormSchema, validate } from '@yoskutik/mobx-form-schema';
import { makeObservable, observable, runInAction } from 'mobx';
import { email, required } from 'path/to/validators';

const shouldValidatePetName = (_name: string, schema: ConditionalSchema) => (
  schema.doesHavePet
);

export class ConditionalSchema extends FormSchema {
  // or it can be @validate.if(email => !!email, [email()])
  @validate.if(Boolean, [email()])
  email = '';

  doesHavePet = false;

  @validate.if(shouldValidatePetName, [required()])
  petName = '';

  constructor() {
    super();
    makeObservable(this, {
      email: observable,
      doesHavePet: observable,
      petName: observable,
    });
  }
}

const schema = ConditionalSchema.create();
console.log(schema.isValid, schema.errors); // true, {}

runInAction(() => schema.doesHavePet = true);
console.log(schema.isValid, schema.errors);
// false, { petName: 'The value is required.' }

runInAction(() => schema.email = 'invalid.email');
console.log(schema.isValid, schema.errors);
// false, {
//   petName: 'The value is required.',
//   email: 'Invalid email format.',
// }

This is a fairly simple validation example. You can take a look at an example of more complex validation, including conditional validation and rules that use an entire schema, on the documentation site.

When the validation happens?

By default, the schema calculates the validation in the autorun function from the MobX library. Due to this, the validation of the property is recalculated automatically when it is changed. But also because of this, if other properties of the schema participated in the validation, when they are changed, the validation will be recalculated as well.

The same rule works for the validation condition function. If the desired property or a property that participates in the condition has been changed, the predicate function will be called again.

You should not worry about unnecessary recalculations. Thanks to MobX and MobX Form Schema optimizations, there are none of them. However, it is possible to disable automatic validation and start validating data manually. You can look at examples of manual validation at the link.

A brief summary of the validation

These advantages may seem subjective, but I really liked this approach in the design of the code. It is well-readable and well-maintainable. It is flexible enough, and even in complex cases, it does not force you to write sophisticated logic.

The downside may seem to be the need to write validators from scratch. Even the most basic ones. While other libraries supply them out of the box. But I have objections to this point:

Even the basic rules may differ for different projects. For example, validation of a phone number or email address in different countries.
The application can support multiple languages. And even within the same language, there may be situations when the same rule in different fields should give different error messages.

Both of these points lead to the need to provide functionality for overriding or configuring basic validators. But as you've seen for yourself, basic validators can consist of 3 lines of code. And for me, it's better to write 3 lines of code from scratch than to write them for the configuration of the out-of-the-box functionality.

What's also great is that MobX From Schema works with decorators of both new and old implementations. But the new one has good typing support. Therefore, I can't pass a validator for a number to a string property.

const rule = () => (value: number) => {
  if (value > 0) return false;
  return 'The value must be greater than 0';
};

export class SignUpSchema extends FormSchema {
  // a typing error here, since `rule` must work with number properties
  @validate(rule())
  email = '';
}

The track of form changes

Now let's move from validation to tracking form changes. It is not difficult to understand that the form has been changed. First, you need to save the initial state of the form. Secondly, at the desired moment, it is enough to use such a piece of code:

const isChanged = currentValue1 !== initialValue1
  || currentValue2 !== initialValue2
  || ...;

This is an effective and simple way, but it is only suitable for simple forms. The more fields there are in the form, the longer this condition will be and the more difficult it will be to maintain such code.

But this is not the only problem. In addition to simple text fields, there may be more complex fields in the form. For example, on most career-based websites, there’s a field for specifying your skill set. And the value of such a field should, in fact, be either an array or a set. And a simple reference comparison will not help here to understand whether the state of the form has changed.

There is another approach: deep comparison.

import isEqual from 'lodash/isEqual';
const isChanged = isEqual(currentState, initialState);

This approach solves the problems described above. But then there are problems with unnecessary calculations. Ideally, the form must tell if it changed or not upon any user interaction. But for each change, calling for a deep comparison can be too heavy.

MobX allows you to work around both of these problems. In the form schema, when a certain field is changed, only the comparison that checks whether this particular field has been changed takes place.

And to activate the tracking of changes of a form, it is enough to use the decorator: @watch.

export class UserSchema extends FormSchema {
  @watch name = 'Initial name';

  @watch surname = 'Initial surname';
}

const schema = UserSchema.create();

console.log(schema.isChanged) // false

schema.name = 'New Name';
console.log(
  schema.isChanged,           // true
  schema.getInitial('name'),  // 'Initial name'
);

schema.name = 'Initial name';
console.log(schema.isChanged) // false

In this form, the isChanged flag will always be false if the first name is equal to "Initial name" and the last name is equal to "Initial surname". Even if the property changes its value to another one and then returns to its original state.

The @watch decorator uses the reference comparison and tells the schema whether the value of the property has changed from its initial state.

You may have noticed that I didn't call the makeObservable function in the example above. This is all because @watch applies observable.ref to properties by default. It is done for logical reasons - if you only need a reference comparison, you will hardly need deep observation through the observable. However, you can add it or any other observable modifications yourself without any problems.

More importantly, the schema itself does not remember its initial state. But if you apply the @watch, the scheme will save the initial state only for the desired fields. Thus, there is no overhead of memory consumption.

Complex objects tracking

Due to reference comparison, @watch is mostly needed to observe primitive values. It is a bit more complicated when it comes to observing objects. For example, when checking whether an array has been changed, we need to check the number of elements in the initial and current states and also check that the elements match at each of the positions.

But decorator modifiers come to our aid again. With their help, we can create such modifiers in which, instead of a reference comparison, there will be some other type of comparison. For example, if you want to use an array of values, use @watch.array, and if there is a set, use @watch.set. By default, these decorators will apply to shemas’s properties the observable.shallow.

import { FormSchema, watch } from '@yoskutik/mobx-form-schema';
import { runInAction } from 'mobx';

export class ArraySchema extends FormSchema {
  @watch.array skillsArray = ['HTML', 'CSS', 'JavaScript'];

  @watch.set skillsSet = new Set(['HTML', 'CSS', 'JavaScript']);
}

const schema = ArraySchema.create();

runInAction(() => schema.skillsArray = ['HTML']);
console.log(schema.isChanged, schema.changedProperties);
// true, Set(['skillsArray'])

runInAction(() => schema.skillsArray.push('CSS', 'JavaScript'));
console.log(schema.isChanged, schema.changedProperties);
// false, Set()

runInAction(() => schema.skillsSet.delete('CSS'));
console.log(schema.isChanged, schema.changedProperties);
// true, Set(['skillsSet'])

runInAction(() => schema.skillsSet.add('CSS'));
console.log(schema.isChanged, schema.changedProperties);
// false, Set()

Once again, new decorators work better with typings. You cannot apply @watch.array to not an array property nor @watch.set to not a set property.

Nested schemas tracking

Schemas can be nested. The simplest reason for this is the logical division of data. For example, in the user information form, information about his contacts can be a separate schema nested in the main schema.

import { FormSchema, watch } from '@yoskutik/mobx-form-schema';
import { runInAction } from 'mobx';

export class ContactsSchema extends FormSchema {
  @watch tel = 'default tel value';

  @watch email = 'default email value';
}

export class InfoSchema extends FormSchema {
  @watch name = '';

  @watch surname = '';

  @watch.schema contacts = ContactsSchema.create();
}

const schema = InfoSchema.create();

runInAction(() => schema.contacts.tel = 'new value');
console.log(schema.isChanged, schema.changedProperties);
// true, Set(['contacts'])

runInAction(() => schema.contacts.tel = 'default tel value');
console.log(schema.isChanged, schema.changedProperties);
// false, Set()

runInAction(() => schema.contacts = ContactsSchema.create());
console.log(schema.isChanged, schema.changedProperties);
// false, Set()

And, of course, such a nested separate schema can be used in the future without a parent scheme if such a situation is required.

In addition to this, you can use the @watch.schemasArray modifier in case you need to use an array of nested schemas. Such an array, for example, can be an array of working experience information blocks in a CV form.

In case you have some unusual data structure that requires an unusual comparison function, you can create a modification of the @watch decorator yourself. For this, you can use the watch.create method. But in order not to inflate the article too much, I will just modestly leave a link to the documentation if you are interested in looking at examples of using @watch.schemasArray and watch.create.

Restoring form to its original state

In some cases, the form restoring function may be useful. Especially in editing forms with pre-filled data from the server. And since we already keep the original state of the form, it is not difficult at all for us to restore the form to its original state.

import { FormSchema, watch } from '@yoskutik/mobx-form-schema';
import { runInAction } from 'mobx';

export class BasicSchema extends FormSchema {
  @watch name = 'Joe';

  @watch surname = 'Dough';
}

const schema = BasicSchema.create();

runInAction(() => {
  schema.name = 'new name';
  schema.surname = 'new surname';
});

console.log(schema.name, schema.surname); // 'new name', 'new surname'
schema.reset();
console.log(schema.name, schema.surname); // 'Joe', 'Dough'

And, of course, arrays, sets, nested schemas, and even your custom entities (if you describe them correctly) — all of them will be correctly restored.

A brief summary of the changes tracking

I will briefly mention that, as with validation, changes are tracked automatically. But, of course, the possibility of manually checking changes is also available.

And so, with just a couple of decorators and methods, fully automated tracking of form changes is ready. No matter how complex the scheme is or how many nested schemes there are in it, you can always understand whether your form has changed. And you can always restore it to its original state.

You can even create an IDE settings form schema. Usually, in such forms, there are many tabs, inside which there are nested tabs. And you can easily track changes and reset the form entirely, only at a specific tab or only at a nested tab.

At the same time, these observations are quite cheap. When a field is changed, only this field will be checked.

And, of course, the fact that @watch and its modifications are able to apply observable modifications from MobX on properties by themselves allows you to reduce your code even more.

Form communication with a server

Sometimes the data received from the server requires some kind of preprocessing before being used. For example, the server cannot send a Set or Date entity, but it may be more convenient for you to use the data in this format.

There may be a reverse situation, the server may require data in a different format from the one in which it is stored in a schema.

And usually, developers who experience such a need modify the data after receiving it, before using it, or before sending it. But with a form schema, such modifications can be described directly in the diagram.

Initialization

In the previous examples, you saw that to create a schema, you need to call the create static method. This method can accept an object as an argument, on the basis of which the schema can be filled with data.

import { FormSchema } from '@yoskutik/mobx-form-schema';

export class BasicSchema extends FormSchema {
  name = '';

  surname = '';
}

const schema1 = BasicSchema.create();
console.log(schema1.name, schema1.surname); // '', ''

const schema2 = BasicSchema.create({
  name: 'Joe',
  surname: 'Dough',
});
console.log(schema2.name, schema2.surname); // 'Joe', 'Dough'

And you can also describe how the data obtained in this method should be preprocessed before the scheme starts using it. To do this, you can use the @factory decorator.

import { factory, FormSchema } from '@yoskutik/mobx-form-schema';

const createDate = (data: string) => new Date(data);

export class BasicSchema extends FormSchema {
  @factory.set
  set = new Set<number>();

  @factory(createDate)
  date = new Date();
}

const schema = BasicSchema.create({
  set: [0, 1, 2],
  date: '2023-01-01T00:00:00.000Z',
});
console.log(schema.set instanceof Set, schema.date instanceof Date);
// true, true

Presentation

Since each schema contains utilitarian data and methods, it may be useful for you to get an object that contains exclusively useful data from a schema. To do this, you can use the presentation getter of the schema, which by default creates a copy of the schema without utilitarian methods and properties.

import { FormSchema } from '@yoskutik/mobx-form-schema';

export class BasicSchema extends FormSchema {
  name = 'Joe';

  surname = 'Dough';
}

const schema = BasicSchema.create();
console.log(schema.presentation);
// {
//   name: 'Joe',
//   surname: 'Dough',
// }

You can also use the @present decorator to change the contents of the presentation object. And you can even cut off some of its properties. For example, you hardly want to send the value of the password confirmation field to the server. To do this, you can use the @present.hidden modifier.

import { FormSchema, present } from '@yoskutik/mobx-form-schema';

const presentUsername = (username: string) => `@${username}`;

export class BasicSchema extends FormSchema {
  @present(presentUsername)
  username = 'joe-man';

  name = 'Joe';

  @present.hidden
  someUtilityProperty = 'utility data';
}

const schema = BasicSchema.create();
console.log(schema.presentation);
// {
//   name: 'Joe',
//   username: '@joe-man',
// }

And later, you can use this very presentation object when sending data to the server.

But how to use it in React?

I created MobX Form Schema as a package with a minimal set of dependencies. So it is not necessary to use React. The only thing needed is MobX - this one has to be in the project.

But nevertheless, I understand that in most cases, MobX is used with React, so I have prepared an example of using my library in a React application. But in order not to inflate the article, I'll just attach links to them: the web documentation, CodeSandbox.io, StackBlitz.com.

And just to keep you interested, I'll briefly show you how a component for displaying a form with the pet's name from the "Conditional Validation" section might look like.

export const ConditionalExample = observer(() => {
  const schema = useMemo(() => ConditionalSchema.create(), []);

  return (
    <form>
      {/* Since error output is standardized, TextField is able to display them itself */}
      <TextField schema={schema} field="email" type="email" label="E-mail" />

      <CheckboxField schema={schema} field="doesHavePet" label="I have a pet" />

      {schema.doesHavePet && (
        <TextField schema={schema} label="Pet's name" field="petName" required />
      )}

      <button type="submit">Submit</button>
    </form>
  );
});

So, does it mean that decorators are the silver bullet?

Am I trying to assert in my article that this approach to form development is the only correct one? No, of course, there are no silver bullets in development. But it really seemed to me that this approach simplifies the development process. And, importantly, it has almost no effect on the size of your bundle - apart from MobX itself, all the functionality that I described is stored in a package of less than 4 KB. And considering that you will have to write less code, you can only win in terms of the size of the bundle.

Moreover, this approach works well both on small-sized and on large-scale forms.

However, yes, you need MobX. At least in my implementation. If someone does something similar for other state managers, it will be interesting for me to see it.

The end

In the article, I showed most but not all the functionality of the form schema. I have not shown how validation and changes tracking work in manual mode; I have not shown all modifiers of the decorators. And in general, if you are interested in this approach to form development, I recommend that you visit the documentation site. There are a lot of useful things there, including useful scenarios for using the form schema.
I am waiting for your feedback in the comments. How do you like this approach in general?

A link to the npm package.

Bye.

Configurable typing of NPM packages. Typing may be stricter than you think

Aleksandrovich Dmitrii — Thu, 10 Aug 2023 14:51:58 +0000

In this article, I'd like to show how you can create NPM packages so that the user of your library (the developer) can configure the typing of your package. And I will also describe why and to whom it may be interesting.

Why do we need configurable typing?

Configuration of the executable logic of NPM packages is not something new. For example, in Axios, you can globally change the default components of requests, as well as globally change the logic of the requests themselves using the interceptors. And MobX, for example, provides the configure function, with which you can disable some checks or slightly change the default logic.

import axios from 'axios';
import { configure } from 'mobx';

// Example of global configuration of requests in Axios
axios.interceptors.response.use(
  // Due to the fact that this function returns not response,
  //  but response.data, the structure of the function result 
  //  becomes different. 
  (response) => response.data,
  // And thanks to this callback, we can output messages to 
  //  the console at certain server response statuses.
  (error) => {
    if (error.response?.status === 401) {
      console.error('User is not authorized');
    }
    if (error.response?.status === 404) {
      console.error('Not found');
    }
    return Promise.reject(error);
  }
);

// Example of configuration in MobX
configure({
  // This setting removes the verification of the correctness 
  //  of updating the observed fields
  enforceActions: 'never',
  // And this one allows you to use MobX without using the
  //  `Proxy` object
  useProxies: 'never',
});

But we are here to talk about configurable typing. What is it in general?

In the example above with axios, the structure of the result of the request function was changed. But TypeScript didn't notice this change. Accordingly, errors or other difficulties may occur at the compilation stage if you configure your requests in this way. However, if you had the opportunity to configure the typing of the function result, such problems would not arise.

Another example is decorators. If you follow TypeScript updates, you know that in its major fifth version there is a new implementation of decorators - proposal, a MicroSoft article. But if not, I'll tell you briefly. There were decorators in TypeScript before, but in a different implementation. And to use them, you had to configure tsconfig.json.

// file.ts
declare const oldExperimentalDecorator: PropertyDecorator;

export class Class {
  @oldExperimentalDecorator
  public property: number = 1;
}

// tsconfig.json
{
  "compilerOptions": {
    // ...
    "experimentalDecorators": true,
    "emitDecoratorMetadata": true,
  },
  // ...
}

Now the “old” decorators are still available. However, if experimentalDecorators: true is not specified in tsconfig in the fifth version, TypeScript will compile decorators in a new way. And will use the new typing.

declare const oldExperimentalDecorator: PropertyDecorator;
declare const newDecorator: <This, Value>(_: unknown, context: ClassFieldDecoratorContext<This, Value>) => void;

export class Class {
  // If `experimentalDecorators` in tsconfig is false, or not set
  // there will be a type error
  @oldExperimentalDecorator
  public property: number = 1;


  // If `experimentalDecorators` in tsconfig is true there will
  // be a type error
  @newDecorator
  public property1: number = 1;
}

And now imagine. You are creating an NPM package, and you want to make it possible to use decorators both in the old implementation and in the modern one. You can write logic so that your decorators work in both cases, but you will not be able to write typing so that TypeScript correctly analyzes your code in both cases. You cannot know in advance whether the developer of the final product has enabled the experimentalDecorators option.

And then configurable typing comes into play. You can give the developer the opportunity to say which typing he wants to use in his project. In the example above, the developer could say that he wants to use legacy or modern decorators.

Preparing for the dive

Before I describe how such a configuration can be implemented, it will not be superfluous for some readers to remind about some of the features of TypeScript.

Firstly, in TypeScript it is possible to “merge” interfaces. Thanks to this, you can extend the typing set using the interface keyword. To do this, you just have to declare an interface with exactly the same name as the interface you want to extend.

interface Interface {
  prop1: number;
}

interface Interface {
  prop2: number;
}

declare const value: Interface;

// We can use both prop1 and prop2 since our interfaces were merged
console.log(value.prop1, value.prop2);

Secondly, when you download an NPM package, its name - what is used in package.json - becomes the name of the module. Yes, if you didn't know, the name for the module is taken from this file, so you can, for example, download the axios library, but call it whatever you want.

// package.json
{
  "dependencies": {
    "@types/react": "^16.14.43",
    "@types/react2": "npm:@types/react@18",
    "axios": "^1.4.0",
    "axixixios": "npm:axios@1.4.0",
    "react": "^16.14.0",
    "react2": "npm:react@18"
  }
}

// file.ts
// And now we can use modules ‘react’, ‘react2’, ‘axios’ и ‘axixixios’
import axios from 'axios';
import axixixios from 'axixixios';
import React from 'react';
import React2 from 'react2';

And thirdly, you can change the typing of modules in your project. To do this, you can use the declare keyword. Using the export keyword, you can type a new exported entity. But what interests us more is that when declaring a module, you can also declare an interface. And if this module exports an interface with the same name, they will be merged.

import { FunctionComponent } from 'react';

declare module 'react' {
  interface FunctionComponent {
    newStaticProperty: number;
  }
}

declare const Component: FunctionComponent;

// There's no types error here, interfaces were merged
console.log(Component.newStaticProperty);

How do I set up configurable typing?

The examples below show typing within a single project for simplification. If you are interested in looking at a full-fledged example with the extension of the typing of individual NPM packages, you can visit my repository.

The knowledge described above is already enough so that we can extend the interface described in the external module. In the React example, we added a new static field to the typing of functional components.

However, using this mechanism, you can fully shift the responsibility for typing entities to the developer of the final product.

// file1.ts
export interface TypesConfiguration {}

// Type must be set in the final product. | undefined is not necessary
export const value: (TypesConfiguration extends {
  value: unknown
} ? TypesConfiguration[value] : never) | undefined = undefined;

// =====================

// file2.ts
import { value } from './file1';
import { expectType } from 'ts-expect';

declare module './file1' {
  interface TypesConfiguration {
    value: string;
  }
}
// There's no error. The type is `string | undefined`
expectType<string | undefined>(value);
// Error. The type is `string | undefined`
expectType<number | undefined>(value);

I have added the | undefined typing so that I can export a default undefined value. If I hadn't done this, then the value type would have been strictly the same as what we would have passed to the TypeConfiguration interface.

And you can also use conditional typing. Thanks to it, you can set the fallback to a less strict type for your entity, if a stricter typing has not been declared in the final product. Or you can switch your typing from one state to another as with a flag.

/ file1.ts
export interface TypesConfiguration {}

// Typed by flag. If flag is not used, type is string, otherwise - number. `| undefined` is not necessary
export const valueTypedByFlag: (TypesConfiguration extends {
  useNumber: true
} ? number : string) | undefined = undefined;

// Type must be set in the final product. If the type is not set, a fallback non-strict type is used
export const mapTypedWithFallback: TypesConfiguration extends { mapTypedWithFallback: unknown }
? TypesConfiguration['mapTypedWithFallback']
: Record<string, number> = {};

// =====================

// file2.ts
import { value, map } from './file1';
import { expectType } from 'ts-expect';

declare module './file1' {
  interface TypesConfiguration {
    // If useNumber: true is not passed, the type of `value`
    //  will be string
    useNumber: true;

    // If `map` is not passed, we can use any key in the map.
    //  But now only `key1` and `key2` are accessible
    mapTypedWithFallback: {
      key1: 1,
      key2: 2,
    }
  }
}


// No error since useNumber: true is used
expectType<number | undefiend>(value);

// No error
console.log(map, map.key1, map.key2);

// Error if `mapTypedWithFallback` is passed
console.log(map.randomKey);

But when it starts to be useful?

The approach to such typing will be useful mainly where the strictness of typing is important. For example, in large projects with several development teams. But to make it more clear to you, let me throw in some typical examples that show what real tasks configurable typing can solve.

Example with decorators

Let's go back to the example with decorators. As with the useNumber flag, we can tell the developer of the final library that he can add a flag to the TypesConfiguration interface that will be responsible for switching the type of decorators.

// file1.ts
export interface TypesConfiguration {}

export const decorator: TypesConfiguration extends { experimentalDecorators: true }
  ? PropertyDecorator
  : <This, Value extends number>(_: unknown, context: ClassFieldDecoratorContext<This, Value>) => void;

// file2.ts
import { decorator } from './file1';

declare module './file1' {
  interface TypesConfiguration {
    // Must be set to true only if it is set to true in the tsconfig file.
    experimentalDecorators: true;
  }
}

class Class {
  @decorator
  property: number;
}

Thus, the developer of the final product will be free to decide for himself which typing he wants to use on decorators. If he needs exclusively outdated decorators, he will need to switch the experimentalDecorators flag to true in tsconfig, and then specify experimentalDecorators: true in TypesConfiguration. Otherwise, you will not need to register anything in tsconfig and TypesСonfiguration.

Registration/Usage example

Another example that I notice relatively often in NPM packages is an approach with registration and usage of a certain entity by key. For example, I'll take the library Tyringe.

import { container } from 'tsyringe';

class A { prop1: number }
class B { prop2: string }

// The registration of an entity
container.register('ClassA', A);
container.register('ClassB', B);

// The usage. Types are applied by generic
const a: A = container.resolve('ClassA');
const b = container.resolve<B>('ClassB');

Some key and value are passed to the register function. And in the resolve function, you can retrieve a value using the key. In TSyringe, you can type the object received in the container.resolve function using a generic - which I did in the example above.

But this approach is not very safe. First, in the resolve function, you can pass a key that does not exist. Secondly, Syringe does not control typing in any way when using this function. Therefore when using a generic of the wrong type, no error will occur. It's not even close to be called strict.

// Typed as A, a valid case
const a: A = container.resolve('ClassA');
// Typed as A, although it is B
const b: A = container.resolve('ClassB');
// Typed as B, although it doesn’t exist
const c: B = container.resolve('Unknown token');

However, strictness can still be added. We can definitely say that by a certain key we should always receive an entity of a certain type.

// file1.ts
export interface TypesConfiguration {}

type KeyToClassMap = TypesConfiguration extends { registry: unknown }
  ? TypesConfiguration['registry']
  : Record<string, any>;

type Constructable<T> = { new (...args: unknown[]): T };

const map: KeyToClassMap = {}

export type TRegister = TypesConfiguration extends { registry: unknown }
  // @ts-ignore
  ? <Key extends keyof TypesConfiguration['registry']>(key: Key, Class: Constructable<TypesConfiguration['registry'][Key]>) => void
  : (key: string, Class: Constructable<any>) => void;

export const register: TRegister = (key, Class) => {
  map[key] = new Class();
};

export type TResolve = TypesConfiguration extends { registry: unknown }
  // @ts-ignore
  ? <T extends keyof TypesConfiguration['registry']>(key: T) => TypesConfiguration['registry'][T]
  : <T>(key: string) => T;

export const resolve: TResolve = (key) => map[key];

// =====================

// file2.ts
import { resolve, register } from './file1';

declare module './file1' {
  interface TypesConfiguration {
    // If we define registry here, our types become much stricter
    registry: {
      ClassA: A,
      ClassB: B,
    }
  }
}

class A { prop1: number }
class B { prop2: string }


// Can register only `A`
register('ClassA', A);
// Can register only `B`
register('ClassB', B);


// Can return only type A
const a = resolve('ClassA');
// Can return only B. Which is why `: A` type will cause an error
const b: A = resolve('ClassB');
// Unknown key will cause an error
const c = resolve('Unknown token');

In this case, our typing is as strict as possible. The developer will not be able to use the register function with a new key until they extend TypesConfiguration['registry']. And they will also not be able to use the resolve function with a key that does not exist, or incorrectly type the object returned in the function.

Do I need to use configurable typing in your package?

Depends on what problems it solves. If it already provides strict typing, if a scenario for changing the structure of your entities is unacceptable there, and if you don't export decorators, than no, you do not need it. But in the opposite case, you can estimate how much this approach can be useful to you.

If you still want to look in this direction, then I hasten to assure you that switching typing by flag and passing stricter typing will help you in implementing configurable typing almost always. At the very beginning, I gave an example of changing the structure of the request response in axios, and it is also quite possible to provide an opportunity for such a configuration using these techniques.

The end?

This work stemmed from my pet project, in which I was just working with decorators. I wanted to make them so that they work everywhere, but I met the problem with typing. And while I was studying the work of TypeScript to solve it, I didn't find a good solution. However, as it turned out, sometimes it's enough to look at the knowledge that you already possess from a different angle to solve your problem.

I hope it was interesting for you to read. As part of self-promotion, I will say that I recently wrote an article in which I conducted a benchmark of ECMAScript performance features. If you are interested in reading which compiler generates the most efficient code or which browser is more productive than others, you are welcome.

Once again, I will attach a link to the repository with full-fledged examples of type configuration in RPM packages with unit tests for types.

Here are my social links: twitter, mastodon, linkedin. And that's it. Bye.

In search of the best EcmaScript version for the website assembly

Aleksandrovich Dmitrii — Tue, 08 Aug 2023 14:00:03 +0000

As it turned out, choosing the ES version for building a web application, as well as organizing this assembly itself, can be a very difficult task. Especially if you are going to make this choice based solely on evidence. And in this article I will try to answer the following questions that have arisen during my investigation on this topic:

How does the compilation of code into ES5 affect site's performance?
Which tool generates the most efficient code — TypeScript Compiler, Babel or SWC?
Does modern syntax affect the browsers' parsing speed of JavaScript code?
Is it possible to achieve a real reduction of bundle’s size, taking into account the use of Brotli or GZIP, if you compile the code into a higher version of ES?
Is it really necessary to build sites in ES5 in 2023?
And also how we implemented the transition to a higher version of ES, and how our metrics have changed.

To answer questions 1–3, I even created a full-fledged benchmark, and I decided to test the fourth question on our real project with a large code base.

Is compiling into ES5 bad?

List of ECMAScript features updates every year and it really helps developers to reduce the amount of code and increase its readability. And to get the opportunity to use the latest version of ES in the source code, developers just need to configure the build process — configure the compilation, as well as add some polyfills.

Just a quick reminder for those who have forgotten why it is necessary to configure the assembly. For example, function Array.prototype.at appeared only in ES2022, and Chrome version below 92 does not know about the existence of such a function. Therefore, if you use it but didn’t think about ensuring backward compatibility, all users of older versions of Chrome will not be able to fully use your site.

Let me give you a couple of short examples on backward compatibility. First, you can add polyfills.

// After adding such polyfills
import "core-js/modules/es.array.at.js";
import "core-js/modules/es.array.find.js";

// You can safely you these functions
[1, 2, 3].at(-1);
[1, 2, 3].find(it => it > 2);

And second, you can use a compiler that will convert modern syntax code into code that is supported by older browsers:

// For example, this code
const sum = (a, b) => a + b;

// Using Babel or any other compiler can be converted into this code
var sum = function sum(a, b) {
  return a + b;
};

Well, I’ve never really liked the need for that backward compatibility. After all, it implies the mandatory generation of additional code, which in turn leads to an increase of the bundle’s size, clogging of RAM, and possibly a performance degradation of the application. And all this is provided that most (at least in our case) clients have a relatively recent version of the browser, which means that for them the backward compatibility can be potentially destructive.

That’s why it became interesting for me to answer the questions that I indicated at the beginning of the article. I decided to start my research by creating a benchmark. Its purpose is: isolated evaluation of the performance of features in assemblies compiled info ES5 by different tools (TypeScript, Babel, SWC), as well as in an assembly without compilation.

The experiment was performed only on features that require compilation, such as classes or asynchronous functions. I decided not to test the features depending on the use of polyfills, because if browsers already have an implementation of a specific feature, polyfills try not to insert their own implementation instead.

Benchmark description: parsing speed and performance test

As I wrote above, I’m going to evaluate each possible compiler separately, because the results of code generation of each compiler may differ. Therefore, in the benchmark, to test each feature, I created bundles compiled using TypeScript, SWC and Babel. You may object that it would be nice to check ESBuild as well, but at the time of writing, it was not capable of generating ES5 code, so I did not consider it.

Example of generated code difference:

// Such code
const sum = (a = 0, b = 0) => a + b;

// Babel will compile into this
var sum = function sum() {
  var a = arguments.length > 0 && arguments[0] !== undefined ? arguments[0] : 0;
  var b = arguments.length > 1 && arguments[1] !== undefined ? arguments[1] : 0;
  return a + b;
};

// And TypeScript into this
var sum = function (a, b) {
    if (a === void 0) { a = 0; }
    if (b === void 0) { b = 0; }
    return a + b;
};

In addition to these 3 builds, I created another one in which the code of the feature under test remained intact. I will continue to call this one “modern” in the text. Modern assembly will contain modern syntax.

I was also interested to check how different features work in different browsers. After all, browsers may have different engines or at least a different set of optimizations. This means that the benchmark results may potentially differ from one browser to another. And just to automate the collection of metrics in different browsers, I created a small HTTP server on NodeJS.

Each test involves opening the generated HTML file N times with a delay between runs. Each launch was performed in a new browser tab in private mode. Upon opening the HTML file, the browser runs the JavaScript code, and after its execution sends a request to the HTTP server with the result of the test iteration run. I tried to get metrics that would be maximally correlated with the metrics of First Paint, Last Visual Change and others similar to them.

First of all, I created the benchmark to determine the performance of the features, but it was also interesting to look at the impact of the features on the parsing speed. Thus, to evaluate the parsing speed, I created 4 additional builds, in which I simply multiplied the code from the assemblies to measure performance. And then I just measured how long it takes the browser to read the contents of the script element.

Benchmark results: not everything is so clear

We gradually came to the section with the results. Here, I made a bar chart for each version of the ES as well as for each syntax feature. Each graph shows the code execution speed for each of the builds in each of the browsers. The longest line on the graph means that the build worked the fastest.

Be careful — there are a lot of tests and graphs in this section!

Performance evaluation of ES features

ES2015 (ES6)

Arrow functions. As it turned out, there is a difference in the speed of executing the common and arrow functions. However, only for Chrome, Opera and other V8 browsers. There, the arrow functions work 15% slower. Apparently, in these browsers, controlling the context in which the function was created is more difficult than using your own context for each function.

Test source code.

Classes. In this test, there is a huge gap in the results of different compilers. Modern and TypeScript configurations showed significantly faster results. Basically, the modern configuration shows to be the most productive, apart from that Safari worked better with TypeScript. Babel and SWC generated the code 2–3 times slower.

Test source code.

In the test of using default parameters, the results are absolutely the opposite. SWC and Babel show similar results and work out the fastest. The slowest was the TypeScript build. The modern one has not gone far from TypeScript, but still shows itself a little more effective.

Test source code.

Iteration using the for..of construction. TypeScript is breaking all records again. Next comes the modern assembly, SWC and at the end is Babel.

Test source code.

Generators. Babel showed the fastest result among the compilers. With a modern assembly, not everything is so clear. In Safari it worked more effective than Babel. But at the same time, in Firefox, it is also the slowest. Apparently, the Firefox developers didn't think much about optimizing the generators. But if we don't take into account this browser, then I would say that the modern assembly shares the first place with Babel, and SWC and TypeScript together stand in second.

Test source code.

In the test of using enhanced object literals, the situation is also ambiguous. In general, TypeScript and modern builds are the most productive, in Firefox and Safari TS is the one who takes precedence, in V8 browsers it is modern. According to the chart, Babel turned out to be the slowest, but I think this was due to some side effect, and in a real project, the results of SWC and Babel would be the same.

Test source code.

Extremely unambiguous results came out in the test of using the rest parameters. The most productive configuration is modern, the slowest is TypeScript.

Test source code.

Spread operator. Definitely the modern assembly showed itself the fastest. In Chrome and Opera, the difference was as much as 4 times. The rest of the configurations showed themselves at about the same level, but in Firefox TypeScript worked slightly slower.

Test source code.

Template literals — again, the modern assembly has definitely shown itself to be more productive. There is no difference in the assemblies with different tools.

Test source code.

ES2016

Exponentiation operator. Absolutely no difference, everything is within the margin of error.

Test source code.

ES2017

Asynchronous functions. Modern assembly is again in the first place. The largest margin in Safari — it is up to 20%. There is a slight difference between other configurations, but it will not be possible to draw unambiguous conclusions — in Chrome and Opera, Babel is the slowest build, and in Firefox the fastest.

Test source code.

ES2018

Formally speaking, only two syntax features appeared this year — rest and spread operators in objects. However, I thought that 2 tests might not be enough. And all because, depending on how these operators are used, different tools generate code in different ways.

Here is a list of links to the sandboxes of the selected compilers, if you want to look at the variety of generated code:

Let’s start with a simple one. To evaluate the rest operator, I created 2 tests — in one I just copy the object, and in the other I take several properties from the object.

In the first case, the rest operator showed quite interesting results. Browsers seem to be divided into 2 camps: Chrome and Opera are optimized for working with TypeScript code, then the modern build shows itself best in terms of speed, and Babel and SWC are weaving at the end; but in Firefox and Safari the situation is absolutely the opposite — TypeScript works the slowest, and the results for the rest of the builds are almost the same.

In the second case, in all the same Safari and Firefox, the modern configuration wins everyone. But in Opera and Chrome, it is the slowest. Of the compilers, TypeScript was again a little slower than the rest of the assemblies.

Now let’s speak about the spread operator. I have written 4 tests using the spread operator in different configurations. But regardless of how I used the operator, the benchmark results turned out to be similar to the results for the rest operator — modern and TS builds work fast in Safari and Firefox, but just as slowly in Chrome and Opera.

In all tests, there is approximately such a picture. But if you are interested in looking at all the results, you can study them in the repository.

ES2018 Bonus

A funny fact that I discovered while writing the benchmark. If you have already looked at the source code of the tests, you noticed how I used the values 'a' + i as keys. And I did it on purpose! Because, as turned out, if you use a number as a key in an object, then for some reason unknown to me in Chrome and Opera, the modern assembly begins to work incredibly quickly. And not just faster than other builds in the same browsers, but even faster than Firefox or Safari, although they showed their superiority in the tests above.

Test source code.

ES2019

Private properties in classes. Again, an unconditional victory for the modern assembly. And TypeScript shows good results, apart from the tests in Safari. But anyway you shouldn’t rely on them — TypeScript, unlike other assemblers, is not able to compile private variables in ES5.

Test source code.

ES2020

Nullish coalescing operator. Again, an unconditional victory for the modern configuration. And Babel proved to be the worst.

Test source code.

Optional chaining operator. TypeScript performed worse than other assemblies, but otherwise there is no difference.

Test source code.

ES2021

Logical operators. I was interested to check individually how they work, when assignment is applied and when not.

In the first case, the modern build shows itself slightly less productive in Chrome, but more productive in Safari. There is no difference between the compilers.

Test source code.

And in the second case, a modern assembly paired with TypeScript shows its superiority over other assemblies.

Test source code.

ES2022

Private methods in classes. The results are the same as in the class usage test. And TypeScript is still not able to use private modifiers in ES5. But in ES6, the ratio of results remains the same.

Test source code.

Parsing speed evaluation

In general, the trend to increase the speed of parsing was popular during OptimizeJS popularity period. A lot of time has passed since then, the developer of this library himself marked it obsolete, and the V8 developers described the practices used in it as destructive. Therefore, now the front-end developers do not chase a couple of milliseconds won. And I too wasn’t going to, of course. But still, I was wondering if using modern syntax could affect the browser’s speed of reading JavaScript code.

I ran the tests, and got a couple of interesting results. For example, it turned out that Safari reads arrow functions slower than common ones, despite the fact that the file with arrow functions has the smallest size.

And Firefox processes code with private properties in the class for quite a long time. And it’s funny that it reads private methods without that much difficulty.

This is where the interesting facts end. In other cases, the benchmark results show a clear correlation of time and the number of characters in the generated code, which means that in other cases, parsing of a modern assembly proved to be the most effective. If you want to see the results in detail, here is the link.

A brief summary of the benchmark

The entire text described above can be summarized with 3 main ideas.

The modern assembly does not have absolute superiority over ES5 and sometimes even performs slower. However, it is the fastest in most cases.
There is no ideal tool for building the most productive code in ES5. At least because of the fact that different browsers have different optimizations. But you can choose for yourself the best ratio of pros and cons. For example, if suddenly there’s a huge amount of generators in your application, Babel will be a very obvious choice, and if there are a lot of classes, it’s worth looking towards TypeScript.

I would say that TypeScript often performs better than other tools. However, it upsets me that in some places where it feels good in Safari, in Chrome it is able to show the worst result. Especially considering the fact that the majority of users on Chrome.
We can conclude that not all browsers have paid attention to optimizing work with modern syntax. Firefox works terribly with generators, Chrome hasn't fine tuned spread in objects, etc. However, it seems to me that if browsers are engaged in under-the-hood optimizations, they are more likely to pay attention to modern syntax. So who knows, maybe in a couple of years the modern assembly will definitely be the fastest.

And what about the bundle size?

The favorite phrase of developers still compiling into ES5 sounds like this:

“Well, what’s the point of chasing a reduction in the size of the bundle? Compression tools will level out all this difference anyway.”

And whether they are right in their reasoning, we will find out now.

I decided to check this point on my working project, because compression is a rather complex process, and therefore it would not be entirely fair to conduct an assessment separately for each feature.

During the tests, I removed the polyfills from the assembly. Then I compiled our project with each of these tools, compressed them using GZip and Brotli, and calculated the total volume of the created chunks of the application. And these are the results I got.

	Raw	GZip	Brotli
Modern	6.58 MB	1.79 MB	1.74 MB
TypeScript	7.07 MB	1.82 MB	1.86 MB
Babel	7.71 MB	1.92 MB	1.86 MB
SWC	7.60 MB	1.94 MB	1.86 MB

You may be surprised that Brotli showed worse results on TypeScript than GZip. This happened because I was running Brotli with a compression level of 2 (the maximum is 11). I decided to choose this compression level because it is as close as possible to the settings used in Cloudflare by default, which we use in our project.

And what do we see? The size of the project has really decreased by 7–15%, both in the raw and compressed versions. And here the decision is up to you. For someone such a difference will be insignificant, and for others, on the contrary, it will seem significant. For ourselves, we decided that this difference is big enough to try to use a modern assembly in production.

It turns out that the modern assembly gets another victory.

And once again, the table tells how TypeScript shows its superiority in terms of the volume of generated code over other libraries.

Is 4% so important?

From everything described above, a simple conclusion can be drawn. Users will get a nicer UX if your product is compiled in a higher ES version. Your web application will become more productive and also your bundle will be smaller.

However, at the same time, you need to understand that according to Browserslist, only 96% of users worldwide currently have ES2015 support, 95% have ES2017, and higher versions have even lower support.

Therefore, the conclusion can be made as follows:

If these 4% of users with outdated browsers are not so important to you, then it would be more logical to build a site in a fresh version of ES. For example, in ES2018.
If they are still important, but you do not have a very large project, or the increase in quality metrics is not very important to you, you can gather under ES5. Performance will not suffer critically from this.
But if users with outdated browsers are also important to you, as well as a slight increase in performance, you should think about creating two assemblies — modern and ES5 — and think about how to deliver the right assembly to the user. That’s exactly what we did in our company.

Our experience of using modern assembly

In general, the idea of separating assemblies in our product appeared long before my appearance in a company, I just improved it a little. Now we are assembling our application twice — one assembly is compiled in ES5 format with all the required polyfills, and another in ES2018 format with a very limited set of polyfills.

To the question of why chose ES2018. The higher we looked at the version of the standard, the less the difference between the builds of different versions was felt. We chose ES2018 as a kind of edge at which 95% of users will get a fast website, and at which the advantages of a modern build will be used to the maximum. We don’t keep private fields in the class, so the only difference between ES2018 and ES2022 is a small performance loss when using the nullish coalescing operator and, possibly, the logical operator. For sure we’ll get over this loss.

And now about how we implemented it. Especially for this article, I decided to create another repository, just to show how the assembly of the application can be organized taking into account the separation of assemblies. There I implemented a simplified implementation of our working variant. However, it still shows how you can organize not only the separation of JavaScript code assemblies, but also CSS. If you open the developer tools in the assembled site, you can see that even on this small project, you can get a reduction of files by 120 KB, which was 30% in my case. You can use the deployed assembly from this repository at this link.

And if you don’t want to look at the repository, then I will briefly describe how we determine on the client side which assembly needs to be downloaded. We are just checking the browser’s ability to handle asynchronous functions, as well as the presence of several polyfills. And then, using the window.LEGACY flag, we add a script with the desired address to the head of the document.

try {
  // Polyfills check
  if (
    !('IntersectionObserver' in window) ||
    !('Promise' in window) ||
    !('fetch' in window) ||
    !('finally' in Promise.prototype)
  ) {
    throw {};
  }

  // Syntax check
  eval('const a = async ({ ...rest } = {}) => rest; let b = class {};');
  window.LEGACY = false;
} catch (e) {
  window.LEGACY = true;
}

Real metrics

Of course, metrics in a vacuum is a good thing, but what about real metrics? In the end, we deployed a strict separation of assemblies on ES5 and ES2018 on the production. And here is such a difference in metrics Sitespeed.io we received on different builds:

First Paint — 13% faster;
Page Load Time — 13% faster than;
Last Visual Change — 8% faster;
Total blocking time — 13% less;
Speed Index — 9% faster.

For the most part, this difference was achieved due to the smaller size of the downloaded files. But in any case, the transition to ES2018 could slightly affect the metrics for the better. And the best part is that this gain was obtained almost without touching the source code.

The end

Thank you for your time. I hope you, like me, were interested in learning about performance, parsing speed, and the metrics obtained.

I highly recommend looking at the benchmark repository. In the article, I described the conclusions only on the performance of assemblies, but in the benchmark I also wanted to look at the difference in the performance of browsers in different OS and architectures. For example, you can find out if Microsoft’s assurances that Edge is faster than Chrome are true or not.

I will also once again give a link to the repository with an example of organizing the separation of assemblies not only JavaScript but also CSS code. And in addition to it, a link to GH pages with the deployment of this assembly.

Here are my social links: twitter, mastodon, linkedin. And that’s it. Bye!

Extremely reducing the size of NPM packages

Aleksandrovich Dmitrii — Sat, 05 Aug 2023 10:39:15 +0000

One day I wanted to create a small NPM library for all the “best practices” - with test coverage, nice documentation, maintaining valid versioning and changelog, etc. I even wrote an article that described in detail what issues the library solves and how to use it. And one of the tasks that I was interested in when creating it was the task of minimizing the size of the output NPM package - the code that will be used by another programmer. And in this article I would like to describe what methods I applied to in order to achieve the desired goal.

I myself believe that developers of NPM packages should pay special attention to what size of the package they provide to other developers. Because even if the developers of the final product use even the most advanced minifiers, they will not always be able to achieve maximum optimization of the output bundle size, if the developers of NPM packages don't help.

By the way, I'll talk only about those packages that will be bundled into client code. The material below is not relevant for backend packages.

Part one. General advices

I decided to split the article into two parts. In the first one, I will tell you about general tips, e.g. about setting up dependencies or the assembly process. And it's necessary to resort to them.

In the second part I will tell how you can write code to make the package even smaller. And there, some tips will be “extreme” - they can greatly affect on the package size, but also dramatically degrade the developer experience. Therefore, applying those technics is up to you.

Importing third-party packages

Let's start with the simplest and most understandable one. There are a few simple rules on how you should import the code of third-party packages.

First, if you are creating a library in which you are sure that both you and the developer of the final product will use a certain third-party package, you should mark it as an external dependency. For example, if you are developing a UI Kit for React applications, you should mark 'react' as an external dependency.

Example of external dependency configuration in Rollup

import { nodeResolve } from '@rollup/plugin-node-resolve';
import commonjs from '@rollup/plugin-commonjs';

export default {
  input: 'main.js',

  output: {
    file: 'bundle.js',
    format: 'iife',
    name: 'MyModule'
  },

  plugins: [
    // nodeResolve и commonjs are needed for enabling
    //  the opportunity to import modules.
    nodeResolve(),
    commonjs(),
  ],

  // And here you declare a list of external dependencies
  external: [
    'react',
  ],
};

If a package as marked as an external library it's code wan't be bundle into your package's code.

// If this is your code
import find from 'lodash/find';
export const getPositiveNumbers = (arr: unknown[]) => find(arr, it => it > 0);

// And you marked lodash/find as an external dependency
// This will be your NPM package code
import e from"lodash/find";let o=o=>e(o,e=>e>0);export{o as getPositiveNumbers};

// But if lodash/find is not marked, the content of lodash/find
// will be inserted into your code entirely, so your package
// will grow by 14 KB.

And the second main tip is - there should be a minimum number of imports in your library. More on this below.

Polyfills

It is not necessary to import any polyfills to increase compatibility with different browsers. This, if necessary, will be handled by the developer of the final product. If both you and another developer paste a polyfill, it will be applied twice, and often minifiers will not be able to get rid of such dublicated code.

At the same time, there may be situations when the presence of some polyfills is critically important for the proper functioning of your package. For example, if it uses old version decorators, it is very likely that you will need the 'reflect-medata' package. But even in this case, you don't need to import anything yourself. It is better to point out this need in the documentation of your package, so the developers of the final product will handle it by themselves. Responsibility for importing polyfills should always fall on the shoulders of them.

What to do when you use TypeScript and your package needs typing from a polyfill? For example 'reflect-metadata' extends the typing of the Reflect object. And it may seem that since it is impossible to import a package, then it won't be possible to get typing from it. But no, it is quite possible to import typing without importing JavaScript code.

To do this, it is enough to create a file with the extension *.d.ts, in which you must import the polyfill, and then you must specify this file in your tsconfig.json. And voilà! The necessary typing has appeared in your project, and there will be no code from a third-party package, because files with the extension *.d.ts, in principle, cannot generate JavaScript code.

Example of importing typing without importing JavaScript code

global.d.ts

import 'reflect-metadata';

tsconfig.json

{
  "compilerOptions": {
    ...
  },
  "include": [
    "src",
    // It's important to set your created d.ts file
    "global.d.ts"
  ],
}

Utility packages

The situation with utility packages is a bit more complicated. It is quite logical to use some kind of utility package if it already implements the functionality you need. However, if you don't know how does the Tree Shaking work, how is the imported library assembled, and how do the minifiers work, you can suffer greatly from the overgrown size of your package.

In the example above, I used lodash and got extra 14 KB. However, the situation could become even worse. Take a look at the example below. Functionally, I wrote 2 identical imports. However, in the first case, after import, the size of the packages increases by 70 KB. Almost 5 times more. And all because in the first case I imported the entire library, and in the second only a specific file.

import { find } from 'lodash';
import find from 'lodash/find';

Therefore, I highly recommend you not to use 'lodash' in your NPM packages in 2023. Most of the function it provides are already built in JavaScript.

It is important to know a couple of simple rules about import utility packages.

If the functionality you need is simple, then the easiest way is not to import, but to copy the function and apply the practices described in the second part of the article to it. So, you can not only get rid of potential import overhead, but also further optimize the size of the output file.
Try to use libraries where the Tree Shaking mechanism is available. This mechanism will allow you to delete imported third-party code that is not actually used. To put it simply, every time you write import { … } from 'package'. You are referring to a file that contains all the exported library entities - functions, classes, etc., which means that in reality all these entities get into the final bundle, even if only one function was imported. But thanks to Tree Shaking, unused imports are simply deleted at the compilation stage in the production mode. This mechanism is only available if the package is assembled in ESM format, i.e. using the import/export syntax.
If the package is not assembled in ESM format, try to import only the necessary code, as I did in my example. Lodash acted very humanely and split the functions into separate files. And if you can only import the file you need, then do so.
If you want to use a package that is written in Common JS format (where require is used) and that consists of only one file, then this is a bad package. Don't use it. The developer of this package has not thought about how other developers will use it. Go back to the first point and write or copy the function yourself. But! Of course, we are talking only about those packages where, in addition to the functionality you need, there is unnecessary code there. If you need the whole library, you don't have to suffer like this.

Minifiers

Minifiers are used to reduce the size of the bundle. They can remove unused code, shorten expressions, and so on. And Now there are already several popular minifiers, and they continue to appear: more familiar ones - written in JavaScript - Terser and UglifyJS, even Babel has its own version of the minifier, there are also more modern SWC (written in Rust) and ESBuild (written in Go), and a bunch of other lesser-known minifiers. And I recommend you to look at this repository. It contains up-to-date test results of various popular minifiers.

And here is a brief description of these tests.

Different modifiers can provide different level of optimisation. The difference in top 5 is on average 1-2%, but in total the difference can reach 10% between different minifiers.
The difference in the speed of the minifiers can differ dramatically - hundreds of times. However, I will not talk about the speed of work in this article - now we only need the quality of compression.

Different minifiers can give different results on your project. If you really want to achieve the minimum file size, you can run the tests yourself and find the best minifier for yourself.

As for myself and as for now, I prefer using SWC's minifier. It can convert const into let, it doesn't add extra braces by default as Terser does, it can inline your variables and so on.

By the way, speaking of extra braces. If you didn't know, terser and some other tools add such extra braces, because OptimizeJS benchmark showed, that it affects on the speed of javascript code parsing. But later, V8 developers describe such technics destructive. And also the main developer of OptimezeJS abandoned his project. So, if you notice your tools generate extra braces - try to remove it.

EcmaScript version

EcmaScript features can be divided into 2 groups - those that add new objects or expand their API, and those that change the syntax of the language. Here is another repository, it conveniently contains all the ECMAScript features by year with their description and examples. If you look at the ES2017 update, then the first group of features would contain the Object.values and Object.entries features, and the second group - asynchronous functions.

Interestingly, the backward compatibility support in older browsers for these features is implemented differently in different groups. For the features of the first group, you need to add polyfills, and as mentioned above, the developer of the NPM package should not do this. But with the features of the second group, everything is more complicated.

If the old browser sees the async keyword, it will not understand what it is about, no matter what polyfills are used. Therefore, the second group of features must be compiled into the form that the browser perceives.

const func = async ({ a, b, ...other }) => {
    console.log(a, b, other);
};

Compiled code into ES5

"use strict";
var __awaiter = (this && this.__awaiter) || function (thisArg, _arguments, P, generator) {
    function adopt(value) { return value instanceof P ? value : new P(function (resolve) { resolve(value); }); }
    return new (P || (P = Promise))(function (resolve, reject) {
        function fulfilled(value) { try { step(generator.next(value)); } catch (e) { reject(e); } }
        function rejected(value) { try { step(generator["throw"](value)); } catch (e) { reject(e); } }
        function step(result) { result.done ? resolve(result.value) : adopt(result.value).then(fulfilled, rejected); }
        step((generator = generator.apply(thisArg, _arguments || [])).next());
    });
};
var __generator = (this && this.__generator) || function (thisArg, body) {
    var _ = { label: 0, sent: function() { if (t[0] & 1) throw t[1]; return t[1]; }, trys: [], ops: [] }, f, y, t, g;
    return g = { next: verb(0), "throw": verb(1), "return": verb(2) }, typeof Symbol === "function" && (g[Symbol.iterator] = function() { return this; }), g;
    function verb(n) { return function (v) { return step([n, v]); }; }
    function step(op) {
        if (f) throw new TypeError("Generator is already executing.");
        while (g && (g = 0, op[0] && (_ = 0)), _) try {
            if (f = 1, y && (t = op[0] & 2 ? y["return"] : op[0] ? y["throw"] || ((t = y["return"]) && t.call(y), 0) : y.next) && !(t = t.call(y, op[1])).done) return t;
            if (y = 0, t) op = [op[0] & 2, t.value];
            switch (op[0]) {
                case 0: case 1: t = op; break;
                case 4: _.label++; return { value: op[1], done: false };
                case 5: _.label++; y = op[1]; op = [0]; continue;
                case 7: op = _.ops.pop(); _.trys.pop(); continue;
                default:
                    if (!(t = _.trys, t = t.length > 0 && t[t.length - 1]) && (op[0] === 6 || op[0] === 2)) { _ = 0; continue; }
                    if (op[0] === 3 && (!t || (op[1] > t[0] && op[1] < t[3]))) { _.label = op[1]; break; }
                    if (op[0] === 6 && _.label < t[1]) { _.label = t[1]; t = op; break; }
                    if (t && _.label < t[2]) { _.label = t[2]; _.ops.push(op); break; }
                    if (t[2]) _.ops.pop();
                    _.trys.pop(); continue;
            }
            op = body.call(thisArg, _);
        } catch (e) { op = [6, e]; y = 0; } finally { f = t = 0; }
        if (op[0] & 5) throw op[1]; return { value: op[0] ? op[1] : void 0, done: true };
    }
};
var __rest = (this && this.__rest) || function (s, e) {
    var t = {};
    for (var p in s) if (Object.prototype.hasOwnProperty.call(s, p) && e.indexOf(p) < 0)
        t[p] = s[p];
    if (s != null && typeof Object.getOwnPropertySymbols === "function")
        for (var i = 0, p = Object.getOwnPropertySymbols(s); i < p.length; i++) {
            if (e.indexOf(p[i]) < 0 && Object.prototype.propertyIsEnumerable.call(s, p[i]))
                t[p[i]] = s[p[i]];
        }
    return t;
};
var func = function (_a) { return __awaiter(void 0, void 0, void 0, function () {
    var a = _a.a, b = _a.b, other = __rest(_a, ["a", "b"]);
    return __generator(this, function (_b) {
        console.log(a, b, other);
        return [2 /*return*/];
    });
}); };

implementations of the possibility of creating asynchronous functions (__await, __generator) and for the possibility of using the rest operator (__rest). The compiler also wrote additional code so that instead of using the object destructor in the function argument, there was an ES5 compatible syntax.

The compiled code looks like a mess. In order to provide backward capability, compiler generated __await and __generator functions because of presence of the async keyword and __rest function because of rest parameter.

The task of the NPM package developer is to decide which ES version to compile its code into. If you used asynchronous functions, and then compiled the library for ES5, then you will create extra code. If the developer of the final product does the same, the code for asynchronous functions will be added twice. And if, on the contrary, he compiles the library for ES2017, it turns out that in the end your code backward capability in unnecessary, and you could simply use modern syntax with async/await.

“Old Believers” may think that it is still most logical to compile the code into ES5 (or even into ES3), because in this way the developer of the final product may not use tools like Babel if he needs ES5. And, for me, they will be wrong. ES6 (ES2015) is now supported by 98% of browsers; support for those browsers that do not use it is either ending or planned to be completed; and therefore there is now a clear trend away from the rejection of compilation in ES5. At the same time, compiling ES6 —> ES5 can have the most significant impact on the package size in comparison with other transitions, because ES6 has brought a lot of improvements to the syntax of the language. In addition, the ES6 syntax is necessary for the tips described in the second part of the article.

Also, using old syntax can affect your performance, but this take is for another article.

Then what version of ES should we compile the code into? If you are writing code for your own use - for yourself or for the project you are working on - specify the version that is specified in the main project. And for the rest of the developers, I would advise to use ES6. All in the name of compatibility. But don't forget to specify in your documentation which version of ES you are using. Just in case to let other developers understand your package may need additional compilation.

But that's not all. You don't just have to compile code for a specific version. You should also be careful to use the syntax of later versions of ES in comparison with the one you are going for. For example, if you compile a package into ES2015, you should not use features from ES2017, e.g. asynchronous functions.

That's not that scary

Most of the features in the new versions of ES are exclusively "sugar". Instead of asynchronous functions, you can use Promises, instead of Object.entries - Object.keys, instead of Array.prototype.includes - Array.prototype.find. And if there is still no analog of the functionality, you can write it yourself.

// ESNext syntax
const func = async () => {
  const result = await otherFunc();
  console.log(result);
  return result.data;
};

// ES6 syntax
const func = () => {
  return new Promise(resolve => {
    otherFunc().then(result => {
      console.log(result);
      then(result.data);
    });
  });
};

// ==================

// ESNext syntax
if ([1, 2, 3].includes(anyConst)) { /* ... */ }

// ES6 syntax
if (!![1, 2, 3].find(it => it === anyConst)) { /* ... */ }

// ==================

// ESNext syntax
Object.entries(anyObj).forEach(([key, value]) => { /* ... */ });

// ES6 syntax
Object.keys(anyObj).forEach(key => {
  const value = anyObj[key];
  /* ... */
});

It would be important to add, that although with caution, but using polifill based features is allowed. But syntax-based is a big "no-no".

Production/Development assemblies separation

A short but interesting topic. If suddenly you want to leave some functionality that only the developer should see - for example, validation of function parameters, error output to the console, etc. - you should split the assemblies, and leave this additional functionality only in dev assemblies.

A lot of package do it, like React, MobX or Redux Toolkit. And it's actually quite simple to organise.

Source code

export const someFunc = (a: number, b: number) => {
  if (__DEV__) {
    if (typeof a !== 'number' || typeof b !== 'number') {
      console.error('Incorrect usage of someFunc');
    }
  }

  console.log(a, b);
  return a + b;
};

rollup.config.js

import typescript from '@rollup/plugin-typescript';
import define from 'rollup-plugin-define';

export default [false, true].map(isDev => ({
  input: 'src/index.tsx',
  output: {
    file: `dist/your-package-name.${isDev ? 'development' : 'production'}.js`,
    preserveModulesRoot: 'src',
    format: 'esm',
  },
  plugins: [
    typescript(),
    define({
      replacements: {
        __DEV__: JSON.stringify(isDev),
      },
    }),
  ],
}));

Output dev version

const someFunc = (a, b) => {
    {
        if (typeof a !== 'number' || typeof b !== 'number') {
            console.error('Incorrect usage of someFunc');
        }
    }
    console.log(a, b);
    return a + b;
};

export { someFunc };

Output prod version

const someFunc = (a, b) => {
    console.log(a, b);
    return a + b;
};

export { someFunc };

Let's formalize it. It is enough for you at the compilation stage of your code to replace some sequences of characters (in my case __DEV__) with the desired value - true or false. Next, you need to use the created flag in the condition. When the flag is substituted in the code, the conditions if (true) { ... } and if (false) { ... } are obtained. And then the if (false) {... } code is cut off, because it will never be called.

Having two files, you need to somehow substitute them into the assembly of the developer of the final product. Before that, it is enough to refer to the NODE_ENV environment variable in your main package file. At the same time, the developer of the final product does not have to configure this variable when using your package - Webpack, for example, configures it by itself.

And in order to use a valid file, you must add a condition into your main file.

// process.env.NODE_ENV sets on the final project side
if (process.env.NODE_ENV === 'production') {
  // using production version
  module.exports = require('./dist/react-vvm.production.js');
} else {
  // using development version
  module.exports = require('./dist/react-vvm.development.js');
}

In addition, I can also say that it there's no need to minify the dev assembly of the package. It's "dev", therefore the developer can actively interacts with it. And it is extremely difficult to interact with minimized code.

Part two. Worse DX, but better outcome

The developers of the final product can afford to write code so that it is convenient for him - their code base will be larger by default. The developer of the NPM package has a smaller codebase, and therefore it is much affordable to write sometime less "beautiful" code to reduce the final size.

And this is due to the fact that the minifier is not a magic tool. The developer must work with him in tandem - he writes the code in a certain way so that the minifier can squeeze his code even more.

Repeatability and reusability

This is, of course, a general practice, but it also affects the size of the package. There should be no repeatable code.

Function creation

If there are pieces of code in the code that are repeated - partially or fully, try to separate the repeated functionality into a separate function. I think this item does not need an example.

Object's properties

There are also a couple of interesting things with objects. If you use the expression object.subObject.field in the code, the minifier will be able to compress this expression to a maximum of o.subObject.field, because the minifier does not know whether further compression is safe. Therefore, if you often refer to the same field in an object, create a separate variable for it and use it.

Example before optimization

Source code:

import { SomeClass } from 'some-class';

export const func = () => {
  const obj = new SomeClass();
  console.log(obj.subObject.field1);
  console.log(obj.subObject.field2);
  console.log(obj.subObject.field3);
};

Minified code (182 bytes)

For clarity, I added line breaks and indents, but the file size is specified without them.

import {SomeClass as o} from "some-class";

const e = () => {
    const e = new o;
    console.log(e.subObject.field1), console.log(e.subObject.field2), console.log(e.subObject.field3)
};
export {e as func};

Example after optimization

Source code:

import { SomeClass } from 'some-class';

export const func = () => {
  const obj = new SomeClass();
  const sub = obj.subObject;
  console.log(sub.field1);
  console.log(sub.field2);
  console.log(sub.field3);
};

Minified code (164 bytes)

import {SomeClass as o} from "some-class";

const e = () => {
    const e = (new o).subObject;
    console.log(e.field1), console.log(e.field2), console.log(e.field3)
};
export {e as func};

The next optimization can be called extreme since it does worsen DX. If you have to frequently use a specific property or a method in an object, you can create a variable of the name of such property or a method.

Example before optimization

Source code:

import { useEffect, useLayoutEffect, useRef } from 'react';

export const useRenderCounter = () => {
  const refSync = useRef(0);
  const refAsync = useRef(0);

  useLayoutEffect(() => {
    refSync.current++;
  });

  useEffect(() => {
    refAsync.current++;
  });

  console.log(refSync.current, refAsync.current);

  return {
    syncCount: refSync.current,
    asyncCount: refAsync.current,
  };
};

Minified code (254 bytes)

import {useRef as r, useLayoutEffect as e, useEffect as t} from "react";

const n = () => {
  let n = r(0), u = r(0);
  return e(() => {
    n.current++
  }), t(() => {
    u.current++
  }), console.log(n.current, u.current), {syncCount: n.current, asyncCount: u.current}
};
export {n as useRenderCounter};

Example after optimization

Source code:

import { useEffect, useLayoutEffect, useRef } from 'react';

const CURRENT = 'current';

export const useRenderCounter = () => {
  const refSync = useRef<number>(0);
  const refAsync = useRef<number>(0);

  useLayoutEffect(() => {
    refSync[CURRENT]++;
  });

  useEffect(() => {
    refAsync[CURRENT]++;
  });

  console.log(refSync[CURRENT], refAsync[CURRENT]);

  return {
    syncCount: refSync[CURRENT],
    asyncCount: refAsync[CURRENT],
  };
};

Minified code (234 bytes)

import {useRef as e, useLayoutEffect as r, useEffect as t} from "react";

const n = "current", o = () => {
  let o = e(0), u = e(0);
  return r(() => {
    o[n]++
  }), t(() => {
    u[n]++
  }), console.log(o[n], u[n]), {syncCount: o[n], asyncCount: u[n]}
};
export {o as useRenderCounter};

The more times current is used, the more effective this optimization will be.

Using ES6 syntax

Using ES6 syntax in conjunction with a minifier can be a good way to shorten your code.

Using arrow functions

In terms of compressibility, arrow functions are better than classical ones in everything. For two reasons. Firstly, when declaring arrow functions in a row via const or let, all subsequent const or let except the first one are shortened. Secondly, arrow functions can return values without using the return keyword.

Example before optimization

Source code:

export function fun1() {
  return 1;
}

export function fun2() {
  console.log(2);
}

export function fun3() {
  console.log(3);
  return 3;
}

Minified code (126 bytes)

function n() {
    return 1
}

function o() {
    console.log(2)
}

function t() {
    return console.log(3), 3
}

export {n as fun1, o as fun2, t as fun3};

Example after optimization

Source code:

export const fun1 = () => 1;

export const fun2 = () => {
  console.log(2);
};

export const fun3 = () => {
  console.log(3);
  return 3;
}

Minified code (101 bytes)

const o = () => 1, l = () => {
    console.log(2)
}, c = () => (console.log(3), 3);
export {o as fun1, l as fun2, c as fun3};

Object.assign and spread operator

This is a specific case of the general rule described in the first part. There weren't such thing as spread operator in objects in ES6. Therefore, if you are compiling your library under ES6, I would recommend that you use Object.assign instead of this operator.

Example before optimization

Source code:

export const fun = (a: Record<string, number>, b = 1) => {
  return { ...a, b };
};

Minified code (76 bytes)

const s = (s, t = 1) => Object.assign(Object.assign({}, s), {b: t});
export {s as fun};

As you see, Object.assign may apply twice.

Example after optimization

Source code:

export const fun = (a: Record<string, number>, b = 1) => {
  return Object.assign({}, a, { b });
};

Minified code (61 bytes)

const s = (s, t = 1) => Object.assign({}, s, {b: t});
export {s as fun};

Try to return the value in the arrow function

Another optimization from the "extreme" category. If this does not affect the functional component, you can return the value from the function. The savings will be small, but they will be. It works, however, in cases when there is only 1 expression in the function.

Example before optimization

Source code:

document.body.addEventListener('click', () => {
  console.log('click');
});

Minified code (68 bytes)

document.body.addEventListener("click",()=>{console.log("click")});

Example after optimization

Source code:

document.body.addEventListener('click', () => {
  return console.log('click');
});

Minified code (66 bytes)

document.body.addEventListener("click",()=>console.log("click"));

Stop creating variables in functions

Another optimization from the category of "extreme". In general, trying to reduce the number of variables is a normal idea for optimization - the minifier gets rid of them if it can do inline code insertion. However, the minifier cannot get rid of all variables independently for the same security reasons. But you can help him.

Look at the compiled file of your library. If it has functions in the body of which there are some variables, then you can use the function argument in your code instead of creating a variable.

Example before optimization

Source code:

export const fun = (a: number, b: number) => {
  const c = a + b;
  console.log(c);
  return c;
};

Minified code (71 bytes)

const o=(o,n)=>{const t=o+n;return console.log(t),t};
export{o as fun};

Example after optimization

Source code:

export const fun = (a: number, b: number, c = a + b) => {
  console.log(c);
  return c;
};

Minified code (58 bytes)

const o = (o, c, e = o + c) => (console.log(e), e);
export {o as fun};

This is a pretty strong optimization, because in the end it can help get rid not only of const, but also of return keywords in the assembled file. But keep in mind that such optimization should be applied only on private class methods and on functions that are not exported from your library, because you should not complicate the understanding of your library's API with your optimization.

Minimal use of constants

Again, the "extreme" advice. In the assembled code, in principle, there should be a minimum number of uses of let and const. And for this, for example, all constants can be declared in one place one after another. At the same time, the advice becomes extreme only if we try to declare literally all constants in one place.

Example before optimization

Source code:

export const a = 'A';

export class Class {}

export const b = 'B';

Minified code (67 bytes)

const s = "A";

class c {}

const o = "B";
export {c as Class, s as a, o as b};

Example after optimization

Source code:

export const a = 'A';
export const b = 'B';

export class Class {}

Minified code (61 bytes)

const s = "A", c = "B";

class o {}

export {o as Class, s as a, c as b};

General advice for extreme reduction

In fact, you can come up with a lot of tips. Therefore, summarizing, I decided to simply describe how the assembled minified file should look like. And, accordingly, if your output file does not match the specified description, it has a lot to squeeze.

There should be no repetitions. Repetitive functionality can be allocated to functions, frequently used object fields need to be written to constants, etc.
The amount of non-abbreviated code should be kept to a minimum. This includes the frequently repeated use of this, the use of nested objects or methods, etc. It is highly desirable that the minimized file contains exclusively single-letter expressions.
The number of function, return, const, let and other keywords should also be kept to a minimum. Use arrow functions declared via const, declare constants in a row, use arguments instead of declaring a constant in functions, etc.

And the most important thing. It makes sense to resort to extreme reduction only when all other optimizations have already been applied and only if it does not affect the functionality of your package. And also, once again, optimization should not affect the API (and, therefore, typing).

Conclusion

It might seem to you that there is no point in extreme compression, because in my examples I got a maximum gain of a couple dozen bytes. But in fact, I specifically made them minimally representative. In real conditions, the gain can be much greater.

But in the end, whether or not to resort to the use of “extreme” advice is up to you. For me, it was more of a challenge to myself about whether I could achieve the minimum possible file size. But in case you are still wondering how useful they are, I can say that they helped me reduce the size of my library from 2172 bytes to 1594. That on the one hand only 578 bytes, but on the other as much as 27% of the total packet volume.

Thank you for your attention, you can share your opinion in the comments. I hope my article was useful for you - if not extreme advice, then at least general. It is likely that I did not specify something in my article. In this case, I will be happy to supplement it according to your suggestions.

MobX with MVVM makes Frontender's life much easier than Redux does

Aleksandrovich Dmitrii — Sun, 13 Nov 2022 07:51:22 +0000

In this article, I would like to discuss how well the MVVM pattern is suitable for developing applications on React. Also, I'm going to describe what advantages there may appear when developing using MobX and the MVVM pattern in comparison with Redux. Stock up on coffee, this is gonna be a long read.

In general, if you analyze the articles that compare MobX and Redux, you will notice several frequently repeated theses:

"Modx is easier to learn than Redux"
"MobX is more productive than Redux"
"You need to write less code in MobX than in Redux"
However, "Scaling with Redux is easier than with MobX", and therefore "MobX is suitable for small applications, and Redux for large ones"
"Debugging Redux is easier than MobX"
"Redux's community is much bigger than MobX's"
"MobX gives too much freedom"

Here are a couple of examples of such articles

It's silly to deny that in comparison with Redux, MobX's community is not so big. For example, the number of downloads at npmjs.com for Redux is 8 times bigger than for MobX. However, I can hardly agree with the other disadvantages.

It seems to me, that debugging problems are either purely subjective, or appear as a result of poor application architecture. For example, I have never experienced any problems with the MobX debug.

The scaling point also looks strange for me. The bigger the application becomes with Redux, the more selectors it has, the more logic in the reducers, the more middleware, the slower it becomes. No matter how the code with Redux is optimized, performance will definitely fall when scaling. On the other hand, MobX, in terms of performance, can expand quite painlessly. Therefore, I assume that the authors of such articles talk about problems in scaling in the context of writing new code. In this case, it is again a problem of poor architecture.

Well, and here we are. There's a reason, why I highlighted the problem of excessive freedom in MobX. This problem is real. There are several ways to create and use stores. For example, you can use them in the component by importing, by injection, or create them in the component. There are incredibly many approaches to using MobX in React. And MobX doesn't even try to recommend any one "good" approach. And due to the fact that it's "easy to learn", this problem is only getting worse, since, having quickly learned the basic concepts of MobX, some developers believe that they definitely know exactly how to make up the architecture.

But the problems with the architecture is not directly related to MobX. It's weird to blame a gun if you shot your leg. The problem is that developers didn't choose any particular approach to using this tool. But it is not necessary to work out the approach from scratch at all - the existing concepts works very well with creating architecture. And as you probably guessed, in this article I will try to show how the MVVM pattern can sufficiently form the strictness, the lack of which is mentioned in such articles.

What is the MVVM pattern?

The main advantage of the MVVM (Model View ViewModel) pattern is the separation of GUI development and logic.

Look at the short example

import { action, observable, makeObservable } from 'mobx';
import { view, ViewModel } from '@yoskutik/react-vvm';

class CounterViewModel extends ViewModel {
  @observalbe count = 0;

  constructor() {
    super();
    makeObservable(this);
  }

  @action increate = () => {
    this.count++;
  };
}

const Counter = view(CounterViewModel)(({ viewModel }) => (
  <div>
    <span>Counter: {viewModel.count}</span>
    <button onClick={() => viewModel.increate()}>increase</button>
  </div>
));

And I'm talking about a complete separation of logic and appearance. In the MVVM approach, your smart components can consist of JSX code exclusively. With such a short example, I just wanted to interest you. But before describing the benefits, let's outline how MVVM can be used in React applications.

MVVM in the React applications

For myself, I have identified only 4 rules for MVVM implementation:

Every viewmodel must be linked to the view and, therefore, when the view is unmounted, the viewmodel must "die";
Each viewmodel can (and often will) be a store;
This store can be used not only in the component that created the viewmodel (i.e. inside the view), but also in all child components of the view;
The view and the viewmodel know about each other's existence.

What is the awareness of the view and the viewmodel about each other? In the React application, the view will be created by React. Therefore, the view have to be responsible for creating the viewmodel. In turn, the viewmodel knows about view's props and is able to process different logic at different stages of the view's life cycle.

And now about benefits

Surely, you have wondered: "But why should the viewmodel die when the view becomes unmounted?". The answer is quite simple. If the component is no longer in the virtual DOM, there is probably no need to store data and methods to display this component. This optimization allows you to free up application memory when some pieces of data are not being used.

And this is just the beginning.

Context API and Data Abstraction

The third "rule" of my implementation says that the viewmodel can be used at any depth inside the view. It's clear that this is about the Context API. And it is quite possible to use it together with the MVVM pattern.

Using MVVM with Context API

import { makeObservable, observable } from 'mobx';
import { childView, view, ViewModel } from '@yoskutik/react-vvm';

class SomeViewModel extends ViewModel {
  @observable field1 = '';

  constructor() {
    super();
    makeObservable(this);
  }

  doSomething = () => {};
}

// ChildView doesn't create a viewmodel and should be located
// somewhere inside a View. Thus, it can interract with SomeViewModel.
const ChildView = childView<SomeViewModel>()(({ viewModel }) => (
  <div>
    <span>{viewModel.field1}</span>
    <button onClick={viewModel.doSomething}>Click in a child of  view</button>
  </div>
));

const View = view(SomeViewModel)(({ viewModel }) => (
  <div>
    <span>{viewModel.field1}</span>
    <button onClick={viewModel.doSomething}>Click in a view</button>

    <ChildView />
  </div>
));

There is a fairly clear analogy with Redux, which exists exclusively on the Context API. However, there is a significant difference between the Redux and MobX approach with MVVM.

Look at these graphics

Each node in the graph in the diagram is a React component.

In the Redux approach, one store is created, and this store is available throughout whole application. In the MVVM approach, a store is created only for the view. And in this case, only 3 stores are created. At the same time, the blue store and the components using it do not know about the existence of the yellow and red stores, they cannot read their data in any way or somehow affect on them.

Unlike Redux, MVVM gives real data abstraction. For example, the data needed by one page can be visible only inside this page, and something that the modal window needs will be visible only to it.

Nested views

Now you could see some contradiction. I said that the view model should be accessible to any children of the view, and the diagram clearly shows that the red nodes have their own view model, but not the "yellow" one.

In such a case, an additional concept was introduced - the parent viewmodel. The parent viewmodel for "red" node will be "yellow" one.

And in the code, the use of the parent viewmodel may look like this

import { view, ViewModel } from '@yoskutik/react-vvm';

class ViewModel1 extends ViewModel {
  doSomething = () => {};
}

class ViewModel2 extends ViewModel<ViewModel1> {
  onClick = () => {
    this.parent.doSomething();
  };
}

// View2 should be located somewhere View1. Thus, ViewModel1 will
// become a parent viewmodel for View2
const View2 = view(ViewModel2)(({ viewModel }) => (
  <button onClick={viewModel.onClick} />
));

const View1 = view(ViewModel1)(({ viewModel }) => (
  <div>
    <View2 />
  </div>
));

But it is also interesting that the parent viewmodel can even be an interface. If a certain view can be used inside different views, whose viewmodels implement some single interface, then you can specify it as the type of the parent viewmodel.

Example of using a parent viewmodel with typing as an interface

import { view, ViewModel } from '@yoskutik/react-vvm';
import { ISomeViewModel } from './ISomeViewModel';

class ViewModel1 extends ViewModel implements ISomeViewModel { ... }

class ViewModel2 extends ViewModel implements ISomeViewModel { ... }

// The type of parent viewmodel will be ISomeViewModel
class ViewModel3 extends ViewModel<ISomeViewModel> { ... }

const View3 = view(ViewModel3)(({ viewModel }) => (
  <div />
));

// View3 can be used in different views
const View1 = view(ViewModel1)(({ viewModel }) => (
  <View3 />
));

const View2 = view(ViewModel2)(({ viewModel }) => (
  <View3 />
));

It probably sounds complicated. But in practice it's quite simple. For example, let's say there is some widget in the project that can appear on several pages, and at the same time depend in the same way on these pages. All pages will have their own view models, but the widget display rules will be the same for each page. And these rules can be called the interface of the parent viewmodel.

Complete separation of logic and appearance

As I wrote above, in MVVM, the separation of logic and display can reach a new level. I incredibly like the concept that smart components can consist exclusively of JSX code. I think this greatly simplifies the analysis of React components.

Creating handlers in a viewmodel

Let's start with a simple one. Event handlers like onClick, onInput, etc. by definition of MVVM, can be declared in the viewmodel. In the very first example in the viewmodel, I created the increase function, which I then called in the component. But I could also name the function as onClick, then it would be possible to use it directly in the component.

const Counter = view(CounterViewModel)(({ viewModel }) => (
  <div>
    <span>Counter: {viewModel.count}</span>
    <button onClick={viewModel.onClick}>increase</button>
  </div>
));

By the way, such a declaration of handlers has a pleasant effect - all functions inside the viewmodel are memoized, which means they don't change when view renders. So you don't need to worry about using useCallback and other similar hooks when creating handlers in the viewmodel.

Viewmodel knows about the view's props

Even if event handlers somehow depend on the view's props, they can still be declared inside a viewmodel, because viewmodels know about view's props.

Example of using props in event handlers

import { FC } from 'react';
import { view, ViewModel } from '@yoskutik/react-vvm';

type WindowProps = {
  title: string;
  onClose: () => void;
}

class WindowViewModel extends ViewModel<unknown, WindowProps> {
  onCloseClick = () => {
    // do something else
    this.viewProps.onClose();
  };
}

export const Window: FC<WindowProps> = view(WindowViewModel)(({ viewModel, title }) => (
  <div className="window">
    <h1>{title}</h1>
    <button onClick={viewModel.onCloseClick}>close</button>
  </div>
));

And it also seemed logical to me to make the viewProps field observable. In this way, you can create reactions to changes in certain props. And such reactions are much easier to read for me than the reactions created in useEffect. Although, probably, this is a subjective opinion.

Example of a reaction with useEffect

import { FC, useCallback, useEffect } from 'react';

type WindowProps = {
  title: string;
  state: 'warn' | 'error';
  onClose: () => void;
}

export const Window: FC<WindowProps> = ({ title, state, onClose }) => {
  const onCloseClick = useCallback(() => {
    // do something
    onClose();
  }, [onClose]);

  useEffect(() => {
    console.log(state);
  }, [state]);

  return (
    <div className={`window window--${state}`}>
      <h1>{title}</h1>
      <button onClick={viewModel.onCloseClick}>close</button>
    </div>
  );
};

Example of a reaction with MVVM

import { FC } from 'react';
import { view, ViewModel } from '@yoskutik/react-vvm';

type WindowProps = {
  title: string;
  state: 'warn' | 'error';
  onClose: () => void;
}

class WindowViewModel extends ViewModel<unknown, WindowProps> {
  protected onViewMounted() {
    this.reaction(() => this.viewProps.state, state => {
      console.log(state);
    });
  }

  onCloseClick = () => {
    // do something else
    this.viewProps.onClose();
  };
}

export const Window: FC<WindowProps> = view(WindowViewModel)(({ viewModel, title, state }) => (
  <div className={`window window--${state}`}>
    <h1>{title}</h1>
    <button onClick={viewModel.onCloseClick}>close</button>
  </div>
));

Also due to the fact that viewProps is observable, there is an additional nice effect. If nested components will somehow depend on their view's props, then when updating the view's props, they will automatically trigger rerender for them.

Less dependence on lifecycle hooks

I already started talking about hooks in the previous block. There is no longer a need to create reactions to certain objects via useEffect. But useEffect is needed not only for reactions - it can also be used to handle the state of the component lifecycle. For example, when mounting, unmounting or updating. And all these stages of the life cycle may well be processed inside the viewmodel.

Example

import { observable, makeObservable } from 'mobx';
import { view, ViewModel } from '@yoskutik/react-vvm';

class ComponentViewModel extends ViewModel {
  @observable data = undefined;

  constructor() {
    super();
    makeObservable(this);
  }

  // For example, you can use this function instead of
  // useLayoutEffect(() => { ... }, []);
  protected onViewMountedSync() {
    fetch('url')
      .then(res => res.json())
      .then(res => this.doSomething(res));
  }

  // Or this function partially instead of
  // useEffect(() => { ... });
  protected onViewUpdated() {
    console.log('Some functionality after component updated');
  }

  doSomething = (res: any) => {};
}

export const Component = view(ComponentViewModel)(({ viewModel }) => (
  <div>
    {viewModel.data}
  </div>
));

Number of props

This is a small but very nice bonus. In smart components, the number of props can be reduced to a minimum. In my last project, on average, each smart component had no more than 3 props.

This is achieved due to the fact that there is no need for drilling props in MVVM. Child components of the view can directly access their viewmodel. If they or their view depends on the state of the parent view, they can refer to the parent field. If there is a dependency on the view's props, then you can refer to the viewProps field. In other cases, of course, you still have to pass props directly, but even such a small opportunity allows you to significantly reduce the number of props. Which affects not only the simplicity of code analysis, but also the performance of the application, because memoized components will have to check fewer props when updating.

Compared to Redux

To make you even more aware of the beauty of MobX with MVVM, I'll try to compare this approach with Redux.

Look at the example below. I've written the same logic as in the MVVM hooks example, but written in Redux.

Example with Redux

import { FC, useEffect, useLayoutEffect } from 'react';
import { useSelector, useDispatch } from 'react-redux';
import { IReduxStore } from '../../store';
import { doSomething } from './slice';

export const Component: FC = () => {
  const data = useSelector((state: IReduxStore) => state.slice.data);
  const dispatch = useDispatch();

  useLayoutEffect(() => {
    fetch('url')
      .then(res => res.json())
      .then(res => dispatch(doSomething(res)));
  }, []);

  useEffect(() => {
    console.log('Some functionality after component render');
  });

  return (
    <div>
      {data}
    </div>
  );
}

In this example, you can see the power of a complete separation of logic and appearence. In the example with Redux, the component is still responsible for updating the state. The actions are declared somewhere else, but they must be used inside the component. In the MVVM example, the view does not call hooks and does not process data in any way. The view only uses it.

What is also interesting is that there is the same amount of code in both examples. In fact, there is a bit more code in MVVM, but the code in the constructor can be avoided (more on this below). But at the same time, you still need to create a slice in Redux, and therefore you have to write more code in Redux.

In general, the amount of code is a separate pleasant bonus in comparison with MobX and Redux. I'm sure, developers who use Redux often think about how much repetitive code they have to write. Of course, Redux Toolkit improved the situation, but it didn't fully get rid of the repetitive code. You need to call a hook to get the store value; you need to call a hook to get the dispose function; you need to specify specific names for actions and/or slices; etc.

And typing. Redux Toolkit has simplified it quite a lot. But to me, it still looks like a crutch. Getting a store type based on the result of a function that returns it; creating a reducer with a certain type using an additional generic function; or the need to set the store type in each useSelector call. I can't say that these are pleasant solutions to use.

In the MobX, it is rarely necessary to think about typing. I created a viewmodel class and then use its object. And TypeScript will arrange all the typing itself.

At the same time, in Redux it is necessary to think about memoization. The amount of useMemo and useCallback per line of code in Redux may differ dramatically from this amount in MobX with MVVM.

And the props. In my practice, drilling of props is quite common in Redux, at least within nesting in 1-3 layers. And, as I wrote above, there are fewer such problems in MVVM.

But that's not all

I think you can agree, that MVVM already looks pretty good. But I decided to go even further and "level up" my MVVM implementation a little.

Automatic call of disposers

The MobX documentation says that you should always call dispose of reactions. This rule helps to avoid memory leaks problems. And following this rule is not very convenient. But not in the MVVM approach.

So, when do the reactions created in the viewmodel cease to be necessary for us? Considering that the viewmodel should die after view unmounting, then in most cases at the moment when the view is unmounted. Therefore, you can add an automatic call at this moment. In this case, reactions can be created using small add-on functions inside the viewmodel. At the same time, the interface and typing of these functions will not differ from their analogues in MobX.

Example of creating reactions with automatic dispose

import { intercept, makeObservable, observable, observe, when } from 'mobx';
import { ViewModel } from '@yoskutik/react-vvm';

export class SomeViewModel extends ViewModel {
  @observable field = 0;

  constructor() {
    super();
    makeObservable(this);

    // You can use this alias to create reaction
    this.reaction(() => this.field, value => this.doSomething(value));

    // You can also use this alias to create autorun
    this.autorun(() => {
      this.doSomething(this.field);
    });

    // And for other types of reactions you can use
    // addDisposer function

    // observe
    this.addDisposer(
      observe(this, 'field', ({ newValue }) => this.doSomething(newValue))
    );

    // intercept
    this.addDisposer(
      intercept(this, 'field', change => {
        this.doSomething(change.newValue);
        return change;
      }),
    );

    // when
    const w = when(() => this.field === 1);
    w.then(() => this.doSomething(this.field));
    this.addDisposer(() => w.cancel());
  }

  doSomething = (field: number) => {};
}

Flexible configuration

The MVVM approach can be flexibly customized. For example, my implementation allows you to customize how the viewmodel is created, and also allows you to assign a wrapper component for all views and childviews. And these 2 settings are much more powerful than you might think. Of course, these settings can be used for debugging, but this is not their main purpose.

For example, you can make the call of makeObservable automatic, so you don't have to call it in each viewmodel separately.

Automatic makeObservable call

import { makeObservable, observable } from 'mobx';
import { configure, ViewModel } from '@yoskutik/react-vvm';

configure({
  vmFactory: VM => {
    const viewModel = new VM();
    makeObservable(viewModel);
    return viewModel;
  },
});

class SomeViewModel extends ViewModel {
  // And now field1 will become observable. There's no need to call makeObservable.
  @observable field1 = 0;

  // However, in the constructor, the field is not yet observable, so
  // it is better to add reactions to onViewMounted or onViewMountedSync
  protected onViewMounted() {
    this.reaction(() => this.field1, () => {
      // do something
    });
  }
}

You can create a viewmodel in such a way that DI (Dependency Injection) pattern can be added to your project. And for me, this is a very nice bonus. Thanks to DI, you can create small independent stores that can be used in different parts of your project. And instead of depending on a virtual tree, with DI you can build dependencies in an absolutely free way.

Example with DI

import { computed, makeObservable, observable } from 'mobx';
// It's not necessary to use tsyringe, you can use and DI library
import { injectable, container, singleton } from 'tsyringe';
import { configure, ViewModel } from '@yoskutik/react-vvm';

configure({
  vmFactory: VM => container.resolve(VM),
});

// This is an example of small independent store
@singleton()
class SomeOuterClass {
  @observable field1 = 0;

  constructor() {
    makeObservable(this);
  }

  doSomething = () => {
    // do something
  };
}

@injectable()
class SomeViewModel extends ViewModel {
  @computed get someGetter() {
    return this.someOuterClass.field1;
  }

  // Thanks to DI we can use classes by simply set them in the constructor
  constructor(private someOuterClass: SomeOuterClass) {
    super();
    makeObservable(this);
  }

  viewModelDoSomething = () => {
    this.someOuterClass.doSomething();
  }
}

// You can also use singloton classes in any spot in your code
const instance = container.resolve(SomeOuterClass);

The possibility of configuring wrappers for each view also seemed to me a very interesting idea. I liked the possibility of using Error Boundary as a wrapper. In this case, all your views will be automatically wrapped in Error Boundary and you will have to think less about error handling during development. It may seem to you that this is a little excessive, but in reality not all components will be a view, but only those that contain a lot of logic.

Example with Error Boundary

import { Component, ReactElement, ErrorInfo } from 'react';
import { configure } from '@yoskutik/react-vvm';

class ErrorBoundary extends Component<{ children: ReactElement }, { hasError: boolean }> {
  static getDerivedStateFromError() {
    return { hasError: true };
  }

  state = {
    hasError: false,
  };

  componentDidCatch(error: Error, info: ErrorInfo) {
    console.error(error, info);
  }

  render() {
    return !this.state.hasError && this.props.children;
  };
}

configure({
  Wrapper: ErrorBoundary,
});

So, is MVVM the ultimate solution to all problems?

Congratulations, you have almost reached the end of the article. But, the aswer in no. Unfortunately, MVVM is not an ultimate solution to all problems.

MVVM allows you to solve many problems. I really like this pattern. But there's one serious problem. There are times when some data is needed in completely disparate parts of the project.

Graph again

Once again, this is a React component graph. I marked components that depends on the same data with yellow.

If such components are relatively close to each other, then it is quite realistic to place the data somewhere in the parent viewmodel. However, with increasing depth, the number of parents used may increase also. Agree, if you have to get data through viewModel.parent.parent.parent.data, then this is completely inconvenient. And if you store in the viewmodel the data that only a couple of children need at a huge depth inside, then the viewmodel will grow incredibly much.

And here we come back to the fact that we need to use some independent stores that are not tied to the virtual tree in any way, and therefore such stores are not affected by the strictness of MVVM in any way.

But there is a solution. And I even think that you probably already guessed what I'm talking about. The DI pattern can impose that strictness. And it fits pretty well with MVVM. And now MVVM + DI looks like a full-fledged solution for large projects, which will allow you to scale the project for a long time. However, I have already written a lot in the article, so I won't write much about DI. If you want, I could do this in my next article.

The end

Thank you for your time. Feel free to share your opinion in the comments, I will read them with pleasure.

And also, as I said, I have written a tiny library, literally 300 lines of code. You can use it if you want to play with the MVVM pattern. Here are the links: npm, github, documentation. And you can also look at a couple of examples of its use.