The development history of front-end modularity

Original reference Yu Bo is a master, I sorted it out.

Our topic today is about the history of front-end modular development, mainly for the development of AMD CMD. These two things are a standard. Their actual products are AMD, RequireJS, and CMD. The product of Seajs is seajs. Their appearance is developed on the basis of COMMONjs. So we have to talk about COMMONjs first.

COMMONJS

About 2009-2010, the CommonJS community gathered many big names. CommonJS was originally called ServerJS. After the launch of the Modules/1.0 specification, it has achieved very good practices in the Node.js environment. In the second half of 2009, these hard-working masters wanted to further promote the successful experience of ServerJS to the browser, so they renamed the community CommonJS, and at the same time fiercely debated the next version of the Modules specification. Differences and conflicts were born, and three major schools were gradually formed: Modules/1.x (completely based on the functions of 1.0, just adding a conversion function), Modules/Async, Modules/2.0.

Modules/1.x school: This view believes that the 1.x specification is sufficient and only needs to be ported to the browser. What needs to be done is to add a new Modules/Transport specification, that is, use a conversion tool to convert the module into code that conforms to the Transport specification before running it on the browser. There are two implementations worth paying attention to now: component and es6 module.

Modules/Async school: This view believes that browsers have their own characteristics and should not directly use the Modules/1.x specification. Typical representatives of this perspective are the AMD specification and its implementation RequireJS. More on this later.

Modules/2.0 school: This view believes that browsers have their own characteristics and should not directly use the Modules/1.x specification, but should be as consistent as possible with the Modules/1.x specification. Typical representatives of this perspective are the authors of BravoJS and FlyScript. BravoJS authors have made significant contributions to the CommonJS community. The author of FlyScript proposed the Modules/Wrappings specification, which is the predecessor of the CMD specification. It's a pity that BravoJS is too academic, and FlyScript later self-castrated and took the entire website (flyscript.org) offline. This story is a bit tragic, so I won’t go into details.

The above are the three major schools that emerged. In other words, the products started with Modules/2.0 all ended without any problems. At that time, Modules/1.x standard ES6 was not yet mature, and later it was RequireJS, which is based on Modules/Async, is developing very rapidly.

However, there are objections to the execution timing of AMD's RequireJS, and the module writing style is controversial and has not been recognized by the CommonJS community. Let's talk about these two points in detail:

Download a in advance in AMD .js is a limitation of the browser, and there is no way to download it synchronously. This community agrees. However, in AMD, it is executed in advance, and in the basic Modules/1.0 specification, it is executed when it is required for the first time. Many people cannot accept this difference, including those who hold the Modules/2.0 view, and they cannot accept AMD's view. This difference also leads to the fact that Node modules and AMD modules cannot be shared, and there is a potential conflict;

Another one is: Module writing style is controversial

Under AMD style, passing dependent modules through parameters destroys the principle of proximity declaration. The principle of proximity means that it will be used when it is used, without the need to declare it in advance. module. Finally, AMD separated from the CommonJS community and became the AMD community alone. Later you will know that RequireJS is particularly popular!

In fact, at this time, it broke away from the AMD specification of the CommonJS community and essentially evolved into an accessory of RequireJS. Later, many people in the RequireJS community reported that they wanted to use the require method. In the end, the RequireJS author compromised, and this was the only way to have this semi-disabled support. (Note that this is pseudo-support, and behind it is still AMD's operating logic, such as early execution) The popularity of AMD depends largely on the promotion of RequireJS authors, and the evolution of AMD specifications is inseparable from RequireJS.

Modules/2.0

Wes Garland, the author of BravoJS, has profound programming skills and is also very respected in the CommonJS community. But BravoJS itself is very academic, a project written to demonstrate the Modules/2.0-draft specification. The academic school was vulnerable to the pragmatic RequireJS, and now basically only retains some good memories.

At this time, there is also a practical faction in the Modules/2.0 camp: FlyScript, which proposed a very concise Modules/Wrappings specification: This concise specification takes into account the particularity of the browser and is also as compatible with Modules/ as possible. 1.0 Specifications. Sadly, after FlyScript launched its official version and official website, RequireJS was booming at the time. During this period, there were some arguments between FlyScript author and RequireJS author James Burke. Later, the author of FlyScript performed self-castration and cleared the project and official website on GitHub. He left a sentence on the official website at that time. I vaguely remember that it was: I will come back with better things. thing.

#What exactly happened in the middle is unknown. Later, Uncle Yu sent an email to the author of FlyScript to ask, and the other party gave me two reasons that I respect, to the effect of:

1. I am not from the front-end background, and James Burke, the author of RequireJS, knows browsers better than me.

2. We should work together to promote the development of a community, even if it is not your favorite.

These two sentences had a great impact on Uncle Yu. It was also after that that I began to study RequireJS carefully and made many suggestions to RequireJS through emails and other methods. Later, in the actual use of RequireJS, I encountered many pitfalls. Although RequireJS was very popular at that time, it was really not perfect. During this period, I was also thinking about what FlyScript said when he left: "I will come back with better things."

Yu Bo said that I am not as great as the author of FlyScript, and he kept giving suggestions to RequireJS. But after it was repeatedly rejected, I began to have the idea of ​​​​writing a loader myself.

This is SeaJS. SeaJS borrows many things from RequireJS, such as renaming module.declare in FlyScript to define etc. SeaJS comes more from the Modules/2.0 point of view, but it removes academic things as much as possible and adds a lot of practical ideas. This is the indirect product of CMD, SeaJs.

Okay, I’ve finished the basic history. I don’t know if what I said can be understood by everyone. A rough summary is that COMMONJS was the first, because COMMONJS is used on the server side. , cannot be directly used in browsers. New things must have debates on how to use this specification in browsers, and different concepts and arguments have arisen. Therefore, there are AMD specifications and CMD specifications suitable for browsers. , some of AMD's problems were not recognized by the COMMONJS community, and finally operated independently. Of course, RequireJS did become popular for a while, and later CMD's product seajs was developed by Yubo.

Judging from the current situation, these two products are probably outdated. Of course, they are still in use. After all, the development of webpack es6 is unstoppable. Webpakc fully supports the three specifications and will provide more support in the future. Let’s share some knowledge about webpack. That’s it for the history of front-end modular development. It is necessary for beginners to understand the historical development of front-end. In fact, the original article was written by Uncle Yu. I just changed it and made it my own to make it easier for everyone to understand. You can also search for information about the history of front-end modularization. There is no explanation here about why modularization is needed. You can understand it first, and you will learn faster if you study with questions.

The above is the detailed content of The development history of front-end modularity. For more information, please follow other related articles on the PHP Chinese website!