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 <[email protected]> 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 > [email protected] > https://mail.mozilla.org/listinfo/es-discuss _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
