Sunday, December 6th, 2009

ES5 is an ECMA standard

Category: JavaScript, Standards

<>p>ES5 is an ECMA standard.

Let’s hear it for forward progress, even though we want so much more for the only viable language to program the Web client to date.

Let’s have a big “Booo” to IBM for being so stuck up that they think their IEEE decimal position is so freaking important that warrants blocking everything (I am so sour from IBM in ECMA and JCP and …..) and Intel for sleeping on the job and “not having enough time to study the intellectual property implications of the standard”.

Can Intel be kicked off? Oh wait, no. It’s ECMA, and all that matter is $ ;)

(sorry for snarky tone, Web developers and the world just deserves a bit more.)

Related Content:

Posted by Dion Almaer at 12:58 am

3.9 rating from 41 votes


Comments feed TrackBack URI

Is there an Obfuscated Blog Post competition that I’m not aware of? You are nominated.

Comment by okonomiyaki3000 — December 6, 2009

Long time reader but I just had to comment that I agree with you on this one. The web deserves better than these corporate pollutions.

Have they ever contribute anything related to ECMAScript/Javascript in real code form besides just writing the standard itself?

Really when you think about Javascript, what is the first company that comes to your mind?
It’s definitely not Adobe/IBM/Intel/M$ … not one bit from any of ‘em.
But why are they the one defining the standards now?

Comment by chakrit — December 6, 2009

For anyone interested: the ES5-spec can be found here:

Comment by edwinm — December 6, 2009

@chakrit == absolutely agree with you.

Comment by kea — December 6, 2009

Although I “understand” the idea of the post –I just started to program an IBM 1600 in the early ’70s–, I would like to have read a more undestandable news.
What has the “IEEE decimal position” to do? –I do know about the existence of different “decimal representations” on IBM/others computers–.
I would like not to have to read all the spec to find that.

(But after almost 15 years of “converting” scientific programs I understand your angry!)

Comment by lmasanti — December 6, 2009

@Imasanti – Basically the IEEE floating point standard used for all JavaScript number representation is not very good for accurate math. IBM has their own decimal representation that they want included in the standard. It was not included in the standard, so IBM rejected the ES5 proposal.
PS – Its ok Dion, I feel your pain

Comment by genericallyloud — December 6, 2009

@chakrit: Adobe actually works a lot with Javascript, just have a look at ActionScript/Flex.

As for IBM, see They also do a lot for Eclipse, the foundation of Aptana.

For Intel I must say I’m also a bit surprised as to why they’re on the committee. It’s completely valid not to have time to research it completely, but then it seems to me you should abstain, instead of vote no (if ECMA allows abstaining, of course).

Note that I don’t fully disagree with you, I just wanted to point this out.

Comment by LudoA — December 6, 2009

@LudoA, this was a vote of the General Assembly, rather the ECMAScript committee. After the committee decides they’re done, it goes to a wider audience for approval.

Comment by joshtynjala — December 6, 2009

@Chakrit the impression I got was that it was largely Douglas Crockford (yahoo), Brenden Eich (inventor of javascript), Waldemar Horwat (Designed later versions of javascript), Allen Wirfs-Brock, Pratap Lakshman (jscript) who wrote the Ecmascript 5 standard. Are they not javascripty enough for you?

Comment by Breton — December 6, 2009

Not to mention that it was largely Douglas Crockford who was responsible for so little being added in this standard. He is not a big corporation, he is well trusted as a javascript guru. Rage against the machine if you like, but I guess it would be good if you did some research first.

Comment by Breton — December 6, 2009

“@Imasanti – Basically the IEEE floating point standard used for all JavaScript number representation is not very good for accurate math. IBM has their own decimal representation that they want included in the standard. It was not included in the standard, so IBM rejected the ES5 proposal.”
IEEE floating point is fine for accurate math, it’s just crap at accurate DECIMAL math, such as is used in accounting programs. getting accurate decimal math in javascript, using a particular (Slow) decimal format is IBM’s only interest in a new ecmascript standard. They spec writers though couldn’t figure out how to put it in without sacrificing the simplicity of the language that has made it so popular. Not in time for this vote anyway. Though they have still promised to try for decimal math in harmony.
And let me just take this opportunity to reiterate that Crockford had some very good reasons for “gimping” this new version of ecmascript. Please see the video linked above, THEN decided if you have any rage against the machine left in you.

Comment by Breton — December 6, 2009

Don’t forget Brendan’s perspective:

Comment by TNO — December 6, 2009

Although I think IBM’s “no” is a bit over-the-top, I can’t wait until decimal comes in. I see people baffled over and over by the numbers they do math in JavaScript (and, to be fair, many other languages).

Comment by Nosredna — December 6, 2009


ActionScript is not ECMAScript. It’s fair to say that it’s a superset of ECMAScript, and influenced heavily by the abandoned ECMAScript 4 standard (which Adobe promoted), but it’s certainly not the same language, and it certainly doesn’t have the same capabilities.

ActionScript 3 adds a stricter type system, packages, classes, and probably a handful of other bits and pieces on top of ECMAScript 3. While standard ECMAScript would likely run just fine as ActionScript (probably with a ton of warnings), a standard ECMAScript (JavaScript) parser would not know what to do with much of what’s in AS3.

I know that the case may be different for AS2 and earlier, but I’m not as familiar so I wouldn’t be able to detail the similarities and differences. That said, it’s clear that Adobe dropped the existing ECMAScript standard, anticipating that it would successfully influence the next iteration of the standard. AS3 remains an odd duck, given how Harmony played out.

Comment by eyelidlessness — December 7, 2009

@Breton – Yes, sorry for the simplification.

Comment by genericallyloud — December 7, 2009

@Dion: back at you. Boo for the snarky tone on a serious issue that has been on the table at ECMA since 1998. We missed a rare opportunity to fix a big problem. 0.1 + 0.2 == 0.3, and if Javascript is to be a serious language and grow beyond the browser to handle things like financial transactions, I’d think the community would want this fixed. Other major languages have done so. IBM simply exercised its vote on an issue it takes very seriously.

Comment by peller — December 8, 2009

@eyelidlessness “a standard ECMAScript (JavaScript) parser would not know what to do with much of what’s in AS3.”

I hope you are aware of the fact that AS3 runs on Mozilla’s Tamarin which is a JIT compiler for ECMA…

Comment by V1 — December 8, 2009

watch Douglas explains why.

Comment by BenGerrissen — December 8, 2009

@BenGerrissen, yes, that’s Doug’s view of things. It is IBM’s position that adding decimal arithmetic is an essential part of ‘repairing the language’. IBM was actually quite flexible on how this was implemented and provided a solution to the committee, both in the form of a specification and a reference implementation. 754r is the standard for Decimal arithmetic, devised by the world’s experts and used in other programming languages. Its seems a bit odd to suggest that TC-39 should invent its own. Should IEEE 754 devise its own scripting language?

Comment by peller — December 8, 2009

I should have provided a link. The concern on the committee was originally that someone had to provide an implementation and address the back-compat issues, and that happened. Nothing was said about the 754 standard until quite recently, AFAIK.

This was ready over a year ago. Not sure why Doug asserts that there wasn’t enough time.

Comment by peller — December 8, 2009


“I hope you are aware of the fact that AS3 runs on Mozilla’s Tamarin which is a JIT compiler for ECMA…”

Right, and we all know Mozilla’s JavaScript engines have never supported anything that was either not-yet a standard (quite like AS3), abandoned in the standards process (again quite like AS3), or simply non-standard. AS3 is *not* Standard ECMA 262, and never was.

Comment by eyelidlessness — December 8, 2009

@Peller, prolly some politics, some reasons that stood out for me was:
- Performance hit (vendors are speeding up JS engines and dont like to implement something that actually slows features down further)
- Backwards compat (or more specific, keeping JS simple)
Dunno if IBM holds a patent on IEEE 754r and would receive cash from vendors when they use 754r, which would be another very damned good reason not to accept 754r imo. Bring on the PNG version of 754r I say. Web is open source and companies that still try to make money from algorithms are dinosaurs that should go extinct.
As for the afore 2 reasons, I would like to know how big that “performance” hit would be and I personally don’t quite agree on the “keeping js” simple road. Sam Ruby’s implementation seems simple enough imo whilst NOT breaking current JS programs.

Comment by BenGerrissen — December 8, 2009

very helpful

Comment by Aphrodisiac — January 15, 2010

Leave a comment

You must be logged in to post a comment.