Posted on November 11, 2011
Now Don't Get Cocky "Web Standards" Dudes, HTML5 Still Has A Looooooooong Way To Go.
Two days ago Adobe announced that were were ceasing development of the Flash player for the mobile web, in favor of HTML5. They will focus on the air packagers and PC/Mac browser plugins. Technologically speaking, nothing has really changed, as Adobe already had an issue with Flash not being supported on iOS browsers. So what has changed? The perception of Flash: the fact that Fortune 500 CIOs think they can now ONLY use HTML5 for web sites, or they will look like Luddites. While this certainly is a boon to HTML5, and has probably numbered the days for the .SWF format (from infinity to about 1000), the successor, HTML5 has a few things to answer for before it can swoop in and push Flash off the cliff.
1. Audio Playback : HTML5 Audio in the PC browser is awful. HTML5 Audio on mobile is atrocious. Audio issues that Macromedia solved in Flash 10 years ago plague HTML5 and don’t look to get better an time soon. Zynga recently released Jukebox to help with this problem, but it falls back to…Flash. That is not gonna work now, is it? Until this is fixed, the web is going sounds pretty much like it did back in 1998 when we all tried to play audio with Java applets!
2. Media Formats: Flash ingests disparate audio and video media formats and spits out a single format to be played across multiple platforms. Essentially, this ability is what created Youtube.com, allowed for audio streaming inside firewalls, and spurred and the Web 2.0 personal media revolution. HTML5 audio and video is stuck in a war over which formats to support, making developers do the same work multiple times to get similar (but not equal results). This needs to be fixed immediately. A the same time, Flash allows for secure, monetizable video streams that are currently not available in HTML5
4. Non-Standard Security Sandboxing : Security sandboxing among different browsers makes creating some web-site based HTML5 apps a real chore. In some instances, code that works locally (to load video for instance) does not work from a web site in certain browsers because it breaks the security sandboxing rules. Flash solved this problem by allowing the developer to set sandboxing rules that were followed across platforms and browsers.
5. Performance : HTML5 is sill slower than Flash running the same kind of application. In certain browsers (iOs 5.0 Safari) this is getting better, and should prove to get better with Windows Metro, but it’s still not good enough yet.
6. Sockets/Networking : Socket and Networking programming (for multi-player games and other uses) is still very primitive in HTML5 and relies on POST requests for communication. (at least until Web Sockets arrives universally) This is akin to the old “server-push” model from the late 90’s It works, but it has a long way to go to match what Flash can do.
9. A Good Flash IDE-like tool for creating HTML5 content does NOT exist. This has forced us and other HTML5 designers to use the FLASH IDE (of all things) to create animations and interactivity, and then pray that the developers can replicate what they have designed with exported Sprite Sheets, png sequences, and rabbits pulled from hats. Designers and programmers alike rely on masks, animation paths, tweens, video with alpha channels for blue-screening, and 100’s of more features, tweeks, and tools in the Flash IDE that will need to be replicated in order to replace Flash. It is now Adobe’s job to create this tool, as they have taken on the burden. God-Speed and good luck.
We do think that HTML5 is promising, and since Adobe is basically ceding it to the Web (at least for general web site uses), we have to make the best of it. However, now that HTML5 is in the spotlight, it has to make good on its’ promise. The list of things here is just the tip of the iceberg. There are probably dozens of other uses for Flash that cannot (yet) be replicated in HTML5. If HTML5 truly is the future, it needs to catch-up to the present as fast as possible.