Finalize assignments: Chapter 1. JavaScript

[rviscomi]

Section	Chapter	Coauthors	Reviewers
I. Page Content	1. JavaScript	@addyosmani @housseindjirdeh @mathiasbynens	@rwaldron @RReverser

Due date: To help us stay on schedule, please complete the action items in this issue by June 3.

To do:

• Assign subject matter experts (coauthors)
• Assign peer reviewers
• Finalize metrics

Current list of metrics:

• Transfer size/count

  • Distribution of JS bytes
  • Distribution of first party JS bytes vs. third party
  • Number of JS requests
  • Number of first-party JS requests vs. third-party
  • % of gzip-compressed scripts
  • % of brotli-compressed scripts

• Runtime cost

  • Breakdown of V8 CPU times (if feasible)

• Library usage

  • Top N JS libraries
  • Notable changes in popularity since last year
  • Top N JS client-side frameworks (React, Vue, etc…)
  • Distribution of JS bytes on site per JavaScript framework

• Feature adoption

  • % of pages that use <script type=module>
  • % of pages that use <script nomodule>
  • % of pages that use <link rel=preload> for JS resources
  • % of pages that use <link rel=modulepreload>
  • % of pages that use <link rel=prefetch> for JS resources
  • Use of navigator.connection.effectiveType property
  • Estimate adoption of specific JS language features (by looking for the following raw strings in JS response bodies)
    • Atomics
    • Intl
    • Proxy
    • SharedArrayBuffer
    • WeakMap
    • WeakSet
    • dynamic import (by looking for "import(")

• Other

  • % of sites that ship sourcemaps

👉 AI (coauthors): Finalize which metrics you might like to include in an annual "state of JS" report powered by HTTP Archive. Community contributors have initially sketched out a few ideas to get the ball rolling, but it's up to you, the subject matter experts, to know exactly which metrics we should be looking at. You can use the brainstorming doc to explore ideas.

The metrics should paint a holistic, data-driven picture of the JS landscape. The HTTP Archive does have its limitations and blind spots, so if there are metrics out of scope it's still good to identify them now during the brainstorming phase. We can make a note of them in the final report so readers understand why they're not discussed and the HTTP Archive team can make an effort to improve our telemetry for next year's Almanac.

Next steps: Over the next couple of months analysts will write the queries and generate the results, then hand everything off to you to write up your interpretation of the data.

Additional resources:

• All chapter assignments
• Project timeline
• About the project

[rviscomi]

@addyosmani @housseindjirdeh @mathiasbynens can you think of anyone who might be interested in peer reviewing this chapter?

[rwaldron]

Hello! @zcorpan shared this project with me and suggested that I might be interested in reviewing the JavaScript chapter—he was right, I am interested!

[rviscomi]

Another Rick!

Hello @rwaldron glad to have you on board! I've added you as a reviewer.

[rwaldron]

Excellent!

[rwaldron]

Thinking about possible metrics, but not sure what the limitations are, so anything that's easily dismissed, please do so...

• Appearance of new ECMAScript features, adoption growth over time
  • Some areas of particular interest for me are:
    • Proxy objects
    • WeakSet & WeakMap objects
    • Module code
    • async/await
    • Atomics/SharedArrayBuffer
    • Intl.* APIs
• Use of Generic Sensor API suite (this may be better left for future editions)
  • Measuring the move away from the old APIs in favor of new (not sure if this is even possible?)
  • Emergence of new occurrences of sensory APIs in the wild

[RReverser]

Hello! I'd be happy to join as a peer reviewer too if you need any more eyes.

[rviscomi]

@RReverser that would be great thanks! Adding you as a reviewer and sending you an invitation to the Reviewers team.

[moos]

@rwaldron: been thinking the same. I'd add arrow functions, spread operator, classes, generators. I've seen the JavaScript language improve but also become a bit bloated over the years. It's be nice to see the adoption trends of these new language features.

[rviscomi]

@addyosmani @housseindjirdeh @mathiasbynens hoping to have the metrics for this chapter finalized today. We have a scant 3 metrics so far, not counting the suggestions in #3 (comment). Aiming for 10 metrics per chapter, but I think JS is such a big/important topic that it could easily be 20 or 30 metrics (not so bad with 3 coauthors). Could you all brainstorm metrics and add them to the doc or edit this issue at your earliest convenience?

@rwaldron @RReverser if there are any other metrics you can think of that belong in this chapter, feel free to suggest them in either place.

[rviscomi]

@addyosmani @housseindjirdeh @mathiasbynens reminder to please close this out today ❤️

[rviscomi]

🛎 @addyosmani @housseindjirdeh @mathiasbynens this is one week overdue, please close it out as soon as possible.

[housseindjirdeh]

Updated the first comment with the list from brainstorming doc.

Everything LGTM. Will defer to @mathiasbynens in case there's anything else worth considering

[mathiasbynens]

Sorry for the delay.

I had added some suggestions to the brainstorming doc previously, and have just now added another round of items (and I've updated the top post here accordingly).

@rwaldron and @moos had some great ideas! Unfortunately for lots of JS language features (especially syntactic features) it's hard to get accurate metrics just by querying the HTTP Archive. We can't just grep all JS responses for async or await, for example, as they're contextual keywords, and so we might potentially hit lots of false positives. To a lesser degree, this is true for non-syntax features (i.e. APIs, such as SharedArrayBuffer) as well.

[zcorpan]

@mathiasbynens would it be feasible to add new use counters in chromium?

[mathiasbynens]

@zcorpan It depends on the feature, since use counters come at a performance cost. We probably wouldn't want to incur a perf hit for every single arrow function, for example.

[zcorpan]

Yes, I agree with that. Would it be possible to enable use counters on-demand for the purpose of collecting information in an HTTP Archive run, without having the use counter enabled for all users?

[mathiasbynens]

Such counters would need to live behind a build-time flag to not incur any cost to users. (Even adding it behind a run-time flag would mean having to check for the flag all over the place.) It definitely sounds possible, it’s just not something we have in V8/Chromium right now.

[rviscomi]

FYI https://stateofjs.com/ (2018 is the latest survey)

Similar research project into the state of JS, the biggest difference being that one is a survey of developers while this is a survey of websites. Might be interesting to see if any of those results help inform some of the trends we see in HTTP Archive, if so feel free to cite that project in your chapter as needed.