In the face of discourse, ECMA 4 was abandoned. Now, the ECMAScript 5 working group seems prepared to put forward a less ambitious set of new capabilities as standard. In many cases, these new capabilities are not really new; they are well-worn Ajax design patterns that both presentation-tier developers and browser makers alike have come to support in the last 10 years.
Why was ECMA standards' progress slow and what caused recent momentum for ECMAScript 5? In fact, there was a move by some to find something less robust that could be agreed to.
"There were various proposals – a lot of starts and stops," said Allen Wirfs-Brock, ECMAScript Language Architect, Microsoft, who took part in a panel discussing ECMA 5 at The Ajax Experience conference this week in Boston, Mass.
"We made progress in the last two years because the players in the browser community worked with each other to define common achievable goals," said Wirfs-Brock, who serves as representative for Microsoft on the ECMA TC-39 study group.
This has made it difficult to formally update, suggests Crockford.
"We have been waiting 10 years for this [update]. The more popular something is, the less room you have as a standard maker to fiddle with it," he said, speaking as well at The Ajax Experience conference ECMA 5 panel.
Most agree that backward compatibility is essential in such a widely deployed technology. Key goals for ECMAScript 5, said Crockford, were to ensure "users would use it" and that "it did not break the Web."
Wirfs-Brock and Crockford indicated that the ECMA 5 community was working on conformance tests to help developers looking to work to the new standard, which goes up for vote within the ECMA standards process in December.
"The way we got here was brilliant, but it's too wacky," said Crockford.
Advises Crockford: "If you stay in the fat middle there is a good chance it will run. Things will always be flaky and fragile at the edges. So stay in the middle."