The Spec, TC39 & Staying Current

JavaScript changes every year, but not every exciting blog post describes something you can safely use today. The skill is learning the pipeline: the ECMAScript specification defines the language, TC39 moves proposals through stages, runtimes ship support on their own schedules, and your project still has to check its actual targets.

The spec is the rulebook

The JavaScript language is standardized as ECMAScript. The spec is the rulebook engines must follow: V8, SpiderMonkey, JavaScriptCore, and other engines can use different internals, but they should agree on what valid JavaScript means and what observable results it produces.

That connects directly to the last two lessons. V8 can optimize hidden classes and inline caches, but those are implementation choices. DevTools can show performance and memory behavior, but the language meaning still comes from ECMAScript. When you ask "is this JavaScript?", the spec is the deepest answer.

You do not need to read the full spec like a novel. Most working developers use it in three practical ways:

• To confirm exact semantics when docs disagree.
• To understand whether a feature is part of the language or just a tool/framework extension.
• To trace a proposal's maturity before betting a codebase on it.

TC39 stages, beginner-safe

TC39 is the committee that evolves ECMAScript. Proposals move through stages 0 through 4. The exact committee process has formal details, but the beginner mental model is:

Stage 0: an idea is being floated.
Stage 1: the problem and rough direction are accepted for exploration.
Stage 2: the proposal has a draft shape worth serious review.
Stage 3: the design is close; implementations and feedback matter.
Stage 4: the proposal is finished and ready to be included in the standard.

The stages are not a hype ladder where Stage 3 means "use it everywhere tomorrow." Stage 3 still needs runtime support, tooling support, compatibility testing, and project judgment. Stage 4 means the language work is finished, not that every browser, server runtime, bundler, linter, and type checker your users touch already handles it.

The yearly release train

ECMAScript now follows a yearly release rhythm. A finished proposal can land in a yearly edition, and the edition name becomes a helpful checkpoint: ES2025, ES2026, and so on.

Current verified sources for mid-2026 give us this snapshot:

ES2025 finalized in June 2025:
- iterator helpers
- Set methods such as union, intersection, and difference
- Promise.try
- RegExp.escape plus related RegExp additions
- import attributes and JSON modules
- Float16Array
 
ES2026 is finalizing now, with Stage 4 features including:
- Temporal
- Array.fromAsync
- Error.isError
- Math.sumPrecise
- Uint8Array base64/hex helpers
- iterator sequencing
- Map.prototype.getOrInsert

That list should feel familiar. You met iterator helpers in the iterator lesson, Set methods in the Set lesson, and Temporal in the dates lesson. The new idea here is not the syntax; it is the pipeline. A feature can be standard-track, finalized, documented, partly shipped, broadly shipped, or polyfilled. Those are different states.

Temporal is the perfect example. Current verified sources say Temporal reached Stage 4 on 11 Mar 2026. Current compatibility data also says Firefox 139, Chrome 144, Edge 144, and Node 26 ship it by default, while Safari stable still lacks it. So the professional sentence is not "Temporal is done, use it blindly." It is "Temporal is the standard replacement path; check target runtime support and use the polyfill when needed."

New lately, coming next

Here is how to talk about the current feature landscape without overclaiming:

• Iterator helpers let iterator pipelines stay lazy longer before converting to arrays.
• Set methods make membership math like union, intersection, and difference part of the language.
• Temporal gives JavaScript clearer date/time types than legacy Date, with support still needing target checks.
• Signals are already visible in frameworks: Svelte 5 runes, Vue Vapor beta, and Solid all reflect signal-style thinking. Current verified sources pin the TC39 Signals proposal at Stage 1, so do not treat language-level signals as settled JavaScript.
• using and decorators are features you will see in articles, tools, and framework conversations. If your trusted sources do not pin a stage, do not invent one. Check current proposal docs, runtime support, and toolchain support before using them in production JavaScript.

That last point is not timid; it is professional. The problem is rarely "new features are bad." The problem is confusing seen online with safe for this project.

When you see a feature in a tutorial, ask:
 
1. Is this JavaScript, TypeScript, a Babel transform, or framework syntax?
2. If JavaScript, is it already in an ECMAScript edition or still a proposal?
3. Which browsers and server runtimes does this project support?
4. Does the build tool parse it? Does the linter understand it? Does the type checker?
5. Is there a small fallback, polyfill, or progressive-enhancement path?
6. Is the feature clearer than the boring code it replaces?

Try it — build a readiness habit

This playground uses a small compatibility matrix instead of live feature syntax. That is intentional: support varies by runtime, and unsupported syntax would fail before your code can even ask a question. Add another feature row and make the decision rule stricter or looser.

The exact rows will change over time. The habit should not: separate standardization status, runtime support, toolchain support, and project value.

How to evaluate hype

New JavaScript features usually arrive wrapped in strong opinions. That is normal. The healthier move is to translate the opinion into a decision record.

Feature decision record
 
Feature:
What problem it solves:
Status according to TC39 / ECMAScript:
Runtime targets checked:
Tooling checked:
Fallback or polyfill:
Code clarity compared with current approach:
Decision:
Revisit date or trigger:

Most features do not need a full document. But the shape matters. You are looking for evidence, not vibes. A small personal script can use a fresh feature sooner. A library, framework, public course platform, or business-critical app needs a higher bar because its users run different browsers, Node versions, build tools, and assistive setups.

There is also a learning rule: read new-feature articles for awareness, then write production code from verified support. MDN, runtime release notes, compatibility tables, installed tool errors, type definitions, linters, tests, and real builds outrank social-media certainty.

JavaScript will keep moving; that is part of why the language has survived. Your job is not to chase every proposal. Your job is to understand the path from idea to spec to runtime to project, then choose deliberately.

You now have the full Section 26 toolkit: engine internals without folklore, performance measurement without guessing, and language evolution without hype. Next, we move into design patterns: recurring shapes like module, factory, observer, and strategy that help you recognize structure in your own code and in the libraries you use.