>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
()` is at stage 3 already IIRC.
(FWIW ES6 modules are sufficiently different enough that I feel it'd
be okay to keep a different syntax for it, and to make it a syntactic
form, to fit with the syntactic nature of ES modules.)
-
Isiah Meadows
m...@isiahmeadows.com
On Sat, Jan 21, 2017 at 1:22 PM, Andrea
hat import() needs to be "in the scope" of the current module, as
>> it needs to resolve the module path it is given relative to the current
>> module's.
>> Thinking about it some more, I thought it would be a pity for import to
>> be so "special", and asked
e will be more features that
> will need to be "module-aware" like import().
>
> And there are! (I think...) - __filename and __dirname in NodeJS are
> exactly such features. Actually, anything passed to the function wrapping
> each NodeJS module is such a feature, but
t it would be a pity for import to be
> so "special", and asked myself whether there will be more features that
> will need to be "module-aware" like import().
>
> And there are! (I think...) - __filename and __dirname in NodeJS are
> exactly such features. Actua
would be a pity for import to
>>> be so "special", and asked myself whether there will be more features that
>>> will need to be "module-aware" like import().
>>>
>>> And there are! (I think...) - __filename and __dirname in NodeJS are
&g
like import().
>>
>> And there are! (I think...) - __filename and __dirname in NodeJS are
>> exactly such features. Actually, anything passed to the function wrapping
>> each NodeJS module is such a feature, but going over them, only __filename
>> and __dirna
> exactly such features. Actually, anything passed to the function wrapping
> each NodeJS module is such a feature, but going over them, only __filename
> and __dirname are not immediately related to the module mechanism.
>
> So my question is this (and it is specifically addressed to
this (and it is specifically addressed to the NodeJS
> implementors in the group): in NodeJS's implementation of ES6 modules, how
> will __dirname and __filename be implemented? Will there still be a
> function wrapper like in the current module implementation? Or will
>
question is this (and it is specifically addressed to the NodeJS
implementors in the group): in NodeJS's implementation of ES6 modules, how
will __dirname and __filename be implemented? Will there still be a
function wrapper like in the current module implementation? Or will
__dirname and __fi
it, but after using es6 modules for a while I now think
they're (far) superior to even python's approach, at least in terms of
usability.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
*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,
that providing ES6
modules to browsers (efficient way) will be much more cumbersome and tricky
than it is to provide CJS ones now.
This may lead to scenario when most of us (for easy serve of bundle), will
prefer to transpile them into something else, but I hope that won't be the
case.
Another
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
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
*I've been redirected from here:
https://github.com/tc39/ecma262/issues/27#issuecomment-84474257 . Not sure
if this is a good place to ask this question. If not, I'm sorry for the
noise. Could you then point me elsewhere perhaps?*
I've just read this post here:
http://www.2ality.com/2014/09/es6
There are two options for prefetching dependencies without having to wait for
load and parse:
1) Assume none of your modules use the loader object for loading other modules,
parse them during deployment and get the dependency graph.
2) Use what Guy calls a tracer that executes your app during
, I just don't see how the browser can know
which 300 entries to request until it parses the first entry. If on the
other hand you mean the server parses the modules, then it sounds
equivalent to bundling.
(Do we want to wait for SPDY in every browser before we use ES6
modules?)
All major
Mutable bindings have valid use cases for object properties as well. My - very
late - vote is for modules to use the same destructuring syntax as objects.
Just leave out mutable bindings in modules for now. That way both modules and
objects use the same syntax and that syntax means the same
They curly braces only look like destructuring if you keep the name the
same, when imported with a different name it's a slightly different syntax,
{oldname as newname} not {oldname: newname}, also as it currently stands
// BAD
import lib from 'library';
lib.foo();
lib.bar();
is
confused by CommonJS. ES6 modules don't have single-export
modules. All modules can have multiple exports. And all modules can have a
specially named export called default which allows you to skip the curly
brackets.
Example:
// foo.js
export default function () { // anonymous function
On Sun, Jun 15, 2014 at 8:32 PM, Axel Rauschmayer a...@rauschma.de wrote:
I apologize for this email, but I still don’t understand the current
module design.
...
**Single-export modules.** Still missing is support for single-export
modules, which could be added as follows (the keyword
On Mon, Jun 16, 2014 at 8:53 AM, Calvin Metcalf
calvin.metc...@gmail.com wrote:
They curly braces only look like destructuring if you keep the name the
same, when imported with a different name it's a slightly different syntax,
{oldname as newname} not {oldname: newname}, also as it currently
e.g. something like
https://gist.github.com/calvinmetcalf/9252f41bf6e3c8b4add7
On Mon, Jun 16, 2014 at 1:01 PM, C. Scott Ananian ecmascr...@cscott.net
wrote:
On Mon, Jun 16, 2014 at 8:53 AM, Calvin Metcalf
calvin.metc...@gmail.com wrote:
They curly braces only look like destructuring if you
From: es-discuss es-discuss-boun...@mozilla.org on behalf of C. Scott Ananian
ecmascr...@cscott.net
Using destructuring syntax for imports would be a *good thing*. It builds on
our existing understanding of JS constructs, instead of adding more
gratuitously different things to learn.
This
On Jun 16, 2014 1:06 PM, Domenic Denicola dome...@domenicdenicola.com
wrote:
From: es-discuss es-discuss-boun...@mozilla.org on behalf of C. Scott
Ananian ecmascr...@cscott.net
Using destructuring syntax for imports would be a *good thing*. It
builds on our existing understanding of JS
On Mon, Jun 16, 2014 at 1:05 PM, Calvin Metcalf calvin.metc...@gmail.com
wrote:
e.g. something like
https://gist.github.com/calvinmetcalf/9252f41bf6e3c8b4add7
re:
let { foo, bar } = import library;
Ignoring the UnaryExpression ambiguity, what happens here:
// library.js
export const
Metcalfmailto:calvin.metc...@gmail.com; es-discuss
Steenmailto:es-discuss@mozilla.org; C. Scott
Ananianmailto:ecmascr...@cscott.net
Subject: RE: ES6 modules (sorry...)
On Jun 16, 2014 1:06 PM, Domenic Denicola
dome...@domenicdenicola.commailto:dome...@domenicdenicola.com wrote:
From: es-discuss
es-discuss
Steen
es-discuss@mozilla.org; C. Scott Ananian ecmascr...@cscott.net
Subject: RE: ES6 modules (sorry...)
On Jun 16, 2014 1:06 PM, Domenic Denicola dome...@domenicdenicola.com
wrote:
From: es-discuss es-discuss-boun...@mozilla.org on behalf of C. Scott
Ananian ecmascr...@cscott.net
Using
A good question Rick, I sketched that out pretty quickly earlier today. It
did take me a while to remember that modules are the ONE place where
strings are by reference an not by value...
On Mon, Jun 16, 2014 at 1:22 PM, Rick Waldron waldron.r...@gmail.com
wrote:
On Mon, Jun 16, 2014 at
On Mon, Jun 16, 2014 at 1:06 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
From: es-discuss es-discuss-boun...@mozilla.org on behalf of C. Scott
Ananian ecmascr...@cscott.net
Using destructuring syntax for imports would be a *good thing*. It builds
on our existing understanding of
On Mon, Jun 16, 2014 at 1:22 PM, Rick Waldron waldron.r...@gmail.com
wrote:
On Mon, Jun 16, 2014 at 1:05 PM, Calvin Metcalf calvin.metc...@gmail.com
wrote:
e.g. something like
https://gist.github.com/calvinmetcalf/9252f41bf6e3c8b4add7
re:
let { foo, bar } = import library;
Ignoring
Jasper: none of those things are legal in the current spec
On Mon, Jun 16, 2014 at 1:41 PM, Jasper St. Pierre jstpie...@mecheye.net
wrote:
On Mon, Jun 16, 2014 at 1:22 PM, Rick Waldron waldron.r...@gmail.com
wrote:
On Mon, Jun 16, 2014 at 1:05 PM, Calvin Metcalf calvin.metc...@gmail.com
On Mon, Jun 16, 2014 at 1:41 PM, C. Scott Ananian ecmascr...@cscott.net wrote:
That is, IMHO mutable bindings and modules with cyclic dependencies
are members of the bad parts of JavaScript. Sure, sometimes there's
a valid reason to use them. But for most developers they will be
happier
On Mon, Jun 16, 2014 at 1:40 PM, Calvin Metcalf calvin.metc...@gmail.com
wrote:
A good question Rick, I sketched that out pretty quickly earlier today.
It did take me a while to remember that modules are the ONE place where
strings are by reference an not by value...
It's more than
On Mon, Jun 16, 2014 at 1:41 PM, Jasper St. Pierre jstpie...@mecheye.net
wrote:
On Mon, Jun 16, 2014 at 1:22 PM, Rick Waldron waldron.r...@gmail.com
wrote:
On Mon, Jun 16, 2014 at 1:05 PM, Calvin Metcalf calvin.metc...@gmail.com
wrote:
e.g. something like
A few more thoughts...
On Mon, Jun 16, 2014 at 1:41 PM, Jasper St. Pierre jstpie...@mecheye.net
wrote:
On Mon, Jun 16, 2014 at 1:22 PM, Rick Waldron waldron.r...@gmail.com
wrote:
On Mon, Jun 16, 2014 at 1:05 PM, Calvin Metcalf calvin.metc...@gmail.com
wrote:
e.g. something like
.
--
From: Sam Tobin-Hochstadt sa...@cs.indiana.edu
Sent: 2014-06-16 13:21
To: Domenic Denicola dome...@domenicdenicola.com
Cc: Calvin Metcalf calvin.metc...@gmail.com; es-discuss Steen
es-discuss@mozilla.org; C. Scott Ananian ecmascr...@cscott.net
Subject: RE: ES6
@mozilla.org; C. Scott Ananian ecmascr...@cscott.net
Subject: RE: ES6 modules (sorry...)
On Jun 16, 2014 1:06 PM, Domenic Denicola dome...@domenicdenicola.com
wrote:
From: es-discuss es-discuss-boun...@mozilla.org on behalf of C.
Scott Ananian ecmascr...@cscott.net
Using destructuring
On Mon, Jun 16, 2014 at 2:27 PM, Matthew Robb matthewwr...@gmail.com wrote:
My argument is that you can keep everything the same as it is now but change
the syntax to not use curlies and avoid the confusing similarity to
destructuring. You could use `(a,b,c)` or `a,b,c` and it would all
- Matthew Robb
On Mon, Jun 16, 2014 at 11:42 AM, C. Scott Ananian ecmascr...@cscott.net
wrote:
On Mon, Jun 16, 2014 at 2:27 PM, Matthew Robb matthewwr...@gmail.com
wrote:
My argument is that you can keep everything the same as it is now but
change
the syntax to not use curlies and avoid
Another alternative is to introduce this funny binding not
destructing behavior as a first-class language construct, so that one
could do:
```
let o = { f: 1 };
let f = o; // using your angle-bracket syntax for the sake of discussion
o.f = 2;
console.log(f); // prints '2'
let foo = import
) and does
destructuring. You then use browserify or similar tools to get your
bundles. Perhaps a whole tool for ES6 modules will rise, but we have to
make sure that the magic doesn't mean only implementable natively. It
needs to be something people can use today in ES5 browsers... or else we'll
have
The other big concern here is that in production, very few people are
going to be loading every JavaScript file asynchronously. If there's
magic, there needs to be a reasonable way to handle bundling multiple ES6
files together.
OK, so there are two issues here:
1. How do you bundle
On Jun 16, 2014, at 5:41 PM, Frankie Bagnardi f.bagna...@gmail.com wrote:
The other big concern here is that in production, very few people are going
to be loading every JavaScript file asynchronously. If there's magic, there
needs to be a reasonable way to handle bundling multiple ES6
we want to wait for SPDY in every browser before we use ES6 modules?)
/caridy
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
is essentially
a runtime bundling process at the browser level without the hazards of doing it
manually, and getting the benefit of the granular caching at the browser level.
(Do we want to wait for SPDY in every browser before we use ES6 modules?)
All major browsers (including safari) support SPDY
All major browsers (including safari) support SPDY today. But the point
is, we should not consider bundling as a prime use-case for modules,
because it is not going to be important at all.
I agree, in principle, but I'm not quite as confident that bundling will
have *no* place on the web.
and say 300
modules how many round trips from client to server will you need using
SPDY? The competition (ES5 prebuilt) uses one.
(Do we want to wait for SPDY in every browser before we use ES6 modules?)
All major browsers (including safari) support SPDY today. But the point
is, we should
we want to wait for SPDY in every browser before we use ES6 modules?)
All major browsers (including safari) support SPDY today. But the point is,
we should not consider bundling as a prime use-case for modules, because it
is not going to be important at all.
If people want to do
, next time the
user visits the app/page, only that piece will have to be loaded over the
wire, the rest is just going to rely on the browser's cache. This is a
killer feature, specially if you're doing continues deployment.
(Do we want to wait for SPDY in every browser before we use ES6
modules
Guy Bedford and I have been discussing a compromise with bundling of
“internal” dependencies but leaving “external” dependencies out of the
bundle. There are legitimate concerns around exposing a library’s internal
module structure to the outside world. For example, Ember is written using
ES6
want to wait for SPDY in every browser before we use ES6
modules?)
All major browsers (including safari) support SPDY today. But the point
is, we should not consider bundling as a prime use-case for modules,
because it is not going to be important at all.
If people want to do bundling
parses the modules, then it sounds
equivalent to bundling.
(Do we want to wait for SPDY in every browser before we use ES6
modules?)
All major browsers (including safari) support SPDY today. But the point
is, we should not consider bundling as a prime use-case for modules,
because
equivalent to
bundling.
(Do we want to wait for SPDY in every browser before we use ES6 modules?)
All major browsers (including safari) support SPDY today. But the point is,
we should not consider bundling as a prime use-case for modules, because
it is not going to be important
I apologize for this email, but I still don’t understand the current module
design.
**Multi-export modules.** Modules made sense to me as long as they were maps
from names to exported values:
```js
// Module 'library'
export function foo() {
}
export function bar() {
}
// Module 'client1'
With Web Components, we also get HTML Imports [1]. This seems like yet another
modularity construct on the web. Would it make sense to coordinate this with
ES6 modules? I’m also hoping/assuming that asm.js will eventually use ES6
modules(?)
[1] http://www.w3.org/TR/2013/WD-html-imports
HTML imports are importing HTML, not JS. Coordination is always good,
but I don't know what that would entail here.
asm.js modules have some specific needs, and it may or may not be able
to use ES6 modules. I'll let Dave speak to that.
Sam
On Sat, Jun 8, 2013 at 9:56 AM, Axel Rauschmayer
from the content, they are very similar to ES6 modules:
you would also want to load on demand, they have dependencies that need to be
fulfilledd, etc.
Axel
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com
not be able
to use ES6 modules. I'll let Dave speak to that.
Sam
On Sat, Jun 8, 2013 at 9:56 AM, Axel Rauschmayer a...@rauschma.de wrote:
With Web Components, we also get HTML Imports [1]. This seems like yet
another modularity construct on the web. Would it make sense to
coordinate
On Sat, Apr 13, 2013 at 4:52 PM, Kevin Smith zenpars...@gmail.com wrote:
Put concretely: if Futures are provided via libraries, but you can't
assume (require) libraries, then you can't design DOM APIs around Futures.
Clearly, one way to solve this is put Futures into the language, but
I think I've taken us off into the weeds, and I apologize. What I was
trying to say is that library authors have an advantage over platform
authors, in that they can require other libraries.
No - this is good input. You want to be able to modularize your platform
API, and not have to hang
1 - 100 of 132 matches
Mail list logo
