6 ms·

So what I still don't understand is how es6 module imports work with requests. Even reading through that blog post it's not obvious to me. Does the browser make

by mevile 10y ago

So what I still don't understand is how es6 module imports work with requests. Even reading through that blog post it's not obvious to me. Does the browser make an HTTP request for the file on the server based on the relative location on the server? So if I have type="module" and app.js is in example.com/js/app.js and then I have an import statement for ./foo/bar.js it makes that request to example.com/js/foo/bar.js? I imagine all these requests would add up and will block if so. With HTTP2 maybe it would be OK to do it this way but I see myself creating single JavaScript builds for the foreseeable future making this sort of module support unlikely to help in anything other than development (which still is nice).

MatthewPhillips 10y ago
Yes, it makes separate requests, like if you made separate script tags (just using module semantics instead). With HTTP2 it will be ok, but you will still need something that understands your dependency graph so your server knows which modules to include with the request.
- eknkc 10y ago
  I guess service workers might solve a lot of issues here. You could do weird stuff like basically serving a tar file for all assets and use a service worker to handle individual requests.
  - MatthewPhillips 10y ago
    That's a really smart idea, I hadn't considered that. Once you add in caching you might get pretty reasonable performance.
    - WorldMaker 10y ago
      Also, the not yet implemented module loader spec would include a format similar to the AMD bundle format where modules are wrapped in calls to `System.register`.
      - MatthewPhillips 10y ago
        There's no such bundling format under consideration, as far as I'm aware. System.register is a SystemJS API, not a spec one.
        WorldMaker 10y ago
        The Loader spec does include the concepts of a module registry and a low level API for them. From what I can tell skimming the specs, the high level construct of System.register has been in and out of the spec. Also from what I can tell, System.register may be possible to be implemented on top of the low level API regardless of whether it makes it into the final spec or not.
  - egeozcan 10y ago
    This is an interesting idea. On the other hand, I think if you started packing everything into a tar file, that could as well be a js file.
    - gsnedders 10y ago
      > On the other hand, I think if you started packing everything into a tar file, that could as well be a js file. Modules give you a certain degree of namespacing, which is nice. Compiling down to a tar to be served to a Service Worker is undoubtedly easier than the mangling needed to remove the modules.
calebegg 10y ago
Note that since ES6 imports are statically defined, the browser can find and begin to download dependent files before even parsing the actual JS. They could even start downloading dependent files in parallel before the first file is fully downloaded. But bundling will still probably be faster and will probably continue to be a mainstay of production web apps, just like minification already is.
- Arnavion 10y ago
  >Note that since ES6 imports are statically defined, the browser can find and begin to download dependent files before even parsing the actual JS. I think you meant executing the actual JS. Finding the imports requires parsing the file, and imports can be anywhere in the file as long as they're at the top level.
  - domenicd 10y ago
    It depends. For HTML all browsers do a form of "preparsing" where they do simplistic string searches for things that look like URLs and start speculatively fetching based on that. You could imagine a similar pass for JS modules.
    - Arnavion 10y ago
      Ah, that's cool.
    - bzbarsky 10y ago
      Firefox doesn't do simplistic string searches, for what it's worth. It actually tokenizes the HTML and kicks off loads from tokenization. If someone then misuses document.write the token stream has to be thrown out and things have to be retokenized, but that's rare in practice. The tradeoff is better accuracy of the preloader and not having to go through the text twice unless someone is misusing document.write.
- MatthewPhillips 10y ago
  You still have to fetch a module before you know it's dependencies. So if A depends on B which depends on C, you must fetch those sequentially. With a deep dependency graph this will be a problem.
GundersenM 10y ago
I recently wrote about this, and how it can be solved using HTTP/2 and Service Workers: https://mariusgundersen.net/module-pusher/ https://mariusgundersen.net/module-pusher/

by mevile 10y ago

MatthewPhillips 10y ago

Yes, it makes separate requests, like if you made separate script tags (just using module semantics instead). With HTTP2 it will be ok, but you will still need something that understands your dependency graph so your server knows which modules to include with the request.

eknkc 10y ago
I guess service workers might solve a lot of issues here. You could do weird stuff like basically serving a tar file for all assets and use a service worker to handle individual requests.
- MatthewPhillips 10y ago
  That's a really smart idea, I hadn't considered that. Once you add in caching you might get pretty reasonable performance.
  - WorldMaker 10y ago
    Also, the not yet implemented module loader spec would include a format similar to the AMD bundle format where modules are wrapped in calls to `System.register`.
    - MatthewPhillips 10y ago
      There's no such bundling format under consideration, as far as I'm aware. System.register is a SystemJS API, not a spec one.
      - WorldMaker 10y ago
        The Loader spec does include the concepts of a module registry and a low level API for them. From what I can tell skimming the specs, the high level construct of System.register has been in and out of the spec. Also from what I can tell, System.register may be possible to be implemented on top of the low level API regardless of whether it makes it into the final spec or not.
- egeozcan 10y ago
  This is an interesting idea. On the other hand, I think if you started packing everything into a tar file, that could as well be a js file.
  - gsnedders 10y ago
    > On the other hand, I think if you started packing everything into a tar file, that could as well be a js file. Modules give you a certain degree of namespacing, which is nice. Compiling down to a tar to be served to a Service Worker is undoubtedly easier than the mangling needed to remove the modules.

calebegg 10y ago

Note that since ES6 imports are statically defined, the browser can find and begin to download dependent files before even parsing the actual JS. They could even start downloading dependent files in parallel before the first file is fully downloaded. But bundling will still probably be faster and will probably continue to be a mainstay of production web apps, just like minification already is.

Arnavion 10y ago
>Note that since ES6 imports are statically defined, the browser can find and begin to download dependent files before even parsing the actual JS. I think you meant executing the actual JS. Finding the imports requires parsing the file, and imports can be anywhere in the file as long as they're at the top level.
- domenicd 10y ago
  It depends. For HTML all browsers do a form of "preparsing" where they do simplistic string searches for things that look like URLs and start speculatively fetching based on that. You could imagine a similar pass for JS modules.
  - Arnavion 10y ago
    Ah, that's cool.
  - bzbarsky 10y ago
    Firefox doesn't do simplistic string searches, for what it's worth. It actually tokenizes the HTML and kicks off loads from tokenization. If someone then misuses document.write the token stream has to be thrown out and things have to be retokenized, but that's rare in practice. The tradeoff is better accuracy of the preloader and not having to go through the text twice unless someone is misusing document.write.
MatthewPhillips 10y ago
You still have to fetch a module before you know it's dependencies. So if A depends on B which depends on C, you must fetch those sequentially. With a deep dependency graph this will be a problem.

GundersenM 10y ago

I recently wrote about this, and how it can be solved using HTTP/2 and Service Workers: https://mariusgundersen.net/module-pusher/ https://mariusgundersen.net/module-pusher/