原文地址：http://yuiblog.com/blog/2008/08/14/premature-standardization/
The web is made of open standards. This was a significant factor in the web’s displacement of proprietary application platforms. Openness is hugely attractive, so much so that the web dominates over competitors with better technologies. The difficult tradeoff that comes with a standards-based approach is that it is difficult to innovate. As a result, the basic technologIEs of the browser have been stalled for a decade. What innovation we’ve enjoyed, such as the AJax revolution, has come by mining all of the latent, accidental potential of the existing standards. That potential has been used up.
互聯網是由開放的標准組成的。這對互聯網代替私有的應用平台是一個重要的因素。開放是非常有吸引力的，也正因為如此互聯網憑借更好的技術控制著其他的競爭對手。然而當基於標准的方法來臨時，無疑創新會變得越來越困難。結果是，浏覽器最基本的技術停滯發展了一段很長的時間。一些讓我們欣喜的創新，如AJax革命等，是一種在現有標准上的再發掘的潛能。然而這種潛能已經幾近枯竭。
If we are to go forward, we must repair the standards. This is something that must be done with great care. A revision to a standard is an act of violence, just like any surgical procedure. It should only be undertaken when the likely benefit far exceeds the cost and the pain and the risk. The web is particularly troublesome because it did not anticipate the management of software updates, which is why IE5, an ancIEnt browser, still has more users than Safari and Opera combined. Changes to the standard can put developers in a very difficult position because the benefits to users of some browsers become the seeds of failure for the users of others. Developers must manage this gulf, and it is not easy. Developers are not well served by new standards that make their jobs even harder.
如果我們想繼續往前走更遠，我們必須修正標准。這是一項必須非常小心的事情。標准的修訂是一種暴力行為，如同外科手術一樣。只有在標准帶來的好處遠遠高於它本身的耗費及缺點時，標准才能真正被使用。互聯網並沒有預先的軟件升級管理，這使得它成為了一個非常復雜的環境，就比如IE5，一個非常非常古老的浏覽器，其用戶份額卻比Safari和Opera加起來還要更多。正因為如此，標准的改變將使開發者陷入一個非常困難的環境，很多對於某些浏覽器的優點卻可能變成其他浏覽器潛在的錯誤。開發者必須管理並減小這些差別，但這卻是不容易的。同時，開發者未能更好的適應使用新標准也增加了他們工作的難度。
I think it is instructive to look at two approaches to managing innovation within a standards based system, one that I vIEw as a success, and the other not so much. JavaScript was a promising but half-baked language that was irresponsibly rushed to market and then irresponsibly cast into a standard. That standard is called ECMAScript to avoid a trademark dispute. That standard was last revised in 1999.
我覺得，把基於標准的系統和並不十分標准的系統放在一起比較並產生革新是非常有益的。JavaScript是一個非常有希望的語言，但它的自身也非常不成熟，它被過快的不負責任地扔入了浏覽器市場，又被不負責任地扔入了標准的圈子裡。為了避免潛在的版權糾紛，這項標准被稱為ECMAScript。它最後更新的時間是1999年。
It is clear that the language needs to be updated, but TC39 (the committee that is responsible for drafting a new standard) could not reach consensus on how to do it, so it split into two groups, each producing its own proposal. This was a good thing in that competition is healthy, and I belIEve that competition inspired improvements to both proposals. This was also a bad thing because no standards organization can adopt two proposal for the same standard. Without consensus, both proposals must fail.
非常顯而易見的，這門語言需要更新升級了。但是TC39在如何更新的問題上，卻不能達到一致。所以他們分成了兩個小組，分別實現各自的目標。這樣的健康的競爭是非常有幫助的，我也相信競爭會改善兩組各自的目標。 但是，這也是個不好的事情，因為沒有一個標准組織會接受一項標准擁有兩個不同的提議。如果不能達成一致，這兩個提議都將會失敗。
On one side there was the proposal called ES4. It was unfortunate that it adopted that name because it strongly suggested that it was destined to be the Fourth Edition of ECMAScript, a fate that was not certain. The project was very open to new ideas and features, adopting a porkbarrel attitude that was almost Congressional in its expansiveness. Lots of good ideas were included without an adequate analysis of the language as a whole system. As a result, many overlapping features were adopted which would have significantly increased the complexity of the language.
其中一項提議被稱為ES4。這個名稱的使用很不幸運，因為它強烈的暗示了它一定會是ECMAScript的第四版，然而它並不一定會是。該項目對於新思想新特征非常的開放，並采納了許多看法，盡管這些思想並沒有基於這門語言系統進行充分的分析。結果，許多復雜的特征被采用，並最終提升了整個語言的復雜性。
ES4 was so large and so innovative that there were doubts about whether it could be successfully specified and implemented. More worrisome, there was no experIEnce with the language itself. Would the interaction of features cause unintended problems as we saw in ES1 and ES3? The schedule for ES4 required that the standard be put in place and adopted by the browser makers before that question could be answered. This is a problem because once a bug is inserted into a standard, it can be extremely difficult to remove it. All of the features, considered individually, were attractive. But taken as a whole, the language was a mess.
ES4非常的龐大，也引入了許多新思想，這不禁令人們擔心它會不會被成功的接受和使用。更令人不安的是，對於語言的本身，並沒有任何使用經驗。那些極富吸引力的新特性會不會如ES1和ES3一樣產生許多潛在的問題？ES4的制定安排要求這項標准必須被浏覽器開發者接受並植入浏覽器後才能回答剛才的問題。這會是一個很大的問題，當一個小bug錯誤的加入了標准，到時候想要去除掉它就會非常的困難了。單獨考慮ES4所有的新特性，都是非常有吸引力的。但是全部放到一起，語言非常的混亂。
On the other side was a proposal called ES3.1. Its name indicated a less ambitious proposal, being a smaller increment over the current Third Edition. This project was intended to repair as many of the problems with the language as possible while minimizing the pain of disruption. New syntax was considered only when it was already implemented and proven in at least three of the four major browsers. Feature selection tended to favor necessary improvements over desirable improvements.
另一項提議被稱為ES3.1。它的名字暗示它相比於現在的ES3只有較少的變革。這個項目的目標是修復語言中存在的諸多錯誤。新的句法只有在至少三至四個主流浏覽器植入並測試過之後才會被考慮加入。他們更多的選擇必須的特性，而不是可擁有的特性。
ES3.1 was more minimal in approach. The set of feature interactions was much smaller and much easIEr to reason about. ES3.1 is likely to complete its specification and will be the candidate for the Fourth Edition.
ES3.1更容易接受。新特性的吸引力會較小，但是也更容易實現。ES3.1也可能完成它的文檔，從而成為ES真正第四版的候選。
ES4 had a large head start (by as much as seven years by some estimates), but was unable to meet its deadlines. Ultimately, the project fell apart when some of the key members left.
ES4的制定起步很早（估計至少7年之前），然而我們看不到它到底什麼時候能結束。最終，由於核心成員的離去，這項工程被擱淺。
Some of the features that were in ES4 were reasonable, so a new project, called Harmony, is starting which will look at adapting the best of ES4 on top of ES3.1. The success of this project will depend on the ability of TC39 to do a better job of managing the tradeoffs between innovation and stability, and adopting a discipline for managing complexity. Simplicity should be highly valued in a standard. Simplicity cannot be added. Instead, complexity must be removed.
現在，由ES4引入的一些合理的新特性，重新成為了一項新項目，被稱為Harmony。這個項目的成功與否取決於TC39權衡創新與穩定二者的能力，以及對復雜度的管理上。在某種程度上，簡約應受到足夠的重視，而不應被矯飾。所以，一些冗余必須被剔除。
It turns out that standard bodies are not good places to innovate. That’s what laboratories and startups are for. Standards must be drafted by consensus. Standards must be free of controversy. If a feature is too murky to produce a consensus, then it should not be a candidate for standardization. It is for a good reason that “design by committee” is a pejorative. Standards bodIEs should not be in the business of design. They should stick to careful specification, which is important and difficult work.
現在看來標准的主體並不是一個創新的好地方。這也正是實驗室存在的目的。標准必須經過一致的協商，也必須有充分的辯論。如果一個特性很難達成一致，那麼它應 該從標准草案中去除。標准的主體不能在有商業目的的情況下設計。它們必須堅持謹慎的設計，這同時是一個相當困難的工作。
I see similar storIEs in Html5. The early work of WHATWG in documenting the undocumented behavior of HTML was brilliant. It went off the rails when people started to just make new stuff up. There is way too much controversy in Html5. I would like to see a complete reset with a stronger set of design rules. Things can be much worse than the way things currently are. Having smart people with good intentions is necessary but not sufficIEnt for making good standards.
我也在Html5裡面看見了很類似的情況。WHATWG的早期對於文檔化HTML中沒有文檔的特性的工作是非常棒的。然而當人們開始只關注創造新東西時，它們開始偏離軌道。在Html5中存在太多的爭議。事情可能會比現在存在的更糟糕。也許，讓一些有目的的聰明人制定好的標准是必須卻又不夠的。
延伸閱讀：
http://almaer.com/blog/Javascript-2-a-perl-6-disaster-that-matters-so-much-more-but-wait
http://AJaxian.com/archives/ecmascript-harmony-coming-together-after-oslo
http://ejohn.org/blog/ecmascript-harmony/