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

[kdex]

For what it's worth, if you're only interested in v8, have a look at the 
"Performance" panel in DevTools. You can inspect "Parse" and "Compile" time by 
in the Bottom-Up view, given that you've enabled `Timeline: V8 Runtime Call 
Stats on Timeline` in the hidden options of`Experiments`.

On Friday, June 23, 2017 6:19:20 AM CEST kdex 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.
> 
> "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/c8167781/attachment.sig>