On Apr 23, 2015, at 10:35 PM, James Burke wrote:
> On Thu, Apr 23, 2015 at 4:48 PM, Brendan Eich <[email protected]> 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 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.
>
> 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 module meta.
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 upon the external
representation of Modules. One Script or Module per external contain or
multiple Scripts and Modules per external container - it makes no difference
to the ES 2015 semantics.. Such encoding issues are entirely up to the host
platform or ES implementation to define. But the platform/implementation has
no choice in regard to the semantics of a Module (including mutability of slots
or anything else in the ES 2015 specification). No matter a Module is
externally stored it must conform to the ES 2015 module semantics to be a valid
ES 2015 implementation.
So, if you want physical bundling, you need to convince the platform designers
(eg, web, node, etc) to support that. Personally, I think a zip file makes a
fine "bundle" and is something I would support if I was building a command-line
level ES engine.
Allen
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
