>We could wirte a simpler parser just for the imports subset
IMHO code on client and server isn't the root problem. I've written a few
versions and the biggest issue I had was how to distinguish an `import`
request/fetch from any other. There is nothing in the request metadata to let
you know
a way to inspect modules
>> to see what they have in them. They're a strange beast. You can see their
>> scope in the debugger and they look like an ES Object or IDL interface, but
>> I don't know how to get a reference to them in code. But, they're new, so
>> we'll see where they
now how to get a reference to them in code. But, they're new, so
> we'll see where they go. Maybe someday we'll have a `modules` collection we
> can interrogate.
> >
> > -Original Message-
> > From: #!/JoePea
> > Sent: Saturday, October 17, 2020 10:35 PM
&g
gt;
> -Original Message-
> From: #!/JoePea
> Sent: Saturday, October 17, 2020 10:35 PM
> To: Randy Buchholz
> Cc: es-discuss@mozilla.org
> Subject: Re: Are ES6 modules in browsers going to get loaded level-by-level?
>
> That's neat, but it seems like the same
ay, October 17, 2020 10:35 PM
To: Randy Buchholz
Cc: es-discuss@mozilla.org
Subject: Re: Are ES6 modules in browsers going to get loaded level-by-level?
That's neat, but it seems like the same work that a server would have to do
with actual ES Module imports, right? And the "type tree&q
That's neat, but it seems like the same work that a server would have
to do with actual ES Module imports, right? And the "type tree"
equivalent is the modules that the JS engine stores as a map from
import identifier to module scope instance. It seems that in the end,
the `PUSH` approach should
I think some form of bundling will always be necessary. I use classes and took
a name-spaced and typed approach to modules and classes, putting each class in
its own module in a file hierarchy (namespace). This is an enterprise level LOB
application with dozens of classes. Many classes are used
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 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
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 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.
Right, exactly. So naively sending all dependencies wastefully is just
the first step.
> Afaik the more promising path are prefetch hints on the client. E.g. the
client (or initial HTML payload) knows the dependency tree, adds tags
for preloading the required modules, and then the browser can
> If I understand HTTP/2 correctly, this requires more than a server
> that simply has HTTP push, it requires a server that understands how
> to read ES modules and enumerate their dependencies.
Not only that: The server also has to "know" which modules are already
cached by the client (including
I'm asking about a server that, upon request of a `.js` file, knows
how to enumerate the dependency tree based on that file, _then_ HTTP
pushes all the modules at once.
So basically, from the code
```html
On Sat, Oct 10, 2020 at 5:19 PM #!/JoePea wrote:
> It's 5 years later, but still no (obvious) sign of HTTP/2 servers
> specialized in ES Module push.
>
What does it mean to specialize in module push? How can modules be pushed
without the browser requesting them? Is it a server that reads the
It's 5 years later, but still no (obvious) sign of HTTP/2 servers
specialized in ES Module push.
Do any exist? Anyone have a list? I'm especially interested in the
self-hostable servers, but also curious about solutions where we may
publish modules to.
The non-self-hosted solutions may be
Replies interspersed below
On Thu, Apr 23, 2015 at 9:48 AM, James Burke jrbu...@gmail.com wrote:
On Thu, Apr 23, 2015 at 7:47 AM, Domenic Denicola d...@domenic.me wrote:
Indeed, there is no built-in facility for bundling since as explained
in this thread that will actually slow down your
*To:* Frankie Bagnardi; Matthew Phillips
*Cc:* es-discuss
*Subject:* Re: Re: Are ES6 modules in browsers going to get loaded
level-by-level?
So just to clarify, when browsers support es6 modules we will still need
some extra library to bundle the modules? This would mean es6 modules are
only
James Burke wrote:
So let's stay on this specific point: bundling will still be done even
with ES modules and a loader that would natively understand ES modules
in unbundled form. Hopefully the rest of my previous message gave
enough data as to why.
Not bundling in full; your previous post
On Apr 23, 2015, at 10:35 PM, James Burke wrote:
On Thu, Apr 23, 2015 at 4:48 PM, Brendan Eich bren...@mozilla.org wrote:
Your lament poses a question that answers itself: in time, ES6 will be
the base level, not ES3 or ES5. Then, the loader can be nativized.
Complaining about this now seems
On Fri, Apr 24, 2015 at 8:42 AM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
I think you're barking up the wrong tree. ECMAScript has never said
anything about the external representation of scripts (called Programs
prior to ES 2015) and the ES 2015 spec. doesn't impose any requirements
On Fri Apr 24 01:35 AM, James Burke wrote:
If not natively supported in ES, it would be great to get a pointer to
the officially blessed transform of an ES module body to something
that can be bundled. Something that preserves the behaviors of the
mutable slots, and allows using the
On Fri, Apr 24, 2015 at 11:39 AM, Brendan Eich bren...@mozilla.org wrote:
Not bundling in full; your previous post talked about HTTP2 but mixed
dependency handling and bundling. You seemed not to advert to the problem
of one big bundle being updated just to update one small member-of-bundle.
23, 2015 10:25
To: Frankie Bagnardi; Matthew Phillips
Cc: es-discuss
Subject: Re: Re: Are ES6 modules in browsers going to get loaded level-by-level?
So just to clarify, when browsers support es6 modules we will still need some
extra library to bundle the modules? This would mean es6 modules
In 10 years, we probably won't be using tools for the modules added in
ES2015, but we might be using them for the changes made in ES2020.
On Thu, Apr 23, 2015 at 7:24 AM, Eric B neuros...@gmail.com wrote:
So just to clarify, when browsers support es6 modules we will still need
some extra
So just to clarify, when browsers support es6 modules we will still need
some extra library to bundle the modules? This would mean es6 modules are
only a syntactical addition and not something functional?
On Thu, Apr 23, 2015 at 10:18 AM Frankie Bagnardi f.bagna...@gmail.com
wrote:
Matthew,
*Subject:* Re: Re: Are ES6 modules in browsers going to get loaded
level-by-level?
So just to clarify, when browsers support es6 modules we will still need
some extra library to bundle the modules? This would mean es6 modules are
only a syntactical addition and not something functional
Matthew, there are already tools for es6 modules + bundling (e.g. babel +
webpack), or converting es6 modules to AMD (e.g. babel
https://babeljs.io/docs/usage/modules/).
On Wed, Apr 22, 2015 at 7:10 PM, Matthew Phillips matt...@bitovi.com
wrote:
Can you clarify what you mean about bundling?
Correct, ES6 has no plans for a bundling solution and the whatwg group
working on the loader has not proposed one.
Nevertheless bundling solution is easier to build and specify. In ES6,
given a root module you can compute the (static) dependency graph as the
basis for creating a bundle. The
On Thu, Apr 23, 2015 at 7:47 AM, Domenic Denicola d...@domenic.me wrote:
Indeed, there is no built-in facility for bundling since as explained in
this thread that will actually slow down your performance, and there’s no
desire to include an antipattern in the language.
Some counterpoint:
James Burke wrote:
It is kind of sad that to use ES modules means to actually not really
use them at runtime, to transpile back to ES5-level of code, and
needing to ship a bootstrap loader script that allows slotting that
the ES5-level code into the ES loader. For the extra script and
Bagnardi; Matthew Phillips
*Cc:* es-discuss
*Subject:* Re: Re: Are ES6 modules in browsers going to get loaded
level-by-level?
So just to clarify, when browsers support es6 modules we will still need
some extra library to bundle the modules? This would mean es6 modules are
only a syntactical
*Subject:* Re: Re: Are ES6 modules in browsers going to get loaded
level-by-level?
So just to clarify, when browsers support es6 modules we will still need
some extra library to bundle the modules? This would mean es6 modules are
only a syntactical addition and not something functional?
On Thu
:* Thursday, April 23, 2015 10:25
*To:* Frankie Bagnardi; Matthew Phillips
*Cc:* es-discuss
*Subject:* Re: Re: Are ES6 modules in browsers going to get loaded
level-by-level?
So just to clarify, when browsers support es6 modules we will still need
some extra library to bundle the modules
On Thu, Apr 23, 2015 at 4:48 PM, Brendan Eich bren...@mozilla.org wrote:
Your lament poses a question that answers itself: in time, ES6 will be
the base level, not ES3 or ES5. Then, the loader can be nativized.
Complaining about this now seems churlish. :-|
So let's stay on this specific
Can you clarify what you mean about bundling? Unless I've missed something,
the ES6 module system does not have a story for bundling at all. Of course
formats can be invented in userland but I'm not sure that they are any
easier to implement than say AMD's. I might have missed something though,
Neither node.js/iojs nor nginx. Though nginx supports spdy and there is a
http2 module for node but it isn't compatible with express.
On Fri, Apr 17, 2015, 2:31 AM medikoo medikoo+mozilla@medikoo.com
wrote:
Thanks for clarifications,
Still after reading your comments I have a feeling that
On Thu, Apr 16, 2015 at 11:16 PM, medikoo medikoo+mozilla@medikoo.com
wrote:
Thanks for clarifications,
Still after reading your comments I have a feeling that providing ES6
modules to browsers (efficient way) will be much more cumbersome and tricky
than it is to provide CJS ones now.
From: John Barton [mailto:johnjbar...@google.com]
But the push scenario in your first paragraph would not use the cache either.
Yeah, that's what I was alluding to with the most naïve comment.
one or the other has to send its information at the outset of a import
request, or
One way of
It'll be great to have some more insight on this.
To my knowledge when using ES6 modules as currently specified there's no way
to introduce more than one module with one file.
So technically, the only way to use them natively in browsers, would be to
serve them separately.
This raises the
On Thu, Apr 16, 2015 at 1:22 PM, Domenic Denicola d...@domenic.me wrote:
From: John Barton [mailto:johnjbar...@google.com]
But the push scenario in your first paragraph would not use the cache
either.
Yeah, that's what I was alluding to with the most naïve comment.
one or the other has
On Thu, Apr 16, 2015 at 12:18 PM, Domenic Denicola d...@domenic.me wrote:
Is there any mean in sight, that will allow us to serve
them as fast as we can serve hundreds of bundled and minimized CJS
modules now?
Yes. Any browser which implements the ES6 module loader (none of them
right
Is there any mean in sight, that will allow us to serve
them as fast as we can serve hundreds of bundled and minimized CJS
modules now?
Yes. Any browser which implements the ES6 module loader (none of them right
now) will also be a browser that implements HTTP/2 (all of them right now).
You might find this interesting:
https://ma.ttias.be/architecting-websites-http2-era/#comment-10935
(PUSH_PROMISE frame)
Glen.
On 2015/04/16 22:43, John Barton wrote:
On Thu, Apr 16, 2015 at 1:22 PM, Domenic Denicola d...@domenic.me
mailto:d...@domenic.me wrote:
From: John Barton
The issue you're describing exists today, and it is the main reason why we do
bundling (a la webpack, browserify, etc.).
ES6 modules are not introducing any new restriction here, it is just the way
things work. HTTP2 is suppose to help in this regards, but only a little bit.
In my experience,
44 matches
Mail list logo
