“JS modules” seem to be the same as namespaces in other languages. The feature is supported by the majority of webrowsers 1 2 (obviously not MSIE). With a fairly fake objective, modules are explained in 3. This lists a number of gotchas: async loading; no global this; no bare modules; forced “use strict”. Obviously modules are only loaded once; matching every other namespace scheme in other languages.

Modules are defined on a per JS file basis. Basic loading strategies are listed 4; deployments need so manage CORS. If you have a non-minified code architecture; then modules will make your RAM usage better and your code more readable. If you did do this then your performance will be terrible, as modern browsers have a maximum download concurrency of 2. I had a test site, where I never bothered to compress and bundle the JS (page load speed 3-4s); when I bundled all the JS and CSS, the reduction in HTTP requests reduced page access time to less than a second (I improved fonts at the same time, so the change is moderated by that). Using HTTP2 would reduce the slowdown; but bundling is still a better solution, IMO. According to 5 the browser will sort out module dependencies, so the order of things in HTML (and their download speed) is less critical to manage. There is some admin work to serve modules according to 6; it claims files need a different suffix (*.mjs) and the mime format will need to be setup for that suffix.

The simplest way to do module to add the module attribute in the script tag. For code fall-backs (mostly old Opera, a few rarities that don't get updates and all of MSIE), traditional solutions are outlined 7 8. A full application using modules from the first day would probably also use the import statement 9. This is basically the same as every other language. If you are person who likes online courses; try 10. There is some technology to assist with packing, for example 11 12 (webpack, rollup, in theory even gulp).
For when I'm solving problems with Node, this article is fairly pointless. Modules are widespread and useful. I mention namespaces at the start, as in Node there is a strong focus on this.

The important decision when supporting this tech tree, is whether the 2 HTTP concurrent transactions per domain is important to you or your clients. Stable scenarios IMO:

  • OPT A [Devils advocate] write everything in HTML. C code is always faster than JS. A HTML download is likely to be much smaller, so faster than any JS framework + app combo. Technically all the clever code (i.e. the C binary) is already at the client side, and loads alot faster than JS does.
  • OPT B A daemon using libuv (most common version is NodeJS), with HTTP2, serving many singular classes, which are each compressed. If you have a stable TCP connection and consistent low latency; this should get some app features to “interaction status” in less time than any other JS approach. Asserting we have a “many small packets fast” network, GraphQL offers less benefits. I do not think NginX uses libUV 13; but has a similar approach and delivers similar performance. As far as I know; with 5G, this approach is best. Adding Common.js 14 by webreflection extends support for browsers which do not have require().
  • OPT C A HTTP 1.1+ server, emitting a few JS bundles; which cover entire features in a single download. If you are using 3g, or a poor reception 4g; this approach is soo much faster. Remember “instant wireless DSL” dongles are technically a 4G connection. Dropped TCP sessions, or SSL sequencing confusion will lead to HTTP2 benefits being absent. When a 4G connection is present a few MB of JS can be downloaded; if the connection drops 3s later, the browser can still take the app feature to “interaction state”. Operationally this architecture should be combined with graphQL 15 to further bundle network requests. Although I wrote that HTTP2 won't help in some networking situations; HTTP1.1 pipelining is a halfway step that can also be used (this saves DNS and TCP setup costs, but not the HTTP negotiation).
  • OPT D Hypothetical: Have a HTTP 1.1+ server, and a websocket server. Serve HTML and images via the webserver; stream JS classes via the websocket server. I can design this, but I have never seen an implementation; there would need to be some magic to take a streamed JS blob and execute it without using eval(). A simple but probably slow method would be to inject a script tag. A casual web search does not lead to an Object() version of Function(); I do not know how to create “in memory” objects [prefix to exclude flat strings] without using JSON or DOM injection. From parsed “in memory” tree structures, objects can be composed easily see Object.create() 16. For reference desktop gmap 17 uses websockets. The reason for mentioning this option is that websockets avoid any concurrent download limit; at the expense of writing more code.

Some similar articles in research