It seems clear some kind of dependency graph metadata hinting is needed somewhere in the loading pipeline to optimize network delivery for unknown dynamic imports.
The question is just where and how that gets specified. Between Web Bundles, Import Maps and Compartments, I am hopeful that there will be some mechanism available here in future. On Fri, 16 Oct 2020 at 18:58, #!/JoePea <j...@trusktr.io> wrote: > es-dev-server by open-wc seems to be import-aware. > https://open-wc.org/developing/es-dev-server.html > #!/JoePea > > On Fri, Oct 16, 2020 at 6:40 PM #!/JoePea <j...@trusktr.io> 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 <w...@randybuchholz.com> > 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@mozilla.org > > > https://mail.mozilla.org/listinfo/es-discuss > _______________________________________________ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
