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 > 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. > > Understood: the ES2015 spec makes it a point to not get into this. I was hoping that the module champions involved with the ES2015 spec would be on this list to respond to how to use modules in practice. So perhaps I was incorrect to ask for "officially blessed", but more "a bundling form that module champions know will meet the ES2015 semantics of a Module". The difficulty is precisely that ES2015 sets strong semantics on a Module that seem difficult to translate to a script form that could allow bundling. I expect module meta to play a fairly important role for that translation, so having that defined, in some ES spec or elsewhere, and how that might work in bundling, would also be really helpful to complete the module picture. > > 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. > See my first post to this thread why when we had this in practice in FirefoxOS, a zip file with the contents, it was decided to use script bundling to increase performance. With the extensible web and more userland JS needed to bootstrap things like view selection and custom elements, getting the JS up and running as soon as possible is even more important. The arguments so far against script bundling have been "there are better things that can be made for performance", but I do not see that in practice, particularly for the offline web on mobile devices. Besides that, I see modules as units of reusable code, like functions, which do allow bundling, nesting. I can understand that is not the goal of ES2015, so hopefully the use case feedback will be useful to help flesh out a full module system that can use the ES module semantics. James
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
