github at esdiscuss.org (2013-07-12T02:27:37.709Z)
2013/6/2 David Bruant <bruant.d at gmail.com> Good points, thanks! > 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. > [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,
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>