> 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-requ...@mozilla.org wrote: > From: kdex <k...@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@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
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
