Some thoughts on javascript module loading technology_javascript skills

Not long ago, a netizen asked me about using requireJs and seajs on the front end. I asked him if your company had any self-written javascript libraries or javascript frameworks before. His answer was nothing, he just heard about it. Things like requirejs and seajs are new things and new technologies, and they are very valuable, so I want to use them.

This netizen’s question caused me to think about JavaScript module loading technology. In the last article, I gave the basic structure of a JavaScript library I wrote. In fact, one of the reasons for writing this article was because I wanted to use requirejs. Or use technology like seajs to redesign the basic model for writing my JavaScript library. When I learned more about this technology, I found that it was incorrect to use the module loading system to solve the problem of decoupling the general code and business code in the JavaScript library. , the scope of the module loading system is to solve the dependency problem between different JavaScript libraries, rather than to help you how to develop a JavaScript library.

So what is the javascript module loading system?

The module system is mainly designed to solve the problem of naming conflicts of operation objects in different JavaScript libraries and the problem of dependencies between different JavaScript libraries. The module loading system is aimed at large-scale web front-end applications or giant web front-end applications.

Generally, in a giant web front-end application page, the functions of the page are very rich and the business is very complex. Moreover, as time goes by, the functions of the page often change, so front-end developers often have to develop new functions for new functions. Function modules, but in actual business, the functions of various functional modules may penetrate each other, depend on each other, and have intricate relationships. When the page becomes complex, the relationship between the various front-end libraries will become difficult to manage and control. This That’s when the module loading system comes in handy.

For most programmers, there are not many opportunities to independently undertake such a large web front-end application. However, there are many more opportunities to develop small and medium-sized web front-end applications, such as enterprise-level web projects. There are very few types of JavaScript libraries used, and the dependencies of each library are easy to control. There is no need to introduce any module management system. Even the web pages of many small and medium-sized Internet companies are probably not as good as the front-end of enterprise-level web applications. It is complex, so the relationship between its modules or JavaScript libraries is easy to manage. In fact, these small and medium-sized applications like the above are all targeted at certain or specific scenarios. Therefore, I personally feel that in the face of such web front-end projects, we can finally form an independent JavaScript library ourselves. The characteristics of this library should be similar to those of jQuery. The types of libraries are similar: a main library plus several plug-in libraries. The purpose of the main library is to solve the problem of versatility. It should be reusable and migrated, while the purpose of the plug-in library is often related to business code. , but in order to distinguish the scope issues of the main library and the plug-in library, I added the namespace function to the library.

Javascript module loading technology and Hadoop technology have some similarities, that is, they are both technologies for very large systems. They can only play their role under certain conditions, so these technologies are launched from large Internet companies. , because large Internet companies must solve problems as their applications become larger and more complex. When your system is still in its infancy, you often need to be cautious when using these technologies. We should find the simplest and most effective way to solve our actual problems. , if you think this system will become larger and larger in the future, then you should retain the interfaces for using these technologies in the future. If you use them too early, it is very likely that when the system scale expands, the cost of refactoring the code will be higher.

For the module loading system, its most suitable scenario is to solve the decoupling problem between large-scale web front-end application modules. If we just write a new javascript file and immediately use the module loading technology, this is not a bit of a misuse of technology. Well, before we use a certain technology, we should not only consider how it is used, but also whether it is valuable to use it.

The last thing I want to say is that I think small and medium-sized web front-end applications should be deployed in production. Because JavaScript is not the most complex, it is best to package all external JavaScript files into a JavaScript external file. The advantage of this is that it reduces http requests. Number, using module loading technology will make it troublesome or even impossible for you to package files (modules like requirejs and seajs are based on files, and each module is an independent file). This is the same as solving the purpose of reducing http. is contradictory.