Finalize assignments: Chapter 1. JavaScript

[httparchive]

Finalize assignments: Chapter 1. JavaScript

[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.

[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.

[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

[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.

[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]

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

[rwaldron]

Excellent!

[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

[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?

[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.