Well the moment I've been dreading has finally arrived. The Microsoft IE team has announced that IE 8 will include an important new feature that is not standard to Ajax: The ability to update the navigation log using JavaScript.As Waldek Mastykarz said in his blog Innovation Matters, "What concerns me is the fact, that it will be supported in IE8 only." You got it; Microsoft has drawn first blood in what will be the next browser war. As Microsoft introduces new features the Firefox team will be faced again and again with two questions:
- "Do we implement everything Microsoft does or do we pick and choose?"
- "Do we innovate through a standards process or do we choose to implement first and standardize second?"
The answer to these questions will determine whether or not Firefox falls in line with Microsoft or asserts itself as a leading browser provider. The outcome seems obvious to me: No self respecting open source team will allow Microsoft to dictate its technical direction.
The Firefox team might implement this new navigation feature for Ajax applications, but it won't implement everything Microsoft chooses to add to each new version Internet Explorer. As a result Microsoft IE and Firefox will diverge to the point that Ajax applications will no longer be portable across these two leading browsers.
The downfall of DHTML, a lack of consistency across browsers brought about the first Browser Wars of the mid and late 1990's, will be exactly the same downfall for Ajax. Microsoft and Firefox are about to rekindle the Browser Wars and its the developers and end-users who are going to suffer.
This only confirms in my mind that plug-in technologies provided by a single vendor (e.g. Flash, Curl, Silverlight, Java) are the only viable RIA solutions in the years to come. Microsoft and Mozilla can innovate and diverge all they want, the RIA plug-in solutions will be able to adapt quickly and effectively protect and encapsulate applications inside their own runtimes.
Ajax is dead RIA walking.
Update:
My old friend Dion Almaer took issue with this post in his own post on Ajaxian.com that says:
I'll admit that I didn't know that this feature was included in HTML 5. The fact that it comes from the HTML 5 standard is certainly encouraging - I really do want Ajax to survive because its a great mass-consumer solution and it provides the glue that allows us to wire different RIA solutions together.
What is interesting here is that even though Sharath said: "adopted in IE8 from HTML5" we have Richard Monson-Haefel (Curl evangelist) saying Ajax is dead RIA walking. This strong conclusion comes from the fact that IE implemented an HTML 5 feature???
Having said that - and not being one to give up so easily - there are two things of interest. First is the fact that HTML 5 is a working draft, not a finished specification. It's quite possible that the APIs in that draft will change before its finished in which case Microsoft's implementation of this feature could be broken. Will Microsoft wait for the W3C to finish HTML 5 before shipping IE8? Maybe, but I doubt it. So IE8 could ship with an API that changes.
The other issue is how much of HTML 5 and what parts of HTML 5 does Microsoft plan to implement in IE8 and future versions of IE? Which parts will Firefox and WebKit implement with what versions of their browsers? I suspect that different browser vendors will implement different aspects of HTML 5 at different rates according to slightly different versions of the HTML 5 specification. Not exactly a recipe for consistent and standardized implementations across browsers.
Just look at the the inconsistent implementation of other W3C standards such as CSS and SVG: None of the vendors implement all the features of CSS. Microsoft will pick and choose the HTML 5 features they wish to implement and by not embracing the entire specification (which is only in draft format) they will effectively make their browser less compatible with other browsers and so we are back to square one: Inconsistent implementations with features sets that are so disparate that Ajax frameworks will not be able to keep negotiating the gaps.
The fact that IE8's new feature is defined in the working draft of HTML 5 is encouraging but not convincing given the history of the parties involved and the history of implementation of W3C standards.
17 comments:
Richard, are you not aware that the XMLHttpRequest API - sometimes called the X in Ajax - was a Microsoft proprietary extension first?
It is now an international standard present in all major browsers.
Proprietary innovations that have value get copied and become standards.
It is precisely this kind of innovation - innovation by multiple vendors trying to leapfrog each other - that moves standards forward quickly.
This is the exact opposite of the "End of Ajax". This is the Ajax Renaissance.
Read the full post at blog.isomorphic.com
I guess that most AJAX developers uses libraries, frameworks and tools because there are already differences between browsers. So somehow you not coding to the browser anyway, you are coding to DOJO, JQuery or even further : GWT or JSF.
This Javascript layer isn't standardized at all, it is very fragmented and a bit innovating. Hopefully it will allow a smooth evolution of the underlaying, rather stagnating, browsers.
I am not so sure. Good developers will continue to implement only what is cross-browser compatible, and let JS libraries fill in the gaps when possible.
I agree. Although this is the wrong direction for things to be heading (thanks again Microsoft) the JavaScript libraries will smooth everything out for us somewhat negating any resurgence of the "Browser Wars" of yore.
The WebKit boy are doing exactly the same: every second week they invent something new. Is this the end of AJAX? No, good developers will use standards(like Matt said) and goog features will be standarized sooner or later. Remember that we are working in innovative branch, new things will be developed and the they have to be developed.
I totally disagree with this post. This is Good for Ajax. Brower vendors need to innovate to continue pushing the limits allowing better applications. If a particular feature is well received, the other browser vendors will likely implement it as well. In the meantime - that's what javascript frameworks are for.
@Charles Kendrick
I'm well versed in the pedigree of XHR. What people forget is that XHR was adopted by Firefox and other browsers because IE dominated the web so completely that doing anything else would have been just stupid. Anyway, the pattern where each browser vendor innovates is great - its the divergence of innovation that is problematic in a technology whose greatest strength is supposed to be standardization (de facto or otherwise).
@Bruno, Matt, and Jamie:
I hope you are right, but if memory serves developers didn't have a lot of luck sticking just to standards with DHTML - the divergence between IE and Netscape became too great and the commonly supported features too shallow. If you freeze Ajax where it is today that will work for a while, but Ajax needs to evolve too and sticking only to standards while each browser vendor (Microsoft and Mozilla and WebKit) are trying to out-feature each other is not going to work in my opinion.
The javascript frameworks constitute a layer that change the game between browsers. How browsers will evolve now depends also on their development. It would be nice if they drive the innovation : the best browser would be the best bed for the framework.
Also I wonder if the Microsoft's XHR feature, that stayed a long time unnoticed, exploded because the term "AJAX" was invented or because other browsers implemented it.
This is completely off topic, but I was a little put off by your choice of graphic to use in this post.
The agony in the face of the marine carrying casualties is too strong for a lighthearted discussion on silly browser issues.
That the price of success, reminds me of the Beattles talking about being as known as Jesus.
Notice that the monkey face you choose as an avatar didn't put anyone off.
The history of the past few years has shown that all browsers diverge while innovating, and then converge on a standard (like HTML5). This I would argue is the healthy way to innovate.
Standards lead innovation leads to things like XHTML2 which take too long and are not grounded in reality.
Silo lead innovation leads to vendor traps that we suffered from in the 80s and 90s.
I disagree with your post. I will give you an example.
The last W3C XMLHttpRequest document doesn't define a way of doing cross-site Ajax requests, but Mozilla, Google and others have developed their own hacks to perform cross-site requests
... are they also killing Ajax?
Who Knows may be in future there could be script to fix ajax issues in FIREFOX (Too Strange isn't?). They days are counted for the Other browsers. And the day is not so far that a browser could introduce themselves as the pretended HTML5 Standards, Whats the solution for this could be the release of HTML5 Specs asap. Otherwise people will think of their own that this could be adopted.
@Richard, who said: "Inconsistent implementations with features sets that are so disparate that Ajax frameworks will not be able to keep negotiating the gaps."
A little more history then: in 2001 SmartClient 1.0 was released with grid components that supported the "live scrolling" feature that only now making it's way into other Ajax frameworks.
This feature was supported across IE4 and Netscape 4.x. At the time Netscape 4.x DHTML support was via "new Layer()" - no DOM-like APIs at all. The feature was supported via the same high-level, declarative APIs found it SmartClient 6.5 today.
Compared to this, providing normalized APIs for history navigation is exceedingly trivial.
good work ... great goin... visit mine...link1
I agree with you that RIA could be more consistent using a single-vendor plugin product, but today what I see is that implementation for different browser/platform are not equal. EG flash plugin is really buggy in Vista and I don't think that Silvelight supporto for Firefox will be the same of IE.
PS: maybe a pragmatic solution could be replace default javascript engine of browser with a single vendor implementation (a la java plugin)
Thanks ever so much, very useful article. If you do not mind, please visit my article related to travel to Pandeglang district in Banten, Indonesia at Kenali dan Kunjungi Objek Wisata di Pandeglang
Best regards
Post a Comment