David Bruant bruant.d at gmail.com
Sat Jun 1 21:57:42 PDT 2013

Le 01/06/2013 21:10, Petter Envall a écrit :
> 2013/6/2 David Bruant <bruant.d at gmail.com <mailto: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.

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

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 
I believe ES6 modules are the way forward to replace top-level IIFEs.


[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
[4] https://github.com/DavidBruant/ECMAScript-regrets
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130601/7454b56c/attachment-0001.html>

More information about the es-discuss mailing list