are there metrics on how es6 and future proposals affect javascript load-time for webpages?

[kdex]

> > First of all, ECMAScript requires an environment, which may or may not be
> > a browser. So it might not necessarily make sense to assume "web pages" or
> > browsers in the first place.
> 
> wrong. all proposals eventually end up creeping into “web pages” or
> browsers, either by adventurous coders or frameworks that lack clear
> boundary separation between client / server code.

"Wrong"? It seems that you are confused about how the language works. Feel 
free to read this[1] section of the language specification.

> both parse-time and [first-run] compile-time.  the intent is to vet most
> language-changing proposals for their impact on initial webpage “freeze"
> due to increased parse-time and compile-time complexity.

AFAIK, ECMAScript doesn't force implementers to "compile" anything, i.e. run a 
native code generation step as popular engines do. As you're more or less 
dealing with engine-specifics here, you're leaving ECMAScript territory, so 
this would likely be the wrong mailing list. The same really applies to parse 
time; the language specification doesn't specify a parser, but a grammar. The 
performance really depends on how the parser is implemented, as well as on the 
type of grammar/amount of look-ahead needed.

> hypothetically, can an enterprising individual provide a graph of 1)
> combined-time to parse-and-compile jquery vs 2) browser-version-history for
> desktop chrome and firefox since 2015?

I'm reading this as "Could I create a graph that plots a specific browser 
version on the x axis and parse time + compile time on the y axis?", and the 
answer would be 'yes'. As a side note, do note that *absolute* time is a 
terrible metric here, as device specs can differ by a lot and aren't actually 
representative for anything but themselves. Relative times should be 
preferred. Nonetheless, if you want to gather this data, you can look up the 
respective engine versions that were used for the browser versions in 
question, edit their source to measure the intervals that you find interesting 
and then compile and run them.

> yes, relevant proposals should consider the implementation-specific
> compile-time of engines

Should they really? If a parser is badly implemented, it should be fixed, not 
worked around. Again, it's really a question of the type of grammar and the 
type of parser used. The features involved are second nature, at least for the 
metrics you're trying to measure.

> as an added precaution against breaking the web.
This is not "breaking the web", because we're not talking about websites that 
worked once, but don't work anymore, given the same code. We're simply talking 
about "parse and compile" performance here.

[1] https://tc39.github.io/ecma262/#sec-overview

On Friday, June 23, 2017 5:37:17 AM CEST kai zhu wrote:
> > First of all, ECMAScript requires an environment, which may or may not be
> > a
> > browser. So it might not necessarily make sense to assume "web pages" or
> > browsers in the first place.
> 
> wrong. all proposals eventually end up creeping into “web pages” or
> browsers, either by adventurous coders or frameworks that lack clear
> boundary separation between client / server code.
> > is "load time" equivalent
> > to "parse time"? Is it "compile time"? Is it both?
> 
> both parse-time and [first-run] compile-time.  the intent is to vet most
> language-changing proposals for their impact on initial webpage “freeze"
> due to increased parse-time and compile-time complexity.
> > Could you state your question more precisely, please?
> 
> hypothetically, can an enterprising individual provide a graph of 1)
> combined-time to parse-and-compile jquery vs 2) browser-version-history for
> desktop chrome and firefox since 2015?
> > Anything else [compile-time] is mostly implementation-
> > specific and thus varies from engine to engine.
> 
> yes, relevant proposals should consider the implementation-specific
> compile-time of engines as an added precaution against breaking the web.
> On 22 Jun, 2017, at 8:20, es-discuss-request at mozilla.org wrote:
> > From: kdex <kdex at kdex.de>
> > Subject: Re: are there metrics on how es6 and future proposals affect
> > javascript load-time for webpages? Date: 22 June, 2017 8:20:16 HKT
> > To: es-discuss at mozilla.org
> > 
> > 
> > I don't think that this is a well-defined question. Is "load time"
> > equivalent to "parse time"? Is it "compile time"? Is it both? Is it
> > something else? Are we talking about engines that don't generate native
> > code and thus maybe "interpretation time"? What are we measuring when you
> > say "JavaScript load time"?
> > 
> > First of all, ECMAScript requires an environment, which may or may not be
> > a
> > browser. So it might not necessarily make sense to assume "web pages" or
> > browsers in the first place.
> > 
> > Aside from that, a great deal of "load time" (?) will likely consist of
> > the
> > time needed to parse the source code. Anything else is mostly
> > implementation- specific and thus varies from engine to engine.
> > 
> > Could you state your question more precisely, please?
> > 
> > On Thursday, June 22, 2017 1:59:05 AM CEST kai zhu wrote:
> >> and should future proposals take load-time performance into account?
> >> 
> >> hi, i’m a new subscriber, and apologies if this seems like a newbie
> >> question.
> >> 
> >> a bit of trivia - i remember long ago (maybe 2010?) a website called
> >> “great
> >> computer language shootout” or something had d8 consistently having the
> >> fastest load-time of all interpreted languages benchmarked.  i recent
> >> google-search led me to maybe the same website
> >> (http://benchmarksgame.alioth.debian.org), but i can no longer find
> >> load-time stats.
> >> 
> >> -kai
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20170623/0b59f78c/attachment.sig>