Besides, developers need to be sure that their code is as good as possible for caching. The big problem with code bandling is that any change to the code, even a single changed line, results in cache invalidation of the entire bandle. If you deploy an application consisting of thousands of small modules (represented exactly as they are in the source code), then you can safely make small changes to the code and still know that most of the application code will be cached. But, as I mentioned earlier, this approach to development can also probably mean that it can take longer to load code the first time you visit a resource than it would with more traditional approaches.

As a result, we face the challenge of finding the right approach to bandwagoning. We need to strike the right balance between the speed of loading materials and their long-term caching.

Most bandlers, by default, apply code splitting techniques with dynamic import commands in mind. But I would say that splitting code only with dynamic import orientation does not allow you to break it into small enough fragments. This is especially true for sites with many returning users (i.e. in situations where caching is important).

I believe that you should break code into as small fragments as possible. You should reduce the size of the fragments until the number of fragments grows so large that it affects the loading speed of the project. While I definitely recommend that everyone do their own analysis of the situation, if you believe the rough calculations in the study I mentioned above, there is no noticeable slowdown in loading speeds for less than 100 modules. A separate study devoted to HTTP/2 performance did not reveal any noticeable slowdown of the project when loading less than 50 files. There, however, they tested only variants where the number of files was 1, 6, 50 and 1000. As a result, 100 files is probably a value that can be used without fear of losing the download speed.

So, what is the best way to split code aggressively, but not too aggressively? In addition to code separation based on dynamic import commands, I would advise you to look at code separation by npm-packages. With this approach, what is imported into the project from the node_modules folder is placed in a separate fragment of the finished code based on the package name.

The post Optimal code building strategy appeared first on Moutjs.

Usually the code is divided into folders and files, and external libraries need to be attached. As a result, each of these files must be included in the main HTML file in the script tag, which is then loaded by the browser.

Having separate script tags for each file means that the browser will load each file separately, which negatively affects page load speed. To get around this problem, files are combined into a single file or a pair of files to reduce the number of requests. But there remains the problem of managing dependencies between modules.

If module systems such as CommonJS or ESM are used, a tool must be used to convert them into properly organized, browser-accessible code. This is where Webpack and other bundlers come into play.

ECMAScript Modules (ESM)

Until recently, the language did not have a built-in module system. ESMs have a compact declarative syntax and the ability to load asynchronously. An ES module is a reusable piece of JS code that exports certain objects, making them available to other modules.

Each JS file stores code in a unique module context and imports the dependencies it needs and exports anything that needs to be imported by other modules. The export/import operations are implemented by the import and export constructs. There are two obvious advantages of this approach – avoiding global namespace pollution and explicitly specifying dependencies.

The new module system differs from CommonJS and others, first of all, because it is a standard. Which means it will eventually be fully supported natively by browsers, without additional tools. However, now browser support is not complete, so ESMs are used in combination with module building tools such as Webpack, Parcel and others.

Named export

A module can export multiple entities that are distinguished by their names and are called named exports. To import them into another module, we need to know the names of the exported entities we want to import.

The first way is to use the export keyword in front of all the entities to be exported. They will be added as properties to the exported entity. When importing, we will destructure the properties from the imported entity.

Default export

Often a module will export just one entity, this export is convenient for importing. The default export is the most important exported value, which can be anything: variable, function, class, etc.

Use the named export when you want to export multiple entities, and the default export when you want to export a single entity. Although it is possible to use the default export and the named export in the same file, it is good practice to select only one style for each module.

The post Module assembly appeared first on Moutjs.

Maintainability: By definition, a module is self-sufficient. A well-designed module is intended to reduce the dependencies of parts of your codebase as much as possible, so that it can grow and improve independently of each other. It is much easier to update one module when it is separated from other parts of the code.Going back to our book, for example, if you want to make a small change to one chapter and it causes changes to some other section of your book, it will be a nightmare. So a chapter should be written so that when you make edits, you don’t have to affect other chapters.

Namespacing: In JavaScript, variables that are outside of top-level functions are considered global (anyone can access them). This is why it is very common to have “namespace pollution”, where completely unrelated code links global variables.Sharing global variables in code that is not related to each other is very bad in development.Later in this article we will see that modules allow us to avoid global namespace pollution by creating private spaces for our variables.

Reusability: Let’s be honest. All of us have copied code into new projects that we have written before. For example, let’s say you copied some helper methods from a previous project into a new project.Ok, but if you find the best way to write this part, you will have to remember all the places where this code appeared to update it.This is definitely a huge waste of time. It would be much easier to write a module and reuse it over and over again.

The post Why use modules at all? appeared first on Moutjs.