Petter Envall petter.envall at gmail.com
Sat Jun 1 23:14:11 PDT 2013

2013/6/2 David Bruant <bruant.d at gmail.com>

Good points, thanks!

 Le 01/06/2013 21:10, Petter Envall a écrit :
> 2013/6/2 David Bruant <bruant.d at gmail.com>
>> Le 01/06/2013 16:52, Jorge a écrit :
>>  On 02/06/2013, at 01:22, Brandon Benvie wrote:
>>>> On 6/1/2013 3:44 PM, Jorge wrote:
>>>>> But they're not fully interchangeable, for example I can exit a
>>>>> function at any point with a return, but can I exit a block at any point
>>>>> with a break or something?
>>>>     block: {
>>>>       if (true) {
>>>>         break block;
>>>>       }
>>>>     }
>>> What might happen with this is that if you concatenate a bunch of .js
>>> files that use this pattern, they might end redefining the same label
>>> (which would be an error, I guess). Wrapping it all in another block would
>>> solve that?
>>> {
>>>    block: {
>>>      if (true) {
>>>        break block;
>>>      }
>>>    }
>>> }
>>> But then... I'm not sure this is any better than an IIFE!
>>  You can also use a less naive concatenator. Labels seem to be very
>> static parts of a JS program. It sounds doable to find and rewrite them.
>> Given what people have been doing with esprima recently [1], I have the
>> impression it would be even easy (?)
> David
>> [1] https://github.com/olov/defs
>  Ouch?
>  It seems like a sorry path to take that makes one have to comfess "Yes.
> In this language we have made some improvements that make it unsafe to
> concatenate program files like before - without using a parser/rewriter".
> Or is there another way?
> I'm not too familiar with JS labels, but I learned from Brandon's message
> that it is actually safe to concatenate with repeating labels [1], so no
> need for rewritters in the end.


> Re "In this language", I'm not aware of other languages where you need to
> concatenate code. It has become a good practice for perf on the web as a
> workaround of HTTP 1.x limitations.
> HTTP 2 promises that with multiplexing, script concats won't be necessary
> anymore (and may even become a bad practice); server push will also be
> possible [2] so that we can keep several <script> elements and ES6 modules
> as separate files without performance issues.

Yes, but concatenation may not be the only "need" (thinking of build
systems to produce a single file for a widget script or something). Guess
it is not unreasonable either to make a system for such ends work a little
bit harder if it has to (or use a different approach altogether).

> "make it unsafe to concatenate program files like before"
> => Heard of what happens when naively concatenating files using strict
> mode inconsistently? [3] :-)

But my impression is "strict" is to be implicit in es6 anyway, so that
problem for concatenation would not be present by then? Happy to be
corrected here.

> Even before strict mode, loading JS on one of several <script> elements
> has observable behavior (number of <script> elements) and can cause bugs in
> fragile code.
> Also, document.write has a different semantics if run in an inline script
> or a loaded script.
> In any case, it's not new that how JS is packaged and loaded can be
> observed at runtime and lead to bugs if the loaded code behavior depends on
> that. It's been fought with conventions and tools. I don't thing that'll
> stop with any version of the language.

True, agree. I was just thinking.. a lot of the awesomeness of new the
features would cause fragility, without one even having used any "weird"
constructs - just the feature and "plain old concatenation".

> Maybe that'll stop when the majority of servers and clients support HTTP
> 2. 20 years from now? 30? The problem is concatenation, not the language.

Yeah concatenation may be costly in the way that it can cause conflicts
under various circumstances. Though, it has been part of the trade for
quite a while, and "breaking" (which probably is too strong a word) what
worked with it would be a little disappointing.

> Regardless, compile-to-JS tools are the future for large scale
> applications. Look at the current trend. CoffeeScript, Dart, TypeScript,
> etc. This isn't an isolated effort. HTML is generated from HTML template
> languages (handlebar, moustache, jade, etc.). CSS is generated from other
> languages (SASS, LESS, etc.).
> These preprocessor tools are necessary to abstract away what I call
> "regrets" [4], that is cruft and annoyances due to the course of history.
> Also you don't necessarily deploy your code to the browser the same way
> your organize it for maintainability purposes.
>    Otherwise it seems tom me like IIFEs still would do the best job
> defining "modules" (in the sense "parts of a program") in the outermost
> scope.
> I feel this thread was more exploratory than trying to define a good
> practice.
> I believe ES6 modules are the way forward to replace top-level IIFEs.

I'm sure they are. I just thought the concatenation problem that arose with
ES5/"use strict"; would be gone by ES6, and that it would not be replaced
by another quirk regarding this practice.

> David
> [1] https://mail.mozilla.org/pipermail/es-discuss/2013-June/030953.html
> [2] Slide 48-51 of http://www.igvita.com/slides/2013/fluent-perfcourse.pdf
> [3] https://bugzilla.mozilla.org/show_bug.cgi?id=579119
> https://bugzilla.mozilla.org/show_bug.cgi?id=627531
> [4] https://github.com/DavidBruant/ECMAScript-regrets

Thanks for the links too,

// P
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130602/c75fe331/attachment.html>

More information about the es-discuss mailing list