IIAFEs?

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.
>

Good!



>
> 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