What are the advantages of modular JavaScript development?

Today, the development of modular JavaScript is becoming more and more hot, whether it is a module loader or a good JavaScript module, there are endless. Since such a fire, there must be a reason for existence, it must have solved some practical problems. Many have not touched the modular JavaScript developers can not help but ask, I really need a modular, modular, compared to the traditional mode of what advantages?

JavaScript itself is not modular support, many languages, and even CSS has such a way to load.

Although CSS is not recommended for loading because of performance issues, this is a modular idea that is useful for JavaScript. Fortunately JavaScript is a flexible language that can be dynamically loaded with JavaScript files using the code below.

The traditional loading method must be loaded by placing a script tag in the page.

<script type= "Text/javascript" src= "Http://example.com/test.js" ></script>

Better separation.

If you want to load more than one script tag, if it is loaded module, take easy.js, the page is always as long as reference easy.js, so for the separation of HTML and JavaScript is very good, in some scenarios this separation is very important.

Let's take our case. The backend view layer is not developed by our front end, when the project is on-line, the front-end can only update CSS and JS files, HTML files cannot move. If the front-end to add a reference to a JavaScript file in this page is cumbersome, because the back-end program updates are strictly follow the process and have a fixed update time, if the module is loaded with the way to ignore the back-end updates. Of course, you might say, if the original page has a JavaScript file, I directly in the original file to add code, then the next thing to say directly in the original file new code will encounter what kind of problem.

Better way to organize your code

If a single file is getting bigger, the odds of maintaining a problem will be more and more large, a person development is OK, if it is a multi-person development, different code style, super Many business logic mixed together, do not say maintenance, light think of the egg pain. Modular development, a file is a module, control the granularity of the file, each module can focus on a function. Just so-called a radish a pit, when many people develop, their own in the pit of the radish on the line, this is the idea of OOP.

Load on Demand

Or around a single file, when the file is large enough, the performance problem comes along. Merging files can reduce requests, which can lead to performance gains, but when the file size is large enough, the download time may not be shorter than the download time for multiple small files. At this point the relationship between the number of requests and the volume of the file needs to be weighed.

One more problem with single files is whether the cache can be used well enough. If a large volume of files contains a lot of business logic and complex functions, and this file is also referenced by many pages. For example, in a page, the actual use of the file only a few features, then the other code for the page is redundant, wasting load traffic. You might say that this file is large, but it was cached the first time it was loaded, although only a small portion of the functionality was used on a page, but it was very fast to load as long as it was cached. Yes, it would be good if the situation were so ideal. However, often the ideal and the reality will have a gap, if the product iteration update too fast, business needs a one day, then the file will be Zooey update, the update may be a small feature, but such an update to refresh the cache cost is very large. If this is the case, it is true that the design is problematic. If you can reasonably manage the file, you can minimize unnecessary loading and minimize the loss of the cache of large files, which also needs to be weighed, such as merging rare updates into a single file, often updated independent modules.

Avoid naming conflicts

JavaScript itself does not have namespaces, and in order to avoid naming conflicts, it is often avoided by using objects and closures. The use of objects is only to reduce the probability of conflict, take the development of often use jQuery, whether it is to expand on the $.fn or expand on the scale, there will inevitably conflict. Or with a custom object, a few layers, not just write it hard to remember, such a call will also be degraded in performance. Modularity is a good solution to this problem, in the module any form of naming will no longer conflict with other modules, you remember what the name line. Of course, you have to put a bunch of things on the window inside the module, and I can't.

Since each module is closed, how do you communicate between modules? The design of the interface is necessary. Quite simply, for a CMD specification like SEAJS, you need to use a custom keyword to expose an interface externally.

Define (function(require, exports) {    var hello = ' Hello world ';          // exposing the interface to the module externally = Hello;});     

Easy.js Follow the AMD specification, exposing the interface more simply, directly with the return keyword.

function () {    var hello = ' Hello world ';     // exposing the interface    to the module externally return hello;});

Better dependency processing

Traditional development mode, if the B file to rely on a file, then must be in front of the B file in the form of script to load a file first. If one day, B files no longer need to rely on A file, or to increase the dependency file C, then back to the first question I said. If this B file is called by N pages, and the page crosses the business site, it's a nightmare to change. If you are using modularity, simply declare the dependencies within the module, and add the delete directly to modify the module. Call the time not to worry about the module depends on which other modules, rest assured that the use.

Well, speaking so much, if you still feel indifferent, either your exposure to the project is small, not complicated enough to this extent, or my ability to express is problematic. If you think there is anything else you need to add, please leave a comment below.

Originally contained in: Rainy Night with knives ' s Blog
This article link: http://stylechen.com/modular-javascript.html
Please indicate the original or original address in the form of a link if you want to reprint.

What are the advantages of modular JavaScript development?