The power and limitations of HTML5

image Back in July I wrote about Google’s HTML5 initiatives on mobile – including their YouTube HTML5 mobile site and their Google Maps HTML5 mobile site.  This week they have been showing off what HTML5 can do on the desk top – at least when running in Chrome.  Check out this custom interactive video for the song “We used to wait” from Arcade Fire – I’m a sucker for music with a bit of a dance beat which may have influenced my opinion, but I loved it. 

As a starter the video is pretty cool, but beyond that the customisation and dynamic rendering is awesome.  You begin by typing in the address where you grew up and then, after a lengthy pause while the video is generated, the action kicks in.  They integrated with Google street view to have me zooming up and down the street where I used to live in time to the music (nice to see my mum’s car is still there…) and dynamically grew trees in a line down the middle of the road.  There are also a bunch of other nice effects including the ability to type directly onto the webpage in a generative typeface.  If you are into this stuff you should check it out.

On a similar note check out Scribd’s HTML5 demo. It showcases rendering complex images and text directly in HTML and using browser functions like search and select text to directly manipulate documents.  That’s much better than using Flash, PDFs and other plugins which take time to load, can crash the browser, and make documents difficult to manipulate.

So far so cool, and other HTML5 features including drag and drop, offline storage and geolocation will massively increase the power of browser apps.

Turning to the limitations – Techcrunch has a piece up today which highlights the immaturity of HTML5 standards.  The cool stuff in the Arcade Fire video doesn’t work in Firefox or IE, both of which consider themselves to be HTML compliant, and in fact was written for Chrome.  That is a really big deal, there is limited value in having cool features available if you have to code differently for each browser to get them to work.

Continuing my thought from yesterday – I’m also starting to think that to compete effectively with native apps the HTML5 standards will need to take advantage of the richness of touch screen interfaces – side swipes, two fingers down and other gestures should be incorporated into web page navigation.

Done right the web and the browser should be a more efficient way of delivering many if not most services – both desktop and mobile – but if the infrastructure and underlying standards aren’t good enough native apps will be more appealing to developers – which will slow the pace of innovation.  The standards issues Techcrunch wrote about today are concerning from this perspective.

Enhanced by Zemanta
  • I feel like I’m literally the only person on the web not to have liked that video. I love the song, but when I looked at the video I found myself thinking; “Is that it? Is that the state of the art after all this time?” It feels contrived and limited by the realities of the new technology rather than pushing any true boundaries and exploring something new. I.e. had this been shown to us in flash about 5 years ago I still wouldn’t have been surprised.

    Then again, I DO have a HD realtime 3D castle on my iPhone 4 (Epic Castle) that’s so detailed you can pick out the individual branches on the ivy… So perhaps I expect more these days?

    Or perhaps I’m simply being awkward 😛

  • James Hancock

    I’m still struggling with if HTML 5 is worth the bet or to go Silverlight for our next project. Works better, super fast, reliable and easier to develop against, and with Windows Phone 7, Nokia, BB and Android support coming it seems like a no brainier for so many reasons. Kills flash and is the best of web and windows apps combined.

  • My response to Erick’s fantasy on TC: http://rafer.net/post/1056267071/in-the-coming-html5-browser-wars-the-markup-should

    I don’t recommend that you use the above as investment parameters.

  • I can see that. Deciding when to adopt an immature technology that looks like it might be the future is always difficult.

    It would be interesting to hear what you decide and your reasons.

  • I know what you mean – the way all the frames popped up might be clever, but aesthetically it left a little to be desired.

  • James Hancock

    We’re leaning Silverlight at this point simply because we can get much more done with it. We don’t like the plugin requirement, but then we’re doing Business applications so requiring it isn’t a huge deal. We’re actually thinking about having a rich client in Silverlight and a “quick” client when you’re on a guest computer in HTML with the basics and then a fully HTML 5 smartphone version with a customized user interface…. seems like a ton of duplication for little reason though. HTML is just a PITA to develop and maintain. State management is the worst in all platforms trying to deal with the Invoice + Details connumdrum where you have 3 bad choices: 1. Use the viewstate or similar, 2. Use Session State or similar, 3. Reload from the DB all of the time.

    All three are horrible in HTML the way it’s being used right now. Silverlight solves this by making the client computer actually do the logic and just gets and posts data, so there is question about what the server’s job is, HTML does not.

  • Interesting detail, thanks.

  • Pingback: Touchscreen web apps | Bookmarks()