Are ES6 modules in browsers going to get loaded level-by-level?

#!/JoePea joe at
Sat Oct 17 01:57:24 UTC 2020

es-dev-server by open-wc seems to be import-aware.

On Fri, Oct 16, 2020 at 6:40 PM #!/JoePea <joe at> wrote:
> So in practice, bundling is still a thing because there isn't an
> import-aware server that has been released that proves to be better
> than bundling? Or perhaps it's too much overhead to set up a server,
> so people just bundle?
> #!/JoePea
> On Wed, Oct 14, 2020 at 2:45 PM Randy Buchholz <work at> wrote:
> >
> > I've been doing some work around module loading/importing recently, writing some "import awareness" into the server request pipeline. I'm also doing things on the client side, but I'm not set up to build a browser so I'm substituting a DI based `injection` approach for the `import` operation. It's given me a different perspective on module imports, especially when working with ES Classes. Here are my basic thoughts.
> >
> > To get to smarter imports both the client and server need  to be "import aware".  But I think just as importantly (and IMHO a prerequisite) is that the transport layer needs to directly support the concept of `import`. From the server side there is nothing in the message/request (e.g., in the header) that lets the server know the request is for an import - it just comes in as a Fetch. Knowing the type of request is an import up-front would allow early routing to "import handlers" on the server. I've suggested adding an `import` category to the headers  spec or extending `sec-fetch-dest` values to include `import` but there seems to be little interest.
> >
> > Also missing is a standard way to indicate what the client wants in the request. An `import` is basically a function call that uses "remote parameters" - the request response.
> > `{a, b, c} scoped = importFrom("/url");`
> > In worst-case form, the client is requesting a file and hoping it contains "parameters" usable by the import function. I say hoping, because the server doesn't know to return an importable file, it's up to the client to know what lies in the server url topology. Once the "importer" gets the parameter file there is another leap of faith (especially with named imports). Even if the file is importable, will it produce the correct types? We should be able to let the server know what we want. While this is too much info for a header, there should be a standard form of letting the server know what the client is looking for beyond "whatever is at this endpoint". Once a communication protocol is standardized, clients and servers can implement "import awareness".
> >
> > At least in my work, I've come to believe that the idea of "requesting a file to import" at a url address is too limiting. I really don't care where the items come from. Conceptually I'm thinking "give me these items" or "execute the import response process with these parameters", and not "give me this file". I almost see it as an HTTP verb -`IMPORT` lol. Anyway just my 2c.
> > _______________________________________________
> > es-discuss mailing list
> > es-discuss at
> >

More information about the es-discuss mailing list