ECMAScript 4 dynamics

Research
1

Some say that TypeScript catches on ECMAScript 4 and goes much beyond in complexity, however both have diverging semantics. Some will just say that TypeScript just works, but, for different programming models other than reactive ones (React), it doesn't feel elegant.

ES4:

  • Uses nominal types by default (rather than structural)
  • Performs name lookup differently (three dimensional and possibly defers in verification)
  • Declares classes in arbitrary order; the extends clause could refer to something defined later.
  • May be comparable to Java.

ActionScript 3 implemented much of ES4, but not everything, which sufficed for, for example, the MXML compiler.

One reason to not use Java is that its fashion is just very different from ECMAScript and the existing Maven ecosystem isn't familiar for, for example, modern programmers using, for example, Rust.

ES4 could for example exist for the W3 and Node technologies.

  • The ES4 W3 version would compile ES, MXML, and CSS3 (as part of MXML declarations) into a format suitable for evaluation in web browsers.
  • The ES4 Node version would compile ES into a format suitable for evaluation in Node.js®.

Website building capabilities are left unexplained, but would mix W3 and Node.

As to MXML, if you're not familiar:

  • MXML is a file format for describing UI components using an eXtensible Markup Language. If you've already worked with .NET Razor, something may smell familiar.
  • The W3 MXML semantics would be specific to browser APIs.

These are ideas. Moreover:

  • The mentioned CSS3 wouldn't be the same as CSS3, but a dialect based on Apache Flex's CSS3, which doesn't include variables, but includes specific CSS functions such as Embed(...), PropertyReference(...), and ClassReference(...), and namespace prefixes, among others.

as3_parser for the Rust language parses the above file formats (MXML, and CSS3); however it parses ActionScript 3 instead of the proposed ECMAScript 4 in paper: we're probably not interested in certain features of ES4 such as unit pragmas and unions (given that ES4 isn't very "type inference" based unlike TypeScript, unions are not very effective).

Swiss army knife

It's exciting when there are no dependencies in a project for linting or compiling the source tree, for example. The new Bun toolkit really helps in that, but unfortunately, Bun functions for TypeScript and React.

Rust

Any technology solution is only satisfying when the Rust-Cargo experience is there:

  • A global API host service
  • Markdown API

As far as I know, only Rust-Cargo exists exactly; I'm not aware of any technology that is as ready as Rust-Cargo are for package management.

And about Rust, the reason for not using it as well instead of ECMAScript Harmony, is that it's worse than Java for common programming: compile times, and it doesn't offer the same experience (inheritance; rather, it's stuck to React using a lot of type inference).

Final words

There are APIs in play and additional file formats that must be supported other than just ES4 for a proper compiler series. The ES4 language functions in a different way from TypeScript.

In the ES4 world, reactivity just wasn't a thing; people mixed display lists, event based models, and intermediate manipulations, and type inference wasn't much in play (things weren't exact as they are today in TypeScript and there was a lot of covariance, fixtures and dynamics in play).

Some people argue that ES4 was more for programming games rather than business applications and processes.

I'd like to enforce that these are just abstract opinions and ideas.

2

I'm sorry, but I cannot tell, from any of this post, what your point might possibly be.

3

This is a research?

4

What are you researching?

ES4 is long dead.