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
