I saw this question while wandering around Zhihu, and there are only 2 answers below. He Shijun also paid attention to this problem, so……

I’m not invited to answer this question.

Let’s start with what the proposal actually is.

JavaScript module fragments are a syntax for named, inline JS modules, which can be used for bundling multiple modules into a single JavaScript file.

JS Module fragments are a proposal for JavaScript module syntax, or “module fragments”, that can be used to write multiple module code in a single JavaScript file.

To put it simply, ES Modules are currently divided by file, while TC39 proposal means that you can go one step further and split the code into Modules within the same JS file, which is somewhat similar to the ‘region’ comment fragment in many other programming languages.

For example, the following code:

// define a module #count module "#count" {let I = 0; Export function count() {i++; return i; # upperCase module "#uppercase" {export function uppercase(string) {return string.toUpperCase(); Import {count} from "#count"; import {count} from "#count"; import { uppercase } from "#uppercase"; console.log(count()); // 1 console.log(uppercase("daniel")); // "DANIEL"Copy the code

Yes, this is the sample code in the proposal, which I annotated.

The motivation behind this proposal can be found in the proposal, which can be summarized as the high cost of loading small files in various environments and the need for other packaging tools.

Take a clip and show it with my second-grade translation skills:

This proposal adds a syntax to JavaScript to allow for several JavaScript modules in one file. This format can be used as output by bundlers, with low overhead on execution, so that bundlers don’t have to emulate as much, and JS engines can see what’s going on. It’s also convenient to be typed directly by JavaScript developers, and it should be low overhead to fit into existing workflows.

This proposal adds a syntax to JavaScript that allows multiple JavaScript modules to be included in a single file. Modules can be packaged this format output, reducing transaction cost, therefore, in the traditional sense of the packaging tool is no longer so important, JS engine itself could finish this a series of work, can facilitate the developers can use the original JavaScript directly, and it is also easy to let it into the existing development process.

I personally support this proposal.

Basically, JavaScript was born too quickly (” sloppy “) and was never intended to be used on the scale it is today, so many advanced features are incomplete.

Historically, JavaScript has not had a module system, where you can break up a large program into interdependent modules with their respective responsibilities and put them together in a simple way. This creates a huge barrier to building complex, large-scale applications.

Webpack, now familiar to everyone, was born to better solve this problem, but this time, it is no longer a community solution or tool, finally someone started to language standards, trying to stand up from the language level to completely solve this problem.

The core capability of this syntax is “module packaging correlation”. One of the most important motivations for this proposal is “browser anticipation”, where the browser anticipates whether modules need to be pre-loaded in advance, so that it can tell whether modules need to be loaded or not, thereby improving loading performance.

Of course, if this proposal can be finally passed, it must be gradual, as to how much energy can be released, it depends on the wisdom of the leaders.

XDM, give me a thumbs up for this…