Le 01/06/2013 23:14, Petter Envall a écrit :
>
>
>     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).
Do you have examples of such systems?
In a world with multiplexing and server push, what is the benefit of a 
single-file widget?

>
>
>     "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.
Only within new syntax IIRC (modules, classes). Outside these new syntax 
constructs, non-strict will remain non-strict.

>
>     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".
What are you referring to?
The example that triggered my answer then yours only used "let" as new 
feature. And even hacked around with old features (label+break), it 
wasn't fragile after all.
What is fragile about new features?

I believe we're having a dogma issue. Concatenation is not an 
unconditionally good idea. It's only become a good practice because of 
HTTP 1.x and the inherent latency of the network. Improve HTTP and the 
good practice is ready to be questioned.

>
>     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.
There is also a granularity problem. If you concat all the files 
together, it takes time to parse/run. If you can send all the files at 
once (server push), but have them run only when needed, you're saving a 
bit of CPU time.

> 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.
I don't get it. If by "it", you're referring to "concatenation", I 
highly recommend reading Ilya Grigorik talk (Slides 42-43 this time)
http://www.igvita.com/slides/2013/fluent-perfcourse.pdf

HTTP 2 enables web devs to get rid of all the dirty hacks we've been 
forced to do because of HTTP 1.x limitations (like concatenation, 
sprites, asset sharding in multiple domains...). Having the opportunity 
to undo all of that is the opposite of 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
I am under the impression that you don't fully understand how web 
standards work. The ES5/"use strict" problem will never go away. The 
very first rule of evolving something on the web platform is to break no 
website.
ES6 only brings new feature and the *hope* is that people will use these 
new features which are safe by default and incidentally stop using 
unsafe features.
Again, concatenation is a hack to work around an HTTP limitation; not an 
inherently good idea. I don't think "plain concatenation" is a 
worthwhile consideration for how the language works.

> and that it would not be replaced by another quirk regarding this 
> practice.
It is not... Modules will replace top-level IIFEs.

Hmm... All your answers are shaped as "yes, but..."

David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130601/8c60c19d/attachment-0001.html>

Le 01/06/2013 23:14, Petter Envall a ?crit :
> Yes, but concatenation may not be the only "need" (thinking of build 
> systems to produce a single file for a widget script or something).

Do you have examples of such systems?
In a world with multiplexing and server push, what is the benefit of a 
single-file widget?

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

Only within new syntax IIRC (modules, classes). Outside these new syntax 
constructs, non-strict will remain non-strict.

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

What are you referring to?
The example that triggered my answer then yours only used "let" as new 
feature. And even hacked around with old features (label+break), it 
wasn't fragile after all.
What is fragile about new features?

I believe we're having a dogma issue. Concatenation is not an 
unconditionally good idea. It's only become a good practice because of 
HTTP 1.x and the inherent latency of the network. Improve HTTP and the 
good practice is ready to be questioned.

> Yeah concatenation may be costly in the way that it can cause 
> conflicts under various circumstances.

There is also a granularity problem. If you concat all the files 
together, it takes time to parse/run. If you can send all the files at 
once (server push), but have them run only when needed, you're saving a 
bit of CPU time.

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

I don't get it. If by "it", you're referring to "concatenation", I 
highly recommend reading Ilya Grigorik talk (Slides 42-43 this time)
http://www.igvita.com/slides/2013/fluent-perfcourse.pdf

HTTP 2 enables web devs to get rid of all the dirty hacks we've been 
forced to do because of HTTP 1.x limitations (like concatenation, 
sprites, asset sharding in multiple domains...). Having the opportunity 
to undo all of that is the opposite of disappointing.

> I'm sure they are. I just thought the concatenation problem that arose 
> with ES5/"use strict"; would be gone by ES6

I am under the impression that you don't fully understand how web 
standards work. The ES5/"use strict" problem will never go away. The 
very first rule of evolving something on the web platform is to break no 
website.
ES6 only brings new feature and the *hope* is that people will use these 
new features which are safe by default and incidentally stop using 
unsafe features.
Again, concatenation is a hack to work around an HTTP limitation; not an 
inherently good idea. I don't think "plain concatenation" is a 
worthwhile consideration for how the language works.

> and that it would not be replaced by another quirk regarding this 
> practice.

It is not... Modules will replace top-level IIFEs.

Hmm... All your answers are shaped as "yes, but..."