Links between browser, ESM specification, modularity, webpack, and vite?

The article comes from the public number: surprise code theft, author: chicken soup brother

preface

In layman's terms: J S, a language that doesn't have a modular system at the design point, will undergo a modular evolution until 2015, when TC39, a committee of browser vendor representatives, released the ES6 specification, known to the world as ESM. I n the process of modular evolution, the problems exposed by modularity itself are becoming more and more obvious. W ith more and more modules in the project, there is confusion in management, so there is an urgent need for tools to solve the problem of various module types. Tools such as webpack and vite are used to solve these problems.

From the development of browsers, the popularity of JS, to modular exploration, to the differences in building tools, there are a lot of knowledge points involved, here are a few simple columns:

• How the browser works
• The evolution of modularity
• The evolution of modular tools
• The evolution of webpack
• The birth of vite
• The choice of front-end developer

Browser with js

The browser parses the HTML document before rendering the page, outputting DOM elements and properties through the HTML parser.

Then build DOM tree and CSSOM tree. The two models are built independently of each other.

Finally, CSSOM tree and DOM tree are merged into a render tree, which is then used to calculate the layout of each visible element and output the drawing process to render pixels to the screen.

If the DOM or CSSOM is modified and needs to be rebuilt to determine which pixels need to be re-rendered on the screen, two points of knowledge are involved: repeat and reflow

While JS allows queries and modifications to DOM and CSSOM, the same JS blocks the build and rendering of DOM and CSSOM, so we'll load JS at the bottom of the HTML.

Most of the cores of today's browsers are divided into two parts: the rendering engine and the JS engine.

The rendering engine, which is responsible for interpreting and rendering web page syntax. We often say gecko engine, "edge", presto engine, webkit, blink engine, etc. are rendering engines.

The JS engine is designed to interpret, compile, and execute JS so that web pages can achieve dynamic results. The often-talked-about V8 engine is the JS engine.

js and modularity

In the js modularization process, CommonJS is commonly used on the service side, and AMD and CMD specifications are commonly used on the client side.

At first, CommonJS specialized in the service side, formerly known as ServerJS, but later changed its name to CommonJs in order to unify the front and rear ends. And just as the community was discussing the next version of the code, there was a big internal disagreement, splitting up three ideas and gradually forming three different factions:

• On the basis of the existing CommonJs to meet the needs of the browser, the existing modular into suitable for the browser side can be. The http://wiki.commonjs.org/wiki/Modules/Transport specification has been developed, and browserify is one such tool that compiles the nodejs module into the modules available to the browser.
• There is also a wave of people who think that the browser and the server environment is too different to follow the old standards, and the browser must load code asynchronously, then the module must be defined to indicate the module on which it depends, and then write the code of this module in the callback function. The module is also loaded through a download-callback process, which is also \ the basis for the idea of a https://github.com/amdjs/amdjs-api/wiki/AMD.
• The last wave of people, neither want to lose the old norms, nor want to be like AMD to come back. T hey think some of ComenJs's ideas are good, such as declaring dependencies through require, and that the new specification should be compatible with them, and that AMD has merit, such as preloading. Eventually they developed a "Modules/Wrappings" specification (http://wiki.commonjs.org/wiki/Modules/Wrappings).

The emergence of RequireJs was quickly accepted by developers. B ut RequireJs also has a spitting slot, where pre-download is not controversial, pre-execution is required? I f one module relies on ten other modules, execute the code for the other ten modules before executing the code for this module, whether or not they will be used immediately. This performance consumption cannot be ignored.

For The Unseemly PlaceS Of RequireJS, The Domestic Bull Yubo WrotE SeaJS. S eaJs embrace the Modules/Wrapping specification in its entirety, but not exactly in accordance with the Modules/Wrapping specification, and seajs do not use declare to define modules, but rather use the same define as requirejs. red. S imilarly, seajs implements the available download when needed to execute, providing the require.async API and supporting CommonJs and RequireJs on how modules expose APIs to the outside world. Since seajs fuses too much to say which specification it follows, Uber simply stands on its own, known as the CMD (Common Definition Module) specification.

CommonJs, AMD, CMD, etc. mentioned above are community-based rather than official. O fficially, the buzz of the community was so high that js Modular finally released the official version of ES6 in 2015. Since then ESM has been born.

The ES6 module is designed to be as static as possible, allowing the compilation to determine the module's dependencies, as well as the input and output variables. C ommonJS and AMD modules can only determine these things at runtime. For example, the CommonJS module is an object, and you must look for object properties when you enter it.

CommonJs is run-time load, and ES6 is compile-time load. M aybe you don't understand the two keywords of compiling and running. C ommonJs loads the module first, outputs an object, and does not change internally after output. E S6, on the other hand, is a language-level change that outputs a reference that refers to the data type-reference type of JS. Value output is not valued until execution.

Modular and build tools

For module loading and transmission, we can first think of two extreme ways:

• One is that each module file is requested separately
• The other is to package all the modules into one file and request them only once

Obviously, each module makes a separate request, resulting in too many requests, resulting in slow application startup, and a single request to load all modules results in wasted traffic and slow initialization. Neither approach is a good solution, they are too simple and crude.

Block transfer, lazy loading on demand, in the actual use of some modules when incremental updates, is a more reasonable module loading scheme.

To implement on-demand loading of modules requires a process of static analysis, compilation and packaging of modules throughout the code base.

But our project is not just js ah! T here are resources such as pictures, styles, fonts, html templates, and so on. A t compile time, the entire code is statically analyzed, the types of modules and their dependencies are analyzed, and the different types of modules are then submitted to the appropriate loader for processing. So the build tool came into being.

About the build tool You can view a previous article, "The Big Mess of Front-End Build Tools."

Webpack stands out because of its philosophy: Everything is a module.

There's also a story about webpack, Tobias Koppers is the creator of the Webpack repository, Tobias's web nickname is sokra, and then we're called sokra, and sokra hasn't written a web page, which is interesting, and a person who hasn't written a web page invented the cornerstone of contemporary web development.

Sokra started out writing about Java, which has a well-known technology called GWT (Google Web Toolkit), which converts Java code into JavaScript, which means having the back end write the front end, essentially doing a layer of code transformation at the AST level, and Babel does it, but GWT is not popular and Google isn't promoting it.

There was a feed in GWT called "code splitting", so he mentioned a problem to the Bundle node .js Ku modules-webmake, which he used to do the front-end project, in the hope that they would be implemented, and that "code splitting" was the main feature that Webpack now provided and the cornerstone of the contemporary front end.

Most of the production of technology can not be separated from the experience of the predecessors, are the original technology, change the bar has become a new technology, so "making wheels" is an inevitable part of technological development.

Webpack and vite

The fundamental difference between webpack and vite is that it is loaded on demand.

No matter how much webpack advocates on-demand loading, it's fake on-demand loading in front of ESM. B ecause browsers didn't support modularity before ESM, most of the modularity we talked about above was a product of the community, not at the language level. The birth of ESM marks that js has its own modular system.

There's a good example of how browsers work properly by adding type-"modules" to script tags, introducing js files, and using import import directly in js files, where we don't need to rely on tools to help us implement browser support for modularity.

The implementation inside vite is to compile other resources into js files, in other words, pictures, styles, fonts, vue files and other resource modules, all converted into JS modules, let the browser load compilation. O f course you might think that webpack will, too, isn't that what technology is all about? Can't the birth of vite draw on other building tools?

Of course, many students will have a question: will vite replace webpack?

No, vite is only just getting started, and the diversity of browsers has led to ESM specifications landing less quickly. Webpack's community and ecology are already very good, it's not comparable to a new-born child, but vite's future is bound to be more powerful than webpack, and that's what technology is bound to go through, and it's going to be better for generations.

Is that the connection W3Cschool编程狮 and the browser, ESM specification, modularity, webpack, and vite? Related to the introduction, I hope to help you.