
ECMAScript 4: The Missing Version - juhangsin
https://evertpot.com/ecmascript-4-the-missing-version/
======
zenhack
On this bit:

> Perhaps if ES4 landed, fewer people would need complex build tools like
> Babel, Webpack and Typescript.

I'd pose it the other way: if stuff like Babel existed at the time, folks
might have actually written es4 because they could do so without breaking
backwards compatibility. And most of the value in a static type system is the
ability to flag errors before running the program, so I don't think there's
anything you can add to the browser that would have obviated an offline tool
for that.

Frankly, I think we'd be better off if we started getting a lot more selective
about what gets added to browsers. Adding more and more features to browser's
js implementations is silly when most folks are using ahead of time build
steps to get access to those features without the browser's help. And
continuing to add things is a great way to ensure that they'll keep right on
using those tools, so they don't have to worry (as much) about who supports
what. And it just makes the barrier of entry for building browsers higher and
higher.

There's more utility when native browser support can do something a compiler
can't. Things like reducing code size for really widely used functionality,
enabling technologies that can't be bootsraped through developer tools (e.g.
WebRTC). I'd like to see additional growth of the web platform be focused on
areas that can't adequately be addressed by separate tools.

~~~
masswerk
Mind that features like type hinting in ES4 / AS3 were more about execution
speed than about IDE-like error checking. There were times when AS3 was faster
than any native browser JS, exactly because of this (and due to faster object
lookup, as well).

~~~
zenhack
Ultimately though this end probably would have been better served by bytecode.

~~~
masswerk
Mind that byte code is generally much larger than source code.

(This is also, why scripting languages were prevalent server-side with slow
hard disks: loading and compiling a Perl script was faster than loading a
massive binary. See also the 2MB Java Hello-World.)

~~~
JoeAltmaier
Which highlights why bytecode is such a bad idea. It isn't a sort of assembly
language, its much dumber, more like a pocket calculator language. It actually
loses semantic information. It has to be re-compiled like the source code but
with most of the useful source clues lost.

A far, far better choice would have been some orderly structuring of the
semantics of parsed and interpreted code. What the compiler has internally
after digesting the source, but before generating code. Choose some schema and
emit json or something. That would have been a game-changing choice some
decades ago. But no we got saddled with byte-code and a billion dollars has
been spent mitigating that disaster.

~~~
teddyh
> _What the compiler has internally after digesting the source, but before
> generating code. Choose some schema and emit json or something._

You mean the parsed Abstract Syntax Tree; AST.

The next step would obviously be that people choose to start programming
_directly_ in the AST form. And now you have created Lisp.

~~~
JoeAltmaier
Denied. The next step is not pretending everybody wants to be a compiler
internals expert. Programming languages are two or three orders closer to
human understanding.

------
dherman
I remember sitting outside a Mountain View Starbuck's with Lars Hansen, then
at Opera, and Brendan Eich, then at Mozilla, and listening to Lars explain
that he'd lost faith that ES4 was realistically implementable. I think that
was the day I knew it was dead.

I spent years working on ES4 and I'm not sorry it failed (namespaces in
particular were just a disastrously bad idea). The whole affair was a
formative experience for me.

~~~
mycall
How did namespaces in ES4 differ from namespaces in Java?

~~~
zwetan
In Java you would use packages to group together class definitions

same as with C++, C# where you would use namespaces to do that

aka define the scope of classes

in AS3, the packages are used the same, group collection of definitions, not
only classes and interfaces but also variables, constants.

The namespaces in AS3 are used to define the visibility of definitions at the
class level, a bit like being able to define your own "public" attribute.

In ActionScript 3, by default the AS3 namespace is open, for example with a
builtin like Array instead of using the push() method defined in the
prototype, it uses the push() method defined in the AS3 namespace.

See
[https://github.com/adobe/avmplus/blob/master/core/Array.as#L...](https://github.com/adobe/avmplus/blob/master/core/Array.as#L187)

But you also have mode to compile with -ES to not open that AS3 namespace by
default.

In ES4, namespaces could do more advanced stuff like namespace shadowing (only
a proposal at the time), see
[https://web.archive.org/web/20070629024201/http://developer....](https://web.archive.org/web/20070629024201/http://developer.mozilla.org/es4/spec/chapter_12_namespaces.html)

For AS3, see 1.9 Namespaces / 12 Namespaces / etc.
[https://github.com/as3lang/ActionScript3/wiki/Specification](https://github.com/as3lang/ActionScript3/wiki/Specification)

------
drawkbox
> _In 2008 the standard was pronounced dead, and ES3.1 was renamed to ES5,
> which was a much more conservative and incremental update to ECMAScript._

> _The closest thing we had for ES4, was probably Flash Actionscript 3. There
> was a point during the release of AS3 that some of us thought that Flash and
> the Web was eventually going to converge._

> _For more details on politics and history of ES4, check out this great
> article on the auth0 blog [1]._

ECMAScript 4 was actually quite nice, Typescript like but ActionScript3 (AS3)
was a great implementation of it. The classes, events, types (was also
dynamic) and more were just so right.

I used a ton of AS3 in Flash games, Flex and that moment _just before_ mobile
took over the world in 2008. From 2005-2008 Flash vs Silverlight was a massive
thing and Flash video had revolutionized the world earlier with Youtube and
others. Macromedia was a great company and I wish that Microsoft had bought
them (they owned part) instead of Adobe.

The big problem I think was that ultimately it was Macromedia that really
started the movement and then Adobe bought them and was really pushing the
charge with AS3/ES4 and it went right at the other tech companies platforms.
Flex before apps was really webapps done right for a time.

Silverlight was ES3 and Google had lots invested in Javascript with
Maps/Gmail/Docs/etc. Microsoft and Google did not like that Adobe was leading
it as they ran both big browsers at the time in IE/Chrome and killed off ES4
to go to the ES5 on path. Apple ninja'd in with apps in 2008 and one upped
them all with WebGL, Canvas for a plugin free web (Flash/Silverlight EOL'd
without notice) and OpenGL ES, Obj-C/C++ for app/handheld games. Apple and
apps signaled a move away from the plugin web to standards web and native apps
for better or worse with gave platform owners in appstores/browser more
control of what technology is used.

It is too bad, I think javascript would look more like TypeScript and be less
of a mess today, this is coming from someone that loves javascript since the
late 90s.

Side note: I love all of Anders Hejlsberg language/platform design in Turbo
Pascal, Delphi, C# and TypeScript and Danish by ancestors so maybe I am
biased. ActionScript 3 based on ES4 was along those lines of _just right_ to
me, the best format/language doesn't always win, the platform owners dictate
technology history.

[1] [https://auth0.com/blog/the-real-story-behind-
es4/](https://auth0.com/blog/the-real-story-behind-es4/)

~~~
didibus
ActionScript 3 was a great language. Would have been nice to have it native
in-browser.

I also have to agree with Anders Hejlsberg, he has great intuition for what
makes a well balanced well rounded language.

------
Etheryte
This is perhaps a good example of how sometimes you can't force the hand of
progress, it simply takes some time. So many ideas that were novel additions
to Javascript at the time but are standard practice in one form or another
today. The touted reason for its failure was lack of backwards compatibility,
but I can't help but wonder how much of it was simply browser wars and
different factions refusing to cooperate. In 2008, Internet Explorer still
held majority of the web, Firefox was a big player and Chrome had just barely
entered the scene.

~~~
whatatita
I also wonder that. IE is famously non-compliant when it comes to web
standards and they were a big player back then.

Chrome gained a lot of it's early traction by being quick to adopt new
technologies.

I wonder if it was also to do with the dramatic increate in the size of the
spec. ES4 would have added so many more concepts I can't help but think
thebrowsers would have nather not gone to all the effort.

~~~
goatlover
It's safe to guess that if Netscape had won in the 90s, JS and the browser
would have progressed much farther in the 2000s. Microsoft was in it to stop
the browser being used as a platform that threatened their monopoly. Once
everyone was using IE, they had little incentive need to improve it.

------
olliej
ES4 had a bunch if problems.

It didn’t address major language problems - the lack of unambiguous
specification for the existing “specified” language, it failed to document the
existing shipping language features that weren’t in the es3 spec. Basically it
left a whole bunch of the spec ambiguous with differing engine behaviours.

On top of that, the spec was _massive_ , included a lot of kitchen sink style
accumulation of language features - I can’t recall which feature it was, but I
do remember when some language showed a new feature it was almost immediately
shoehorned into ES4.

And while a lot of the work was on static typing, more time was consumed by
academic features of little real world value - object capabilities were a huge
drain on committee time and complexity of many features.

The end result was that ES4 as a spec was far too large to implement, didn’t
solve The very obvious major problems with the existing spec, and didn’t
actually provide much in the way of features that people were asking for.

Incidentally the reason we have for(of) in javascript is because that would be
ambiguous with the type syntax designed in ES4. The reason I couldn’t use for
each was because of the other spec this article talks about: E4X.

Both of these were language specifications pushed by Mozilla and a few
academic PLT folk with little-to-no interest in other implementer feedback.

At this point even ECMA has retired E4X (it’s been withdrawn, or whatever
language ECMA uses for a spec that no longer exists)

~~~
gsnedders
> On top of that, the spec was massive, included a lot of kitchen sink style
> accumulation of language features - I can’t recall which feature it was, but
> I do remember when some language showed a new feature it was almost
> immediately shoehorned into ES4.

And in very many cases, too much was added too fast: the spec was _miles_
ahead of any implementation. You really don't want the spec getting too far
ahead, as so many issues only become obvious during implementation, and you
don't want to be building indefinitely on top of that potentially unsound
base.

------
snek
There is a lot of excellent information on ES4 (and other things) in Allen
Wirfs-Brock's "JavaScript: The First 20 Years":
[https://zenodo.org/record/3707008](https://zenodo.org/record/3707008)

~~~
treve
Sounds interesting, but sadly a dead link =(

~~~
fanf2
The announcement blog post is at [http://www.wirfs-
brock.com/allen/posts/866](http://www.wirfs-brock.com/allen/posts/866) but
sadly the wayback machine doesn’t have a copy of the pdf

~~~
zwetan
You can find a copy of the PDF here

[https://discuss.as3lang.org/t/javascript-the-
first-20-years/...](https://discuss.as3lang.org/t/javascript-the-
first-20-years/2309)

------
pier25
I wrote _a lot_ of ES4 back in the day, or rather AS3. It was my main
programming language from around 2007 to 2014. It was a nice mix between ES6
and TypeScript.

------
dandare
I remember hearing rumors back in the day that MS dragged its leg with ES4
because they didn't want the browser to be powerful enough runtime to compete
with Windows. Mind you that Flesh with AS3+E4X aka Flex was powerful enough to
run spreadsheet or text processor in the browser - long before Google
Spreadsheet or anything similar was possible with ES5.

~~~
Marazan
Everyone who wasn't Adobe realise that standardising on a new version of
Javascript that Adobe already had a runtime and tooling for thus having the
defacto implementation of would put themselves and a massive competitive
disadvantage.

------
fiddlerwoaroof
Does anyone know where one might find the reference implementation of
ECMAScript 4? It’s linked here[1] and you can find a form to fill out and
download it via archive.org[2], but because it was behind a form, archive.org
doesn’t have the actual file.

[1]: [https://brendaneich.com/2007/06/ecmascript-
edition-4-referen...](https://brendaneich.com/2007/06/ecmascript-
edition-4-reference-implementation/)

[2]:
[http://web.archive.org/web/20090721022046/http://www.ecmascr...](http://web.archive.org/web/20090721022046/http://www.ecmascript.org/download.php)

~~~
snek
[https://github.com/dherman/es4](https://github.com/dherman/es4)

------
montroser
Another interesting proposal for ES4 was a Python-inspired array slice syntax.

I would quite to have seen this feature adopted, and am glad to see it looks
like there is once again a proposal under consideration:
[https://github.com/tc39/proposal-slice-
notation/blob/master/...](https://github.com/tc39/proposal-slice-
notation/blob/master/README.md)

------
jisaacks
I covered ES4 in my book, Get Programming with JavaScript Next. ActionScript 3
was basically a real world implementation of ES4.

------
Roboprog
I’m so glad ES4 never happened. Bullet dodged. Nice to see that sometimes, at
least, the industry avoids needless suffering.

But I like that JS can be a primarily functional, rather than primarily object
oriented, language.

~~~
throw_m239339
> I’m so glad ES4 never happened. Bullet dodged. Nice to see that sometimes,
> at least, the industry avoids needless suffering.

You're so glad now most shops use Microsoft Typescript when there could have
been an open standard and implementation in all browsers 13 years ago? Because
JS still ended up having classes, and no, they are not "just functions" since
you need to call them with the new operator or it yields an error. Ultimately
we've got the worst of both worlds, with Microsoft typical EEE cherry on the
top.

I'm not glad we wasted all these years because of petty political infightings
at ECMA.

------
pavlov
JavaScript, the Leisure Suit Larry of programming languages.

~~~
pavlov
I feel I should explain this lackluster joke. It's not a comment on the
quality of the language, but rather on how the Leisure Suit Larry game series
skipped episode 4 completely, and the in-universe explanation was that there
was a lost game called "Larry 4: The Missing Floppies."

------
foobar_
This could easily be a nice compiler project. The like operator is quite
interesting along with generic functions.

------
lstamour
The explanation I heard was that E4X died at the time because (a) JSON
developed by the early/mid 2000s to compete with XML and (b) XHTML would so
easily break in strict browsers that the web was pushed in the direction of
HTML5 instead of XHTML. In short, there was a rather large backlash against
“enterprise” technologies like XML, WS-* and Flash (in some circles) in favour
of HTML Microformats, REST and JSON. This is roughly around the same time when
AJAX moved from shipping XML (2003-4) to shipping bits of HTML (PJAX) or using
JSON APIs via AJAX or JSONP. The thinking of the day was if XHTML 2.0 was dead
on arrival, then we should probably back out the E4X changes as “from another
era.” CORS is a great example, the original CORS was “Authorizing Read Access
to XML Content Using the <?access-control?> Processing Instruction 1.0” from
2005: [https://www.w3.org/TR/2005/NOTE-access-
control-20050613/](https://www.w3.org/TR/2005/NOTE-access-control-20050613/)
which in 2007 became a header, then several headers, then the CORS specs we’re
a bit more familiar with by 2009 as Chrome was introduced.

Worth noting that compiling new syntax to old is also not new — anybody
remember CoffeeScript? I’d say if there’s a new part, it’s the prevalence of
implementations of standards and of polyfills for them in both TypeScript and
core-js via Babel such that you can confidently write code in new syntax
knowing you wouldn’t have to rewrite it later. Nobody remembers CoffeeScript
or sees it today because it was generally all converted to JS long ago — it
wasn’t a syntax we could build on top of. Arguably, if it was, you’d still see
projects using it today, but it’s hard to modify syntax in an unambiguous way
(for parsers I mean) while also simplifying the syntax as CoffeeScript did.
Implementing standards are safer, though until implemented and shipped in
multiple browsers, anything could still change. There are a few places where
TypeScript has to be changed or will be changed due to changes in the JS
standard...

To illustrate how messed up standards can still be though, I’d present
“decorators” —- seemingly a solved problem in Babel or TS but apparently very
hard to implement as a standard: [https://github.com/tc39/proposal-
decorators](https://github.com/tc39/proposal-decorators) I’m beginning to
think JSX will ship in browsers before decorators do ;-)

That said if there’s something the web community learned from ECMAScript 4 and
XHTML2 it’s that usage, what people want to use and working code, always wins
out over arbitrary standards. If two options are good enough, the one folks
implement and use will win when it comes to standards. To this end, I’m pretty
sure future standards required 2 independent implementations to actually
graduate and become standards instead of remaining proposals. Not sure how
that will change if Chrome ever becomes a larger monoculture than it already
is... maybe web developers will have to vote with their codebases as standards
bodies write and distribute polyfills to encourage their spec to “win”.

~~~
mycall
> maybe web developers will have to vote with their codebases as standards
> bodies write and distribute polyfills to encourage their spec to “win”

I think WASM gives some real possibilities here. I'm not sure how polyfiling
WASM will look like.

------
zwetan
> The closest thing we had for ES4, was probably Flash Actionscript 3.

No.

Flash = a browser plugin

ActionScript 3 = a programming language

ActionScript 3 can run in other runtimes than just Flash

Adobe AIR is another runtime, target desktop (Windows, macOS) and mobile (iOS,
Android).

Redtamarin is yet another runtime (based on the avmplus) target the command-
line and server-side (Windows, macOS, Linux).

