github at esdiscuss.org (2013-07-12T02:27:36.798Z)
Le 01/06/2013 21:10, Petter Envall a ?crit : > 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 practice. 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, https://bugzilla.mozilla.org/show_bug.cgi?id=627531 [4]: https://github.com/DavidBruant/ECMAScript-regrets
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 practice. I believe ES6 modules are the way forward to replace top-level IIFEs. 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130601/7454b56c/attachment-0001.html>