为什么 ECMAScript 第四版被彻底废弃？
我一直在寻找一些有关废弃的 ECMAScript 第 4 版的信息，但没有取得多大成功，即使在 SO 上也是如此。我知道 Mozilla 的 JavaScript 1.7 实现了第四版中提供的许多（全部？）新功能，我想我记得 John Resig 的一篇关于它的好文章，但我现在似乎无法在他的博客上找到它。
特别是，我想知道为什么它被完全废弃，取而代之的是 ECMA-262 第五版，以及为什么它不只是得到改进。有些功能非常酷，比如生成器、迭代器、let、新的赋值运算符和（我特别喜欢的）解构赋值。
我知道所有这些特定功能只会在具有过时 ECMAScript 实现的浏览器中引发错误，但既然知道有一天这些实现会变得很少而且相隔很远，为什么不包含它们呢？还有其他原因吗？我们是否可能会看到一些被废弃的功能在未来的版本中重新出现，或者供应商是否非常害怕破坏兼容性，以至于我们可能永远不会看到对标准的此类改进？
顺便说一句，很高兴知道有关此事的一些意见，您是否对第五版中删除的某些功能感到恼火，或者您认为这样更好吗？ ECMAScript 4 的实现值得尝试吗？
I've been looking for some information regarding the scrapped ECMAScript 4th Edition without much success, even on SO. I know Mozilla's JavaScript 1.7 implemented many (all?) of the new features offered in 4th Edition and I thought I remembered a good John Resig post on it but I can't seem to find it on his blog now.
In particularly, I want to know why it was completely scrapped in favour of ECMA-262 5th Edition and why it wasn't just improved upon. Some of the features are pretty cool, like generators, iterators, let, new assignment operators and (my particular favourite) destructuring assignment.
I know all of those particular features would just throw errors in browsers with out-of-date ECMAScript implementations, but why not include them anyway with the knowlege that one day those implementations would be few and far between? Were there other reasons too? Are we likely to see some of the scrapped features reappear in a future release, or are vendors so scared of breaking compatibility that we will probably never see such improvements to the standard?
As an aside, it would be nice to know some opinions on the matter, are you annoyed to see some features cut from the 5th Edition or do you think it's better this way? Is it worth playing around with implementations of ECMAScript 4?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
简而言之，没有 ECMAScript 第四版。来自第五版规范：
基本上，关于如何推动 JavaScript 向前发展有很多非常强烈的观点，其中许多观点是不兼容的，其中一些观点在事情分崩离析之前大部分已经被整合到了一些人认为的第四版中（尤其是因为缺乏一些重要实施者的支持）。与此同时，该标准的新版本已经非常非常迟来了，因此经过大量的预先谈判，各方于 2008 年 7 月在奥斯陆齐聚并商定了前进的方向（Brendan Eich [JavaScript 的发明者] 后来将这种方法称为“ “和谐”在编写时）。
Harmony 推迟了一些事情，永远把一些事情完全排除在外（命名空间、包、早期绑定），而且——重要的是——允许委员会推进自 1999 年以来的第一次规范更新：第五版。
Simply put, there was no ECMAScript 4th Edition. From the 5th edition specification:
Basically, there were a lot of very strong opinions about how to move JavaScript forward, many of which were incompatible, some of which had mostly been assembled into what some thought would be the 4th edition before things fell apart (not least because of lack of support from some important implementors). Meanwhile, a new edition of the standard was very, very overdue, and so after a lot of advance negotiation, the various parties got together in Oslo in July 2008 and agreed a way forward (Brendan Eich [inventor of JavaScript] later termed that approach "Harmony" when writing it up).
Harmony deferred some things, put some things completely off the table forever (namespaces, packages, early binding), and — importantly — allowed the committee to move forward with the first specification update since 1999: The 5th edition.
如果您有 55 分钟的空闲时间来了解该主题，请观看视频 Douglas Crockford：“ECMAScript 的现状和未来” 或 转录。
If you have a spare 55 minutes for the subject, see the video Douglas Crockford: “The State and Future of ECMAScript” or the transcript.
基本上它正在成为一个厨房水槽，有太多的功能需要实现。
Basically it was becoming a kitchen sink with too many features to be implemented.
在Coders At Work的采访中对此进行了一些讨论，其中两位受访者处于相反的立场这个问题。
这似乎归结为 v4 工作人员和社区其他一些受人尊敬的成员之间对于语言应包含哪些内容存在根本分歧。
（顺便说一句，我强烈推荐这本书）
There was some discussion of the in the interviews of Coders At Work, two of the interviewees were on opposite sides of this issue.
It appears to have come down to fundamental disagreement about what the language should contain between those working on v4 and some other well respected members of the community.
(I highly recommend this book by the way)