Every web developer knows the anxiety: a new framework trends on social media, a hot take declares your stack obsolete, and you wonder if you've fallen behind. The truth is that the web platform moves on a much slower, much more predictable clock than the discourse suggests — and the roadmap is public. You just have to know where it's published.
This post maps the sources that actually predict where the platform is going: standards bodies, browser vendor programs, runtime release schedules, ecosystem RFCs (request-for-comments proposals), surveys, and events. At the end there's a practical system for consuming all of it without burning out.
The sources fall into six tiers, ordered from the most upstream signal — where a feature is born, years before you can use it — down to the most digested, where someone else has already read everything for you:
Tier 1: The standards pipeline (where features are born)
Everything that ends up in your browser starts as a proposal in one of a handful of standards bodies. Watching these gives you a 1–3 year head start on what's coming.
TC39 — the future of JavaScript
TC39 (Ecma International's Technical Committee 39) is the committee that evolves ECMAScript. Its proposals repository on GitHub (tc39/proposals) is the single most reliable predictor of future JavaScript. Proposals move through stages:
| Stage | Meaning | Should you care? |
|---|---|---|
| 0–1 | Idea / under discussion | Only if you enjoy speculation |
| 2 | Draft, semantics roughed out | Worth reading, may change significantly |
| 2.7 | Approved pending tests | Very likely to ship |
| 3 | Ready for implementation | Browsers are shipping it; learn it now |
| 4 | Finished | It's in the annual ECMAScript release |
Practical gotcha: a Stage 3 proposal can still be demoted (Array grouping was renamed mid-flight; decorators sat at Stage 2 for years). Treat Stage 3 as "safe to learn, be careful shipping without transpilation."
WHATWG and W3C — HTML, DOM, CSS
The W3C (World Wide Web Consortium) and the WHATWG (Web Hypertext Application Technology Working Group) maintain the specs for HTML (HyperText Markup Language), the DOM (Document Object Model), and CSS (Cascading Style Sheets):
- WHATWG Living Standards (HTML, DOM, Fetch, Streams): there are no versions anymore. The spec is a living document, and the interesting activity happens in the GitHub issues and pull requests (PRs) of
whatwg/htmlandwhatwg/dom. - CSS Working Group (
w3c/csswg-drafts): if you want to know why a CSS feature behaves the way it does — or when the weird edge case you hit will be fixed — the resolution is usually in a CSS Working Group issue thread. The group publishes minutes of every meeting. - WICG (Web Incubator Community Group): where speculative browser APIs (application programming interfaces) incubate before they're mature enough for a standards track. View Transitions, Portals, and many Chromium-first APIs started here.
You don't need to read specs daily. But when you're evaluating whether a feature is "real" or a single-vendor experiment, checking whether it has a mature spec in one of these venues is the test that matters.
Tier 2: Browser vendor signals (where features become usable)
Interop — the annual cross-browser roadmap
The Interop project is the closest thing the web platform has to a published yearly roadmap. Apple, Google, Microsoft, Mozilla, Igalia, and Bocoup agree on a set of focus areas each year and publicly track pass rates on a shared dashboard. Interop 2026 includes twenty focus areas, among them anchor positioning, container style queries, dialog/popover improvements, CSS shape(), scroll snap, and cross-document view transitions, plus web-compat cleanup work on things like ECMAScript-module (ESM) loading edge cases and unprefixing -webkit-user-select.
If a feature is an Interop focus area, you can plan around it landing everywhere within roughly a year. Interop focus areas only include features with mature specs and automated tests, and every engine has committed engineering time to them. The 2025 cycle took the combined browser score from 25 to 95 and delivered same-document View Transitions, CSS Anchor Positioning, the Navigation API, @scope, and URLPattern cross-browser.
Sources: the Interop dashboard (wpt.fyi/interop), the web-platform-tests/interop GitHub repo, and the annual announcement posts from web.dev, WebKit, Mozilla Hacks, and the Edge blog — reading all four vendor posts side by side is genuinely useful, because each vendor emphasizes what they consider strategic.
Baseline — the adoption traffic light
Baseline (surfaced on MDN — the Mozilla Developer Network — web.dev, caniuse, and webstatus.dev) answers the only question that matters day to day: can I ship this?
| Baseline status | Meaning | Adoption strategy |
|---|---|---|
| Not in all core browsers | Progressive enhancement only, or don't | |
| Works in latest versions of all core browsers | Fine for apps with evergreen users; check your analytics | |
| ~30 months of cross-browser support | Ship it without a second thought |
Gotcha: "Newly available" starts the clock when the last engine ships. A feature can be years old in Chrome and days old in Baseline. Your user base — not the badge — decides whether "newly" is good enough. Check your own browser analytics before celebrating.
Release notes and preview channels
Each vendor publishes release notes on a predictable cadence (Chrome roughly every four weeks, Firefox similar, Safari tied to operating-system (OS) releases plus Safari Technology Preview in between):
- Chrome: Chrome Platform Status (
chromestatus.com) — filterable by release, includes intent-to-ship signals from Blink development. - Firefox: Firefox release notes for developers on MDN, plus Mozilla Hacks for the narrative.
- Safari: the WebKit blog. Safari release notes are dense; WebKit blog posts explain what's actually interesting.
- "New to the web platform" monthly digests on web.dev summarize all engines in one post — the highest signal-to-effort ratio in this entire category.
Tier 3: Runtimes and tooling (where your stack evolves)
Node.js
Node's release schedule (nodejs/Release on GitHub) is boringly predictable, and that predictability is the point: a new major every six months, even-numbered majors promoted to Long-Term Support (LTS) in October, roughly 30 months of support. Develop against Current if you like, deploy on Active LTS, and put the LTS transition dates in your calendar — that's when you schedule the upgrade PR, not when production forces you to.
The nodejs/node releases page and the official blog announce features like native TypeScript execution and permission model changes well before they're stable. If you run Docker images, watching the LTS calendar also tells you when your base images go stale.
Your bundler and test runner
For those of us on Vite and Vitest, the roadmap lives in the open:
- Vite / Rolldown: the
vitejs/viteandrolldown/rolldownrepos, the Vite blog, and ViteConf talks. Major architectural shifts (like the Rolldown-based bundling core) are announced and RFC'd — circulated as public request-for-comments proposals — long before they land, so the migration guides practically write themselves if you've been watching. - Vitest: release notes on GitHub are detailed and honest about breaking changes. Browser Mode's evolution has been trackable release by release.
- RFC repositories in general: React (
reactjs/rfcsand the React Labs blog posts), TypeScript (the iteration-plan issue pinned inmicrosoft/TypeScriptevery release cycle — it tells you months in advance exactly what's in the next version). TypeScript's iteration plans are criminally underused as a planning tool.
Gotcha: GitHub release notes ≠ roadmap. The roadmap is usually in a pinned issue, a ROADMAP.md, a milestones page, or the maintainers' conference talks. When evaluating a dependency for long-term use, the existence and freshness of such a document is itself a health signal.
Tier 4: Surveys and data (where the ecosystem consensus shows)
Reading these tells you what browser vendors will fix next.- State of JS / State of CSS / State of HTML (Devographics): beyond the framework popularity contests, the "pain points" sections directly feed browser priorities — Interop 2026 explicitly used State of HTML and State of CSS results to pick focus areas.
- Web Almanac (HTTP Archive): what the web actually uses, measured from millions of real pages. The corrective to Twitter-driven perception. When you think "everyone uses X," the Almanac usually says otherwise.
- Stack Overflow Developer Survey: broader than web, useful for hiring-market and salary signal more than technical roadmap.
Tier 5: Events (where direction is announced)
You don't need to attend; the talks are the artifact, and almost all publish recordings within weeks. Watching two or three keynotes per year plus reading the TC39 meeting summaries covers most of the strategic signal.
| Event | What it signals |
|---|---|
| Google I/O (May) | Chrome and web platform strategy for the year |
| Apple WWDC — Worldwide Developers Conference (June) | Everything Safari will ship, Progressive Web App (PWA) / iOS web capabilities |
| ViteConf | Vite ecosystem roadmap: Rolldown, Vitest, framework integrations |
| React Conf | React's multi-year direction (Server Components, the compiler) |
| JSConf / JSNation / CityJS | Ecosystem breadth, TC39 members often preview proposals |
| TC39 plenaries (6× per year) | Proposal stage advancements; minutes published on GitHub |
Tier 6: Curation (letting others read for you)
Newsletters and podcasts are aggregation layers over everything above. A short, high-signal list:
- JavaScript Weekly / Frontend Focus / Node Weekly (Cooperpress) — comprehensive, low-editorializing weekly digests.
- Bytes — the same news with jokes; genuinely easier to retain.
- web.dev blog and its monthly platform digests — vendor-written but engine-neutral in the digest series.
- Syntax / JS Party (podcasts) — good for commute-time coverage of ecosystem debates you'd otherwise only see fragments of.
Newsletters are a discovery layer, not a decision layer. Never adopt something because a newsletter featured it; adopt it after the Tier 1–3 sources confirm it's on a standards track or has a healthy roadmap.
A sustainable system: the cadence table
Trying to follow everything continuously is how people burn out and quit reading entirely. Assign each source a frequency instead:
| Cadence | Time budget | Sources |
|---|---|---|
| Weekly | 20–30 min | One newsletter (JavaScript Weekly or Bytes), skim only |
| Monthly | 30–45 min | web.dev platform digest, release notes of your stack (Node, Vite, Vitest, React, TypeScript) |
| Quarterly | 1–2 h | Interop dashboard check, TypeScript iteration plan, TC39 stage changes, Baseline status of features you postponed |
| Yearly | Half a day | State of JS/CSS/HTML results, Interop announcement (all four vendor posts), two or three conference keynotes, review your own stack's roadmap docs |
The decision framework: is this future-proof?
When a new feature, API, or tool crosses your radar, run it through this before committing production code to it:
| Question | Green flag | Red flag |
|---|---|---|
| Is there a mature spec? | ||
| Cross-engine commitment? | ||
| Baseline status vs. your analytics? | ||
| Is there a public roadmap? | ||
| Who pays for it? |
Software that's "future proof" isn't software that uses the newest thing — it's software aligned with where the committed, multi-vendor roadmap is going, with graceful degradation for everything else. The roadmap is public. Standards bodies publish their minutes, browser vendors publish their yearly commitments, runtimes publish their release calendars, and serious tools publish their RFCs. The developers who seem effortlessly up to date aren't reading more than you — they're reading upstream of you.
References
- TC39 proposals —
tc39/proposals, the staged pipeline of future JavaScript. - WHATWG HTML and WHATWG DOM — living standards for HTML and the DOM.
- CSS Working Group drafts —
w3c/csswg-drafts, CSS specs and meeting resolutions. - Web Incubator Community Group (WICG) — incubation venue for speculative browser APIs.
- Interop project — the shared cross-browser roadmap and test suite.
- Interop 2026 announcements: web.dev, WebKit, Mozilla Hacks, Microsoft Edge.
- Interop 2025: A year of convergence (WebKit) — the 25→95 score and features delivered.
- Interop dashboard — live pass-rate scores at
wpt.fyi. - Baseline — cross-browser availability status, surfaced on MDN, caniuse, and webstatus.dev.
- Chrome Platform Status, the WebKit blog, and Mozilla Hacks — vendor release notes and narratives.
- Node.js release working group, Node.js releases, and the Node.js blog.
- Vite, Rolldown, and the Vite blog.
- React RFCs, the React blog, and TypeScript (iteration plans pinned each cycle).
- State of JS, State of CSS, State of HTML (Devographics); Web Almanac (HTTP Archive); Stack Overflow Developer Survey.
- Newsletters and podcasts: JavaScript Weekly, Frontend Focus, Node Weekly, Bytes, Syntax, JS Party.