Staying Current: Reading Specs and Proposals

Frontend changes fast. New CSS, JS, and browser APIs ship every quarter. Senior engineers don't wait for blog posts — they read the source: W3C drafts, TC39 proposals, CSS WG specs, browser implementation status pages.

TC39 is the committee that evolves JavaScript. Proposals go through 5 stages: 0 (strawperson), 1 (proposal), 2 (draft), 3 (candidate), 4 (finished, shipped in ECMAScript). Stage 3 is when it's safe to bet on (browsers implement, syntax frozen).

Each proposal lives at github.com/tc39/proposal-NAME. The README explains the motivation, syntax, and examples. The 'spec text' branch has the formal grammar. Recent landings: Records & Tuples, Pipeline Operator, Decorators v3, Iterator Helpers.

github.com/tc39/proposals: list of every proposal with stages. 2ality.com: Axel Rauschmayer's blog summarises every meeting. v8.dev: Google's V8 ships proposals fastest, blog posts explain them.

W3C standardises CSS, ARIA, web APIs. WHATWG maintains HTML, DOM, Fetch, URL — the 'living standards'. Both work in public on GitHub. Filing issues on WHATWG's html repo is open to anyone.

The CSS WG ships specs continuously: container queries, :has(), CSS nesting, view transitions, anchor positioning, scroll-driven animations. Track via github.com/w3c/csswg-drafts and the CSS WG blog.

Even a Stage 4 proposal isn't usable until browsers ship it. Check: caniuse.com (general), chromestatus.com (Chrome), webkit.org/status (Safari), platform-status.mozilla.org (Firefox).

web.dev/baseline reports which features are 'Newly available' (in latest of all major browsers) and 'Widely available' (~30 months in). Excellent for deciding what's safe to ship.

1) web.dev/blog — Google web devrel. 2) WebKit blog — Safari announcements. 3) v8.dev/blog — V8 / Chrome JS. 4) CSS-Tricks newsletter. 5) JavaScript Weekly / Frontend Focus. 6) This Week in WebKit.

Read the source of libraries you use. React, Vue, Vite — all on GitHub. Reading how the maintainers solved tricky problems is one of the best ways to level up.

Don't just read about new features — try them. Build a tiny demo with View Transitions API, with :has() selector, with the new ECMAScript Set methods. You only really learn by using.

Not every shiny new thing belongs in production. Ask: is it Baseline? does it work in our target browsers? what's the polyfill cost? what problem does it solve that the current approach doesn't? does my team know it? Adopt deliberately, not reflexively.

File issues on TC39 / WHATWG proposals with use cases and counter-examples — the committees genuinely listen to developers. Open-source your demos. Comment on proposals you care about. This is how the platform improves.

Senior engineers think in years, not sprints. Reading specs makes you the person who knew about :has() six months before everyone else, who chose the right data-fetching library before the team got burned, who understood Server Components before the migration. That foresight compounds.

At which TC39 stage is a JavaScript proposal generally considered safe to start using in production with a transpiler?

Read the source: TC39 proposals, W3C/WHATWG specs, CSS WG drafts. Stage 3+ is safe for production with a transpiler. Track via caniuse, chromestatus, webkit.org/status, Baseline (web.dev/baseline). Subscribe to web.dev, WebKit blog, v8.dev, CSS-Tricks, JS Weekly. Build demos to internalise. Evaluate critically. Contribute back. Senior thinking compounds — the engineer who reads specs leads.