> 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.
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).
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.)
This needn't be the case; it depends on the details and what the particular format is designed for.
Wasm is a good example of a bytecode format designed for small code size. Though I expect wasm may often still be larger than equivalent js just because it's so much lower level. But there's no reason you couldn't design a compact bytecode format with high level semantics, and I would expect it to beat any human readable format.
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.
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.
But this was more a 1:1 representation of the source with generic markers for any arguments and local variables (in functions), as far as I remember. However, there was also an optimization option in the compiler. (But, of course, type hinting instructed the byte code emitted by the compiler.)
Absolutely. AS3 bytecode was heavily inspired from java bytecode. There were a number of asks to get a server version of AS3 but Adobe was too invested in coldfusion to make it happen.
Adobe is a classic example of having too many products that they’d let internal innovation stifle. Can’t blame them but that’s why we needed Flash to be open source. Adobe did a poor job letting it realize it’s true potential.
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.
And yet a good part of ES4 been realistically implemented in ActionScript 3 and used by many developers for over a decade.
And those namespaces in AS3 (much simpler than in ES4) I think are quite a good idea, they allow to control what is visible or not and/or to switch which implementation you use.
For example when some AS3 builtins do not support some methods defined later in ES5.1 then ES6 etc.
ES5 function trim():String
ES6 function repeat(count:Number):String
So yeah you not gonna use namespaces everyday for everything, but they do have allow to solve specific problems while "programming in the large".
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.
> 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.
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.
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.
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.
One of the biggest issues was that stakeholders were uncomfortable with having to ship their browsers with multiple engines to handle different versions of JS (or having to build one engine which could efficiently switch between all the features of different versions).
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)
> 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.
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
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.
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.
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.
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.
> 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.
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."
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/ 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 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”.
> 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.