HTML 5 as a Silver Bullet

Since I’m in the business of trashing up and coming technologies (see my previous post) and may ultimately end up with my foot in my mouth, I figured I might was well share some thoughts on HTML 5. First, HTML is awesome. I am in no-way disputing the concept that running rich media content in a web browser without the need for a plugin or virtual machine is the way of the future. However, I too often these days talk to people in the tech sector who see HTML as a silver bullet that will magically solve all of the problems encountered by Flash, embedded apps, and Java, among others, without introducing any problems of its own. At least right now, this is a very dangerous view to hold, since plowing down an HTML 5 path without considering its current limitations can end in disaster. The concept behind HTML 5 is simple: use JavaScript for all of your client-side code, with AJAX requests to talk to the server, a canvas control to handle bitmap rendering, and a browser-based video control to handle video playing without the need for a SWF. In many cases this is great and all you need, but you need to remember that HTML 5 is still a very young platform. There are many fewer libraries, so things such as charting, 3D, graphics processing, handling live video and other hardware such as webcams, and many other common tasks are either not doable or very difficult. HTML 5 is also not entirely supported by many modern browsers. For example, Apple (the creator of the HTML 5 canvas control) doesn’t provide hardware acceleration for the canvas control in iOS Safari, so good luck running smooth game animations on the iPad. Currently, the performance and development time of HTML 5 for many RIA’s or mobile apps will be vastly worse than solutions developed in “old guard” technologies such as Flex, Silverlight, or native languages like Objective-C and Java on their respective mobile platforms. I’m waiting for the day when HTML 5 can ascend to the throne, but I don’t believe it’s entirely there yet. The question is, when will it be?

Tags: , , , ,

10 Responses to “HTML 5 as a Silver Bullet”

  1. Aaron Heinen

    I think the root of the problem lies at cross-browser compatibility. When I developed a new “HTML5″ video player I still had to include a fallback swf for Internet Explorer because the tag is not supported. I agree that HTML5 is by no means an end all be all, we should be utilizing any and all technology that meets the needs of the client, just like how carpenters don’t limit themselves to a hammer in their toolbox, developers shouldn’t limit themselves. That being said I wouldn’t mind a shift towards a “universal browser” in the sense of no more compatibility tables, no more css hacks, everyone that accesses the internet would be on the same playing field. (minus add-ons/plug-ins) Or they could just discontinue Internet Explorer and I’d be just as satisfied.

    Reply
  2. admin

    I totally agree that we should limit ourselves as developers, my point is just that HTML 5 is still an incomplete solution. It feels like back in the day (i.e. mid to late 1990’s) where some browsers didn’t even support JavaScript, so if you used that functionality you still had to implement a fallback anyway. I think we’re a year or two away from widespread HTML5 support with proper hardware acceleration on the canvas, etc. I think then technologies like Flex certainly won’t go away, they’ll just compiled into HTML5/JavaScript instead of a virtual-machine-based format like SWF.

    Reply
  3. goodman

    HTML5 is much more well developed in the mobile space. iOS and Android can handle HTML5 and CSS3 (which is often left out in the discussion, but shouldn’t be because it has some great new features) very well. CSS3 transitions and animations are hardware accelerated in iOS, which is great because JavaScript fades and animations can be very slow in mobile browsers.

    HTML5 is not a silver bullet, but if used right it can really help cross-platform issues. Also, you can do some great stuff inside a WebView on Android. The JavaScript version of Google Maps, for example, is much more feature rich than the MapView that Google provides.

    The biggest improvement with HTML5 is with video. Flash video is slow and has a lot of issues. I think HTML5 is a reality these days, since all modern browsers have good support for it. It’s also the only way to deliver video to iOS in a browser.

    Here is great discussion of HTML5 vs Mobile that was presented at the last Google I/O: http://youtu.be/4f2Zky_YyyQ

    Reply
    • hardin

      We’re using the peer-to-peer streaming in one of our projects, and it is very cool. Much more streamlined that using a server solution like Red5 or FMS. The big thing Flash video still has over HTML5 is that you can develop completely custom solutions in Flash/Flex that integrate video without being stuck with the browser’s rendition of the HTML5 video player and its controls.

      Recently though I’ve been working with jQuery’s UI control kit, and I’m very impressed. It’s still more cumbersome than whipping together UI’s in MXML, but it’s coming along way. Their data-grid control, for example, is fantastic. Things like this are what is going to make HTML5 the eventual winner, not just the video player. I agree with Neil though that the video component is currently the best motivation to utilize HTML5.

      Reply
  4. Jon Lange

    You make a great point about HTML 5 not being the solution to everyone’s problems yet. Microsoft however seems to think that it will be a cure all, announcing that Windows 8 is abandoning .NET in favor of HTML + Javascript. It will be very interesting to see how this paradigm is presented. If Microsoft can pull it off smoothly, we may see a veritable coup of the web development scene.

    Reply
    • hardin

      Any chance you’ve got a link to that announcement? That’s an interesting concept, especially since many components of .NET are server-side that would work in conjunction with HTML5, unless Microsoft is pushing something like node.js. I’d imagine you mean the post-back runat=”server” components from ASP.NET or Silverlight, but I’m curious as to what their press release was…

      Reply
    • hardin

      It looks to me like it might be related to their announcements about no plugin support in Metro-based browser mode, which would imply no Silverlight, Flash, etc. That said, obviously the Win7-based mode in Windows 8 will still support such apps. It’s very interesting though, I hadn’t heard anything about this yet. Thanks for the scoop…

      FYI here’s the link I briefly read after some quick Googling: http://www.infoq.com/news/2011/09/Metro-Plug-ins

      Reply
      • Jon Lange

        I’ve actually gotten the inside scoop from a former Microsoft employee. One of my current colleagues worked at Microsoft, Redmond up until last month. According to him, .NET client side is being removed, but server side will be preserved. It seems to be a result of internal politics over the whole LongHorn/Vista debacle. Microsoft is very persistent in dissolving DevDiv and Scott Guthrie. I should have been more specific in my original post, but .NET on the client side is being dissolved in the new Windows 8 paradigm, unless it is run on the desktop version, (upgraded Windows 7).

        Reply

Leave a Reply