"Translating" immature standardization is the only thing we're afraid of.

The only Thing We Have to fear is premature standardization

Original address: http://yuiblog.com/blog/2008/08/14/premature-standardization/

The web is made of open standards. This is a significant factor in the Web ' s displacement of proprietary application platforms. The openness is hugely attractive and so much of the web dominates over competitors with better technologies. The difficult tradeoff that comes with a standards-based approach are that it's 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's potential has been used up.

The internet is made up of open standards. This is an important factor in replacing the private application platform with the Internet. Openness is attractive, and because of this, the Internet controls other competitors with better technology. But when standards-based approaches are temporary, innovation can become increasingly difficult. As a result, the most basic technology stagnation in browsers has been growing for a long time. Some of the innovations that make us happy, such as the Ajax Revolution, are the potential to rediscover existing standards. Yet this potential has almost dried up.

if we are to go forward, we must repair the standards. This is something that must being done with great care. A revision to a standard be an act of violence, just like any surgical procedure. It should is 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 are why, 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 Bec Ome the seeds of failure for the users of others. Developers must manage this gulf, and it isn't easy. Developers are not a. Served by new standards this make their jobs even harder.

If we want to move further, we must revise the standard. This is a matter that must be very careful. Standard revisions are acts of violence, like surgery. Standards can be used only when the benefits of standards are far higher than their own costs and drawbacks. The internet does not have the prior software upgrade management, which makes it a very complex environment, such as IE5, a very very old browser, its user share is more than safari and opera add up. Because of this, the standard changes will put developers into a very difficult environment, many of the advantages of some browsers may become other browsers potential errors. Developers must manage and reduce these differences, but this is not easy. At the same time, developers ' inability to better adapt to new standards also adds to the difficulty of their work.

I am The It are instructive to look at the two approaches to managing innovation within a standards based system, one that I vie W as a success, and the other isn't so much. JavaScript is a promising but half-baked language that is irresponsibly rushed to market and then cast int o a standard. That's standard is called ECMAScript to avoid a trademark dispute. That standard is last revised in 1999.

I think it is very useful to compare and produce innovations based on standard systems and systems that are not very standard. JavaScript is a very promising language, but it itself is very immature, it was too quickly irresponsible to throw into the browser market, and was irresponsibly thrown into the standard circle. To avoid potential copyright disputes, this standard is called ECMAScript. The time it last updated was 1999 years.

It is clear this language needs to be updated, but TC39 (the committee this is responsible for drafting a new standard Could not reach consensus in how does it, so it is split into the two groups, each producing its own proposal. This has a good thing in so competition is healthy, and I believe that competition inspired improvements to both Proposa Ls. This is also a bad thing because no standards organization can adopt two for the proposal same. Without consensus, both proposals must fail.

It is very obvious that the language needs to be updated and upgraded. But TC39 on how to update the problem, but not to achieve the same. So they were divided into two groups, respectively, to achieve their respective goals. Such healthy competition is very helpful and I believe that competition will improve both sets of objectives. But that's also a bad thing, because no standard organization would accept a standard with two different proposals. If no agreement is reached, both proposals will fail.

On one side there is the proposal called ES4. It is unfortunate that it adopted this name because it strongly suggested that it is destined to be the fourth Edition O F ECMAScript, a fate that is not certain. The project is very open to new ideas and features, adopting a porkbarrel attitude this is almost congressional in its E Xpansiveness. Lots of good ideas were included without a 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 LANGUAG E.

One of the proposals is called ES4. The use of this name is unlucky because it strongly suggests that it will be the fourth edition of ECMAScript, but it is not necessarily. The project is very open to new ideas and has adopted many ideas, although these ideas have not been fully analyzed on the basis of this language system. As a result, many complex features have been adopted and eventually increased the complexity of the entire language.

ES4 is so large and so innovative that there were doubts about whether it could to successfully and specified . More worrisome, there is 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 is put on place and adopted by the browser makers before that question LD be answered. This is a problem because once a bug are inserted into a standard, it can being extremely difficult to remove it. All of the features, considered individually, were attractive. But taken as a whole, the language was a mess.

ES4 is very large and introduces a lot of new ideas, which makes you wonder whether it will be successfully accepted and used. What is even more disturbing is that there is no experience of using the language itself. Will the attractive new features produce many potential problems like ES1 and ES3? The ES4 arrangement requires that the standard must be accepted by the browser developer and implanted in the browser to answer the question just now. This is going to be a big problem when a small bug is incorrectly added to the standard and it's going to be very difficult to get rid of it. It is very appealing to consider all the new features of ES4 alone. But all together, the language is very confusing.

On the other side is a proposal called ES3.1. Its name indicated a less ambitious proposal, being a smaller increment to the current third Edition. This project is intended to repair as many of the problems with the language as possible while minimizing the pain of dis Ruption. New syntax is considered only when it is already implemented and proven in the least of the three four. Feature selection tended to favor necessary improvements over desirable.

Another proposal is called ES3.1. Its name implies that it is only less transformative than the current ES3. The goal of this project is to fix many errors in the language. The new syntax is not considered for inclusion until at least three to four major browsers have been implanted and tested. They are more selective about the features they need, not the features they can have.

ES3.1 is more minimal in approach. The set of feature interactions is much smaller and more easier to reason about. ES3.1 is likely to complete its specification and would be the candidate for the fourth Edition.

ES3.1 is easier to accept. New features are less attractive, but easier to implement. ES3.1 may also complete its documentation to become the candidate for the ES Real fourth edition.

ES4 had a large head start (by as much as seven years by some estimates), but is unable to meet its deadlines. Ultimately, the project fell apart when some of the key is left.

ES4 started early (estimated at least 7 years ago), but we couldn't see when it would end. Eventually, the project was stranded because of the departure of the core members.

Some of the features that were in ES4 were reasonable, so a new project, called Harmony, is starting which'll look at ad Apting the best of ES4 on top of ES3.1. The success of this project would depend on the ability of TC39 to do a better job of managing the tradeoffs between the Innova tion and stability, and adopting a discipline for managing complexity. Simplicity should is highly valued in a standard. Simplicity cannot be added. Instead, complexity must be removed.

Now, some of the reasonable new features introduced by ES4 have been reintroduced as a new project, known as Harmony. The success of this project depends on the ability of TC39 to weigh both innovation and stability, and on the management of complexity. In a way, simplicity should be given enough attention and not be pretentious. Therefore, some redundancy must be eliminated.

It turns out this standard bodies are not good places to innovate. That ' s what laboratories and startups are for. Standards must is drafted by consensus. Standards must is free of controversy. If a feature is too murky to produce a consensus, then it should the not being a candidate for standardization. It is for a good reason, "design by committee" is a pejorative. Standards bodies should is not being in the business of the. They should stick to careful specification, which are important and difficult work.

Now it seems that the subject of the standard is not a good place to innovate. This is precisely the purpose of laboratory existence. Standards must be negotiated in a coherent and full debate. If a feature is difficult to agree on, it should be removed from the draft standard. The subject of the standard cannot be designed for commercial purposes. They must stick to careful design, which at the same time is a rather difficult job.

I similar stories in HTML5. The early work of WHATWG in documenting the undocumented behavior of HTML is 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 the a complete reset with a stronger set of the design rules. Things can be much worse than the way things currently. Having a smart people with good intentions are necessary but not sufficient for making good standards.

I also saw a very similar situation in the HTML5. The early days of WHATWG are great for documenting features that are not documented in HTML. But when people start focusing only on creating new things, they start to deviate from the track. There are too many controversies in the HTML5. Things could be worse than they are now. Perhaps a wise man with good will is necessary, but not enough to cast good standards.

Extended reading:

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/