2026-09-22 — ECMAScript Research Summary

Frontend Analysis (FA) treats ECMAScript as an independent semantic research domain rather than as a JavaScript parser or conventional AST problem.

The current ECMAScript research direction focuses on determining which authored and derived semantic facts must remain observable for reliable frontend analysis.

Primary areas of interest include:

• declarations and bindings
• expression semantics
• static semantics
• Early Errors
• Block and statement behavior
• Automatic Semicolon Insertion
• source correspondence
• authored occurrence ordering
• duplicate contributor preservation
• semantic ownership
• cross-domain interaction with HTML and CSS

A central research concern is the distinction between authored syntax and semantic facts derived from that syntax.

An authored ECMAScript construct may contribute multiple kinds of information, including:

• declared names
• authored source occurrences
• initializer relationships
• declaration propagation
• static semantic conflicts
• contributor order
• downstream semantic facts

These facts do not necessarily require preserving the complete syntax tree that produced them.

Because of this, FA does not assume that a general-purpose ECMAScript AST is sufficient or appropriate as the production representation.

The research instead asks which facts are actually required and how their provenance should be represented.

Current accepted research has progressed through deliberately bounded capabilities including:

• top-level var
• one-level Block-contained var
• 1..N authored declarators
• Block var propagation into Script semantics
• declared-name computation
• source-name correspondence
• decimal integer initializers
• fractional DecimalLiteral forms
• exponent DecimalLiteral forms
• Boolean literals
• null
• this
• direct String literals
• direct IdentifierReference
• escaped non-reserved IdentifierReference
• leading unary +
• leading unary -
• exactly two IdentifierReference contributors in additive expressions
• limited ASI behavior at EOF and Block close

The research has also established that authored contributor order and duplicate occurrences may need to remain observable independently from final semantic sets.

For example, contributor analysis can preserve authored order across both top-level and one-level Block var declarations rather than grouping contributors according to syntactic container.

Expression research follows the same bounded approach.

A capability is not widened into an arbitrary expression representation merely because a larger abstraction appears convenient.

For the currently accepted two-IdentifierReference additive frontier, the bounded contributor representation remains conceptually:

None One(Fact) Two { first, second }

This preserves ordering and duplicate occurrence information while avoiding unsupported generality.

The operator itself is not retained as a semantic contributor for the currently demonstrated consumers, and the additive expression does not require an additional whole-expression anchor in the accepted representation.

These conclusions are treated as evidence-backed research results rather than permanent assumptions.

Future research may falsify them when new consumers or wider expression forms introduce requirements that are not currently observable.

The intended ECMAScript workflow remains falsification-first:

ECMAScript authority → bounded semantic question → independent oracle → positive and negative witnesses → attempted falsification → accepted evidence → production representation → regression coverage → next research frontier

Production implementation is not treated as the source of semantic truth.

Where practical, independent oracles are established before production widening so that expected behavior is derived through a separate path.

Relevant research questions include:

• Which authored occurrence produced a semantic fact?
• Which component owns the fact?
• Does source order matter?
• Do duplicate occurrences matter?
• Does surrounding syntactic context change the result?
• Which static semantics propagate across Block or Script boundaries?
• What information must survive into production representation?
• Which counterexample would invalidate the current model?
• Does a wider abstraction solve a demonstrated problem or merely anticipate one?

Still-open capability frontiers include areas such as:

• three-reference or arbitrary-length additive expressions
• multiplicative expressions
• parenthesized expressions
• member access
• calls
• assignment expressions
• wider statement coverage
• deeper Block nesting
• broader ASI behavior

These are intentionally treated as research frontiers rather than a fixed parser implementation roadmap.

The current objective is therefore not simply to "support JavaScript."

It is to progressively establish small, evidence-backed ECMAScript capabilities whose semantic meaning, ownership, provenance, and limitations remain explicit.

As individual research lineages become large enough, they can be promoted into separate dated research records while this summary remains the domain-level baseline.

#ECMAScript #FrontendAnalysis #JavaScript #StaticAnalysis #Rust #Research