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 performance, and there’s
>> no desire to include an antipattern in the language.
>>
>>
>>
>
>
> Some counterpoint:
>
> For privileged/certified FirefoxOS apps, they are delivered as zip files
> right now. No HTTP involved. Asking for multiple files from these local
> packages was still slower than fetching one file with scripts bundled, due
> to slower IO on devices, so the certified apps in FirefoxOS right now still
> do bundling for speed concerns. No network in play, just file IO.
>
>
> With service workers, it is hard to see that also being faster since the
> worker needs to be consulted for every request, so in that FirefoxOS app
> case, I would still want bundling.
>
If we're just talking about scripts, why not simply cache the entire zip
file on the client end? That way there'd be only one request to the
service worker (and perhaps queries to see if the zip's been updated).
>
> With HTTP2, something still needs to do the same work as bundling, where
> it traces the dependencies and builds a graph so that all the modules in
> that graph can be sent back in the HTTP2 connection.
>
> So the main complexity of bundling, a "build" step that traces
> dependencies and makes a graph, is still there. Might as well bundle them
> so that even when serving from browser cache it will be faster, see device
> IO concerns above.
>
There's one big advantage of not bundling: debugging tools. Chrome's
debugger is much more stable than it used to be (I've not tried Firefox for
a long time), to the point that being able to load one's scripts in their
original form and map them to their location on the file system is quite
nice (you can then live edit scripts in Chrome DevTools, which is
unbelievably nice, you have no idea).
>
> Plus, bundling modules together can be more than just a speed concern: a
> library may want to use modules in separate files and then bundle them into
> one file for easier encapsulation/distribution.
>
Right. Bundling libraries for release builds makes perfect sense.
>
> I am sure the hope is that package managers may help for the distribution
> case, but this highlights another use related to bundling: encapsulation.
> Just like nested functions are allowed in the language, nested module
> definitions make sense long term. Both functions and modules are about
> reusing units of code. Ideally both could be nested.
>
> I believe that is a bigger design hurdle to overcome and maybe that also
> made it harder for the module champions to consider any sort of bundling,
> but bundling really is a thing, and it is unfortunate it is not natively
> supported for ES modules.
>
> The fun part about leaving this to transpilers is trying to emulate the
> mutable slots for import identifiers. I think it may work by replacing the
> identifiers with `loader.get('id').exportName`, or whatever the module
> meta/loader APIs might be, so having those APIs are even more important for
> a usable module system. There is probably more nuance to the transformation
> than that though. Like making sure to add in "use strict" to the function
> wrapper.
>
> 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 transpiling concerns, it does
> not seem like an improvement over an existing ES5-based module systems.
>
> James
>
>
Syntactically it's quite nice, though. IMHO, even if it's just syntactic
sugar it's still worth it. I remember thinking the grammar was insane when
I implemented 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
