JavaScript refactoring: module partitioning and namespaces

Usually in our team, developers have considerable technical literacy and rich experience in the Java language, and have many mature and reasonable protocols, various types of code hazard inspection tools, and even planned reviews between teams and unannounced inspections. However, the front-end code is not like the back-end. It is like a child that no one cares about. Not only is it easy to be underestimated and despised, it leads to poor quality and poor maintainability, there is also a lack of excellent front-end developers in terms of skills.
JavaScript is an important part of the front-end code. As the version continues and the product becomes bigger and bigger, JavaScript-level reconstruction needs to be gradually strengthened throughout the process.

When the amount of code reaches a certain level, JavaScript is best modularized together with page module components (such as custom FreeMarker tags).
The biggest benefit brought by modularization is independence and maintainability. There is no need to locate problem locations in massive js. It is simpler, easier to be understood and accepted, and easier to customize.
It is best to keep the dependencies between modules simple. For example, if there is a common.js, it becomes the most common functional code. It does not contain or contains uniformly managed global variables. It is required that it can be published independently, and other component js can be easily Depend on it. For example, we often need to implement a trim method on strings, but js itself does not have it. Then we can extend the string prototype in common.js to implement it, which is transparent to external users.

Using namespaces is a good way to keep js from interfering with each other. Since js is object-oriented, it must follow the principles of encapsulation, inheritance and polymorphism.
Referring to the usage of Java import, I hope that namespace can bring such an effect. Let’s look at the simplest example:
I have a module play, which contains a method webOnlinePlay. Then when this module is not imported, I I hope the execution of js is wrong:
Java code
webOnlinePlay(); //Error! Unable to find method

But if I introduce this module:
Java code
import("play");

webOnlinePlay() ; //Correct, you can find a method

In fact, it is very simple to achieve such an effect, because the essence of calling a method webOnlinePlay() by default is: window.webOnlinePlay(), right?
So when import("play"), the internal implementation mechanism is as follows:
Java code
var module = new playModule();

Every method in this module is imported into the window object for direct use. ：
Java code
window[methodName] = module[methodName];

In fact, there is no mystery here, but this idea of ​​​​getting what you need brings an idea to the front-end reconstruction, and the possibility brought by encapsulation Maintenance enhancement idea, isn't it?

If you are smart, you may also ask a question:
If I don’t import the play module and this page doesn’t need it, can I not even load the play.js?
Of course, please pay attention to the following decomposition - the part about dynamic loading of js.