Framehawk Inc.

I think all of us tech folk are very focused on never repeating the Great Browser Wars of the last 15 years.  Having a site that said “works with Firefox 3, 3.5, IE6, and IE7 only” was a serious (and often unavoidable) injury to a firm.  It blocked out entire parts of the potential customer base who didn’t have or couldn’t get the particular browser version desired.  It did keep BYO M(acs) people from bringing those goofy Safari browsers into the office.  [Note, I own every type of Apple product, so I include myself.]

I was looking through html5test.com and rng.io data recently and was impressed with how the browser scores for many devices have improved over the last year.  One might even suggest that for the majority-share devices/browsers, the compatibility is high against the (not completed) spec to the point where we can declare victory!

I really wish so.  But not so fast…

The interesting premise of HTML5 is also one of its primary weaknesses.  It built audio/video and storage access right into the browser spec and included a flexible graphics scheme called canvas.   That’s all you need, right?

The mobile device browsers have decided to embrace this mantra pretty consistently and enforce a “plug-in free” experience.

As a result, there seem to be a few fundamental challenges that cause HTML5 pain today.  Will either of them be so painful as to inflict injury on your company?

1) HTML5 was not intended for high performance, it was intended for mass appeal.  Don’t get me wrong, you can build a high-performance Web app using HTML5.  But doing so in a way that works across the variances of device size and browser strengths is quite difficult, if not impossible.  Lightweight lowest common denominator apps are fine in HTML5, however.

2) Built-in HTML5 browsers on mobile devices have embraced the “plug-in free” part of the spec.  That means no Flash, no Silverlight.  No embedded PDFs.  No native hardware manipulation. This is a killer for many enterprises who have spent the last 20 years building these things, and do not have the dollars in their IT budget to rewrite their business apps again.

How about new apps?  If you need to do something fancy, immersive, and “predictable” are you stuck with a native app-per-platform model?   Hey, learning something new (times 3 or 4) is what keeps those 10-14 million developers young!

3) HTML5 has limited APIs.  Comparing to something like the iOS SDK, I have seen estimates that there are 50-75x more APIs in the native app toolkits.  So, what do you do if you are a browser manufacturer and want the eyeballs and sex appeal?  That’s right! You *extend* your browser (“Hey, I am still part of the HTML5 team, I am complying with HTML5 spec.  Why are you looking at me funny?”).

You can see where this is going. You may not allow plug-ins, but you can create a pen API interface on your device and the other guys may develop a battery API for smart charging.  If you own both hardware AND a browser?  Oh yeah!  Can you give me access to the USB port?  A faster screen scaling function?  Network stack?  I’ll write to your browser!

So….you want to write something that is more than a (ahem) blog – a real mobile enterprise application.  What do you do?  Native apps mean you need to write and maintain the app on every platform.   And HTML5 means…you need to write and maintain on every platform?  Argh! Pick a browser or two and lock-in…

Folks, welcome to the Great Browser Wars, part 2 – thanks, ironically, to HTML5.  Battlefields never end with just a little pain….injuries are in the forecast, unfortunately.

This post also appears on Stephen’s Getting a Grep blog.