For years, I wanted a clear way to classify TC39 proposals.

Official records track the stage number (0 to 4), proposal name, authors, and champions. That shows where a feature sits in the committee pipeline, without answering how it actually behaves in production:

• Is it something you can polyfill in userland, or does it require native engine changes?
• How much mental overhead does it add for a developer learning it?
• Does it risk breaking existing sites by colliding with old global polyfills (like the Array.prototype.flatten MooTools collision)?
• What was the actual reason someone proposed it in the first place?

Reading and tagging 324 proposals by hand across five technical dimensions and seven intent categories was a spreadsheet project I kept putting off.

I ended up writing a small script to evaluate them using TypeSafe’s Jev model (jev-latest). Jev answers structured schema questions, returning choice selections, numeric score ranges, and calibrated probabilities instead of unstructured text.

const response = await fetch("https://api.typesafe.ai/v1/systemone", {
  method: "POST",
  headers: {
    Authorization: `Bearer ${apiKey}`,
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    model: "jev-latest",
    state: { name, description, stage, tags, authors },
    questions: {
      domain: { type: "choice", criteria: DOMAINS },
      disruption: { type: "score", criteria: DISRUPTION_SCALE },
      adoption: { type: "choice", criteria: ADOPTION_PATHS },
      cognitiveOverhead: { type: "score", criteria: OVERHEAD_SCALE },
      webCompatRisk: { type: "score", criteria: COMPAT_SCALE },
      intent: { type: "choice", criteria: INTENT_ARCHETYPES },
      isSandboxingSecurity: { type: "noul" },
      requiresTypeScriptChanges: { type: "noul" },
      affectsMemoryModel: { type: "noul" },
    },
  }),
});

The schema evaluates each proposal across 9 technical dimensions:

1. Core domain: where the feature lives in the platform (Syntax & Grammar, Standard Library, Concurrency, Metaprogramming, Types, Sandboxing, Memory).
2. Ecosystem disruption: scored 1 to 5 from additive and invisible to severe ecosystem breakage.
3. Primary adoption path: how developers consume it (transpilation, runtime polyfill, native engine only, or toolchain/types only).
4. Cognitive overhead: scored 1 to 5 from zero mental load to a full paradigm shift.
5. Web-compatibility risk: scored 1 to 5 from zero risk to hazardous web invariant collisions (like MooTools flatten).
6. Intent archetype: why the author proposed it (reducing boilerplate, adding expressive power, engine optimization, paradigm bridge, security hardening, spec housekeeping, or legacy bug repair).
7. Realm sandboxing: calibrated probability that the proposal establishes defensive boundaries or isolates prototypes.
8. TypeScript impact: calibrated probability that the proposal requires modifications to TypeScript’s compiler or checker.
9. Memory model: calibrated probability that the proposal alters buffers, allocation, or low-level runtime storage.

Running 4 concurrent worker streams over the entire archive:

• Total Proposals: 324
• Total Wall-Clock Time: 12.7 seconds
• Throughput: ~25.5 proposals / second
• Total Judgments Evaluated: 2,916 typed vectors (9 per proposal)
• Failures / Retries: 0

A few patterns stand out in the aggregated data:

Security and sandboxing proposals hit a wall. Nineteen proposals focused on prototype freezing, defensive sandboxing, or realm isolation (ShadowRealm, SES, freezing prototypes). Zero of them have reached Stage 4. Locking down dynamic prototypes in JavaScript almost always collides with assumptions in older web code.

Ergonomics accounts for most of the committee’s work. 143 proposals (44.1% of the archive) focus on reducing boilerplate and enabling chaining, including the pipeline operator, pattern matching, and optional chaining.

Proposals that port established ideas from languages like Rust, Python, or C# (such as BigInt or Temporal) reached Stage 4 at more than double the rate of novel ideas. Their mathematical edge cases and operational rules were already established elsewhere.

I built a small interface to browse and filter the full dataset:

• Live explorer: h3manth.com/fun/tc39-atlas/
• Repository: github.com/hemanth/tc39-atlas