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

[kai zhu]

> 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 --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20170623/52b3b0c5/attachment-0001.html>