Home >
NOTE: This is a cross-post from my blog. I rarely (if ever) cross-post, but with the attention this topic has garnered, I wanted to be sure this information was easily accessible to all.
If you monitor the web, you likely think that the Flash Player and Silverlight are on life support, and that HTML5 is rapidly changing what is possible on the web. In reality, many people who are commenting on HTML5 don't fully understand the current landscape. Did you know that HTML5 editor Ian Hickson stated that HTML5 won't fully be implemented in all browsers until 2022? Did you know that iPhone developers can start fully using HTML5 now? Did you know that all features in HTML5 were originally from web plugins? Did you know that Google uses a web plugin for Google Wave?
We need an open honest discussion about HTML5 and what it means for the web. Unfortunately, you aren't going to get the truth from fanatics on either side, but instead we all need to examine all of the evidence and come to our own conclusions. I have spent a great deal of time analyzing the facts, and in the process I have made several observations.
DISCLAIMER: In full disclosure, I must mention that currently I am Flash Platform developer (primarily Flex/AIR). I also write a regular column for the Adobe NewsFlash newsletter. However, before I became a full-time Flash Platform developer, I was a traditional web developer who spent all day dealing with HTML, CSS, JavaScript, and PHP. I feel that I have an understanding of both sides of the discussion (but obviously am open to any input anyone has on the matter).
The Present
After much effort by many dedicated developers, HTML5 is just about ready for prime time. This process started about a decade ago, and gone through many iterations. Today, HTML5 is available and ready to go on a few platforms/browsers. However, not all browsers implement all of the standards, and some browsers haven't even announced when they expect to have full HTML5 support6. In reality, version 3 of the iPhone OS is the only solid platform that has full HTML5 support (as well as some other fixed development platforms). What does this mean for developers? It means that HTML5 is still very much in the future (and not the present) for a majority of developers.
I was struck when reading Jeff Croft's posting, Two Thousand and Twenty-Two, last September. It shed a lot of light on the frustration many developers are having with web standards as a whole. While, I haven't even talked with Jeff directly, I have always been a fan of his work. After learning of the bleak timeline1 put forth for full HTML 5 browser adoption, Jeff stated: "it ultimately doesn’t matter if HTML 5 is available next month, next year, or fifty years from now. Those of us who do real work in this industry know that the only thing that really matters is what specs and technologies are supported by the browsers real people use".
Developers who have to build solutions for clients don't care about the theoretical, they care about the reality. On that same vein, a solution is not a solution if it only applies to 10% of the target audience. It isn't a solution if only applies to 90% (and leaves out 10%). Clients want sites/applications that work well for every member of the target audience - and they want it today. This brings me to my first observation:
Observation 1: Developers won't be able to use HTML 5 in solutions they build for their clients (unless they are on a fixed-platform as described above) until at least 2014. For full HTML 5 functionality, this will be much later even than this.1
Developers could look at creating solutions that leverage both HTML5 and the current HTML/JS model. However, this would mean that for a single solution a developer would have to create:
- Browser detection to determine if the user is HTML5 capable
- A full HTML 4.1/XHTML 1 application for current and older browsers:
- Multiple CSS files (including hacks) to support IE6, IE7, Firefox 3, Safari 3
- JavaScript that is compatible with all browsers listed above
- A full HTML5 application (which will have little code overlap from the HTML 4.1 application)
For developers who already have to deal with the CSS and JavaScript craziness, this would just add another layer of complexity. In reality, HTML5 won't be an option for traditional developers until 90%+ of the web is using an HTML5 capable browser. Keep in mind that most all sites still have to check for IE6 users, even though it was released eight years ago (2001).
The Truth About Plugins
At the heart of this discussion are the web plugings that we use today. Many articles5 have been written lately claiming that HTML5 will kill off traditional web plugins. In reality, this is far from the truth. Before I address that issue directly, we need to take a closer look at what is a web plugin.
When listing the common web plugins, most people realize that this includes the Adobe Flash Player, Microsoft Silverlight, and JavaFX. However, this also includes Google Gears, Google Native Client, the Google Earth plug-in, as well as the Google audio/video chat plug-in. In addition, to the Google plugins, there are countless plugins by other vendors. These plugins have been vilified due to the fact that they are 'closed source' projects. The truth is that the plugins have a rapid development cycle that leads to innovation. I am not saying that this can't happen with an open source project, but I develop cutting-edge solutions for real clients. I can't look to web standards for real innovation - only more of what has already been implemented:
Observation 2: Web standards will never innovate - they will only implement what plugins have already successfully included. This is due to the fact that the standards process is run by Microsoft, Google, Mozilla, and other companies that aren't going to invest in implementing a feature unless it already has a proven place in development. The term standardization implies that you are taking something that already exists and creating a uniform process for implementing it.
In addition, many developers fail to acknowledge the role plugins have played in the HTML5 standard. This brings me to an observation:
Observation 3: Every new feature in HTML 5 (except maybe 2) were added because developers wanted functionality already available in a plugin. This includes offline cache (Google Gears), canvas (Flash Player), media playback (Flash Player and others), drag and drop (Flash Player and others), etc...3
At the recent forefront of this debate has been Google Wave, recently announced by Google at the Google IO Conference. This rich Internet application has been hailed as a great example of what web standards can do. However, virtually no one has commented on the fact that it requires a plugin to function. Yes, the example of what HTML5 can do requires Google Gears for some of its functionality. In reality, it is only for a small portion of the functionality (drag and drop), but it brings to light an important observation.
Observation 4: Google had the option to go through the standards process and try to add the drag and drop functionality before releasing Wave, but they decided that the user experience would suffer without the functionality. Instead, they chose to use the plugin to provide the best overall user experience.2
The truth is that plugins can 'upgrade the web' in under a year. In reality, an idea can go through production, QA, released to users, and then pushed to 85%+ of the web within 16 months4. This is not the case with web standards:
Observation 5: Because of the major corporations and entities (as well as egos) that are involved, any major change (that requires browser creators to change functionality in a uniform manner), is guaranteed to take at least a decade from idea inception to actual implementation (across all browsers). The time required to allow for users of older browsers to upgrade, can add another 5+ years to the process.1
If HTML5 were completely implemented by all major browsers today, and if all users had these upgraded browsers - the web plugins would take a serious beating from HTML5 (although even then - it wouldn't kill them). In reality, HTML5 can't even compete with the web plugins - because it is currently only viable on fixed-platform solutions (like the iPhone).
Quality vs. Standards
One of my major points of anger on this topic is that many developers are ignoring quality in pursuit of web standards. That is at the center of the video codec debate (and there are many examples of these types of issues around HTML5). Developers are choosing to evaluate solutions based on their relative openness rather than their actual functionality. What have the last five years taught us? We are finally entering an era where we understand that user experience is the key, and now some developers want to sacrifice quality for openness. This beings me to one of my most vehement observations:
Observation 6: Many open-source solutions are at the top of their respective field (Apache, MySQL, Linux, the Flex Framework, etc...). Inferior solutions (like the Ogg codecs) should not be tolerated just because they are 'open'. If you want all browsers to implement a video codec, make one that is better than h.264. Developers should never sacrifice the user experience for the warm feeling they get when using 'open' solutions.
When a potential client looks at my body of work (or my company's body of work) they will not care about web standards - they will care about the quality and functionality of the work. In addition, when a user uses my application, they won't care about 'openness' but only about the overall functionality and user experience. As a developer and an employee of a company - I cannot recommend an inferior solution. I have to evaluate all solutions based on functionality to stay competitive. This means that in the future, HTML5 will be a solution that I consider if it provides better functionality - but, I will not choose it simply because it is open. It will be on equal footing with the other solutions that are available.
The Future
I hope that these overall observations have shed some light on this issue. The crux of the issue is this: fixed-platform developers can enjoy HTML5 now - and they should embrace it and start learning / working with it now. Traditional developers will have to wait around 5 years before it is a real option for them. In that time, we will probably have Flash Player 13, Silverlight 5, and JavaFX 3. Who knows what these versions will include - but, we can assume that the functionality they will include will probably be included in a future version of HTML.
Vote on What You Think Will Happen
Here at InsideRIA - we are currently having a poll where you can give your thoughts about HTML5 and web plugins. I encourage all who are interested in this issue to take part in the poll!
1 HTML 5 Editor Ian Hickson discusses features, pain points, adoption rate, and more
2 Google Wave (video described Wave's use of plugins)
3 HTML5 Versus Flash Versions
4 Adobe Flash Player Version Penetration
5 HTML 5: Could it kill Flash and Silverlight?, HTML 5: Could it kill Flash and Silverlight?
6 Compatibility tables for features in HTML5, CSS3, SVG and other upcoming web technologies, Implementations in Web Browsers




Facebook Application Development
@David, Indeed your opinion is biased a lot towards Flash.
Observation X: HTML5 with related proposals are 50% Microsoft's previously proprietary staff, 25% Apple's and 25% Google's.
Observation Y: HTML5 buzz is mainly about "video" tag and about how bad Internet Explorer is.
Hope my observations do not look more radical than yours :-)
@David, Indeed your opinion is biased a lot towards Flash.
Observation X: HTML5 with related proposals are 50% Microsoft's previously proprietary staff, 25% Apple's and 25% Google's.
Observation Y: HTML5 buzz is mainly about "video" tag and about how bad Internet Explorer is.
Hope my observations do not look more radical than yours :-)
You state that your customers want web applications that work for 100% of their users. If so, then why would you ever develop a web application that required a plug-in like Flash or Silverlight, which will always have some users that haven't installed the plug-in, plus some users that have installed an outdated version?
Hello David:
I am very impressed by your article. You have a vision and showed us smart view without a biased. I think 90% of your article is right.
Thanks for your clarification and write. Good day.
@Sergey - I truly don't think my opinion is biased towards Flash - but rather biased towards people who actually build solutions for clients. As I stated in the article - "Developers who have to build solutions for clients don't care about the theoretical, they care about the reality". HTML5 will be amazing when it is completed - my main point is that there shouldn't be much real discussion about it killing current solutions until it is viable - which won't be for a while.
@Anonymous - Good question. In reality - I choose to develop most of my applications as Flash Platform (Flash/Flex) applications or AJAX applications. The statistics that we know show that user compatibility for both of these technologies is roughly the same (around 98% of the Internet). You can view the link above to get more information on the Flash Player penetration statistics. The update item is a concern as well - Flash Player makes it easy for users to upgrade since version 8 (if I remember correctly) - and statistically users upgrade within the first 8-12 months of a new milestone version being released.
JavaFX is gaining ground as users install JavaFX anytime they upgrade their JRE. Silverlight still has lower numbers - but it is rising.
@Won - Thanks for the comment.
HTML 4 will live a long time more and so will IE 6 too. And Windows XP. And Flash will continue be the major "plugin" for serious Rich Internet Applications, because I subejctively think it's the best looking and most feature rich tool and the most mature platform. I welcome that Flash platform is more than simple animations and such.
@David - When saying about your opinion being biased towards Flash, I wanted to tell that these were not always plugins that did innovate mentioned in the "observation 3" features.
Otherwise I agree with many of your statements in the article and the one expressed in your response. To me it is more than clear that browsers have a very long way to run before they get acceptable performance, quality and ease of development available from Flash or Silverlight.
Also what I personaly (as software architect) think is that HTML5 and its supplimentary technologies (being either developed or re-worked) are not nice, also they are often inconsistent with theirselves. By being not nice indeed I mean they are not as nice as Flex or .Net
It looks like the whole direction of where HTML5 is rolling the web to is not more than just a possible compromise...
I feel the reason the plugins have a long life ahead of them is that they are usually tightly controlled by the company that created it. The company updates the plugin, markets the plugin and controls the plugin to their best interest in an attempt to maintain market share.
HTML5 will take so long to become mainstream that it will be too late to be relevant. By that time we'll be asking where's HTML6 that competes with the latest plugins?
The reason? Easy, HTML5 is designed by committee and you can't design something like that with a committee. You end up with situations where each part of the committee pushes their own agenda and tries to hinder the agendas of others. It eventually takes months or years to finalize something as simple as a single tag and how to implement it.
HTML5 will always have problems simply because they are trying to implement things we've been doing for years already, albeit with plugins. The end user does not care how it works, just that it works. Some people point out asking end users to download/install plugins is a hindrance to the user experience. HTML5 will solve this by making it seamless. But not all browsers will support HTML5 correctly anytime soon, if at all.
What do you think would be easier? Asking an end user to download/install (or even update) a plugin for his current browser or to switch the entire browser just for your website/application?
That's why plugins will have a rather healthy lifespan for a long while to come.
@Travis - I couldn't have said it better. There are a lot of good features that are in HTML5, but if you really think about it, HTML5 is just playing catchup to what plugins are currently providing. By the time HTML5 apps go mainstream, plugins will have already moved on to the next cool technology. Then this whole cycle will repeat itself w/ HTML6...
I feel as long as the web browsers are still around, plugins will always be there alongside. Imo, the root of the problem w/ web browsers is not really the technology, but it's the adoption of the latest version of the browsers. At my company, a majority of our users are still using IE6. It may be years before we can get them to upgrade their browser.
To be fair, Wave is a very early developer sandbox release. Google is committed to HTML 5 and will not make Wave dependent on Gears. Instead, they have written a compatibility layer that uses HTML 5 if available and Gears if not (read IE!).
On desktops, Safari and Firefox 3.5 already do a great job of implementing HTML 5. Opera also covers much of the standard and is committed to complete coverage. Google is also committed to complete converage in Chrome.
So, in the longish term, Microsoft is the primary hold-out and that is enough to make HTML 5 on the desktop a problem. That was a show stopper for me and my project.
Another issue in HTML 5 is the variation in implementation. Try searching for some HTML 5 Canvas demos/games. Run them on Opera, Safari, FireFox and Chrome. You will get very different performance and behavior on the 4 browsers. This is likely to be a problem for a long time.
Based on all of this, I chose Flex for my project. I could not be happier. I'm writing a very significant application with a minimal REST back end. With Flex and AS3, I get really great tooling to support large application development. Plug-ins really shine in their tooling support. HTML 5 will lag behind in this regard until Google integrates full HTML 5 support (and compatibility in IE) into Google Web Toolkit.