HTML5: BlackBerry’s biggest asset or greatest distraction?

In the world of mobile computing, HTML5 is a potential disruptive force to the current way of doing things. Perhaps more specifically, it can disrupt the way Apple invented the mobile app ecosystem.

Mobile apps existed long before Apple came along. As BlackBerry owners know, it has always been easy to grab a link to a JAD file, click on it, and have the app install itself on your BlackBerry phone. But when Apple introduced their App Store, they centralized the distribution of iOS apps and imposed their own set of rules on what would be permitted in the store.

For consumers, the existence of a mobile application store makes things easy. It's like knowing that whatever you need to buy, you'll find it at Costco, or Home Depot, or whatever mega-store you want to substitute into this metaphor. There's one store to buy things from, there's one easy method payment, and there's one simple way to get app updates.

For publishers, it's convenient too. Publish your app in the store and don't worry about collecting the money. Don't worry about managing all those emails from customers who tell you they lost their download link or broke their device. The store takes care of it. That is, unless your app doesn't fit into their neat little framework, or unless you don't want to part with 30% commission. Or, unless you don't like the idea of someone else owning your customer.

Big media companies don't like the idea of having Apple (or anyone) "own" their mobile app subscribers. They want to be able to directly connect with customers by email, and collect payment outside of the walled-garden that is the app store.

Enter HTML5.

It's a whole new world of web programming. No longer is HTML useful only for presenting text, or rendering CSS stylesheets. HTML5 is dynamic, flexible and pretty darn powerful. The capabilities of HMTL5 let you do all kinds of things such as adding filters to an image, playing video, automatic drag and drop of files that get uploaded to a server, simple text chat, geolocation, scalable vector graphics, and much more.

RIM has embraced HTML5 by introducing the open sourced WebWorks development platform (essentially a fork of PhoneGap). They've even go so far as to build the BlackBerry 10 browser using HTML5, and they're pushing hard to show developers how easy it is to create BlackBerry 10 app using their tools.

RIM is by no means the only company supporting HTML5. Apple had a very public stance on the inevitable death of Flash, based on their belief that HTML5 would displace it. I think it's safe to say Apple was right about this. Every major player in mobile realizes the movement towards HMTL5.

But app developers who publish their work using a framework such as BlackBerry WebWorks are still publishing to a store. They are still dependent upon the rules of that store, and the commissions taken by the platform owner. Nothing really changes except for the programming lanuage.

That is, until people sidestep the stores completely and just publish their apps as a URL. Point your URL to the server that hosts your HTML5 app and you're in business. There is no app store. There are no versions to maintain for customers, since it's all hosted online. There are no issues with someone else owning your subscribers, if you have a subscription model. Everything is run through the browser.

HTML5 allows offline web caching, so that apps can work when they aren't connected to the Internet. Pretty awesome, right?

So what is HTML5 really useful for? In the long term, I don't know. It's probably going to extend far beyond whatever we're seeing today. Right now it's among the easiest ways to publish content-rich apps. Think news, weather, ebooks, video, audio, recipes, tour guides, or any other app that mostly consists of text, simple graphics, audio and video.

At the other end of the spectrum we have complex 3D games. But those games are usually coded on gaming SDKs such as Unity. I think the gaming industry has already proven that platform-specific tools are not the best approach for the big name developers (who can afford to use these tools). Big names would rather invest in a cross-platform tool that lets them bring their games to iOS, Android, BlackBerry 10 and Windows 8.

It seems to me, then, that this same truth will extend itself to content apps. RIM is putting a lot of effort into WebWorks. The code is all open source on GitHub, so anyone is free to run with it. Longer term, I think we'll be looking at a scenario where one best-in-class HTML5 app development kit exists, and platform vendors, like BlackBerry, contribute specific code blocks to enable the use of APIs on their devices.

News, weather, sports, and many other content-rich apps don't need to exist in a store. They need to exist on the web, and be saved as shortcut icons to the mobile device. We then need a public cloud with user authentication so that we can share our apps across our multiple devices. This is going to take many years to unfold, but that's where I see things going.

In the mean time, is BlackBerry going to be helped or hurt by this focus on HTML5? I actually think it will help them in the long and short run.

In the short run, they're giving developers two major choices. Develop using WebWorks, or develop using the native kit with Cascades. I suppose I should add that the Android player is a third choice. Considering how far these tools have been pushed along over the last couple of years, RIM is in a good position in terms of what it offers developers. The offline world of apps hasn't really taken hold yet, but iOS and Android developers now have an easier way to get their code running inside BlackBerry World.

Longer term, I think the bet on HTML5 will prevent RIM from falling behind in mobile computing. They will absolutely need to support the standard to the highest level. When mobile apps become mobile HTML5 websites, not distributed through a store, RIM needs to ensure these apps run on BlackBerry 10. If we all complain about the lack of Skype, Netflix and Instagram now, imagine what we'd be saying when it's not even the developer's choice anymore - imagine what we'd say when it's a limitation of the platform (and their poor support for HTML5).

I think RIM is placing the smart bet here. They're doing what works not only for the short term, but for the long term.

Support for HTML5 is fantastic, but the browser should have been written in C for best performance. Core apps should be multi-threaded for optimal responsiveness. The effort to write using WebWorks is fine for simple apps, but the performance will always be a little below par. It's not worth the compromise.

HTML5 Is very smart for 2 additional reasons. Enterprise and the car industry. In the business world it is far more palatable to write HTML5 apps for Blackberry that will work for everything as else as well. The loss of performance may be an acceptable trade off for universal function. In the car industry we have a new class of touchscreen devices with a very small app base to work with; HTML5 gives RIM a chance to get big name apps that want to work in cars as well (and Blackberry)

I also think that HTML5 will be great for remote car virtualization AKA your car display is in HTML5 and can be virtualized to any phone or tablet through the browser so you can remote control some functions). It may take a while to get the performance, but that would look really good if I was a car maker

HTML5TEST scores compliance.... Interesting but day to day users care about speed. Unless RIM is ALSO fast, nobody will care. They should focus on improving ALL the benchmarks. Internet Exploder gets abysmal HTML5Test scores but it is still better supported than most web browsers because developers write to it... Plugins also matter and HTML5TEST does little to solve that problem.

Actually, it means that many of the things for which you need "apps" in iOS or Android will just work in the browser in BB10. I am constantly amazed at how many sites work properly on the Playbook, for instance, that don't work properly in Android 4. This is a selling point.

WebWorks is a wrapper that gives the native functionality that can't be achieved just buy using a web site that is hosted on a server. HTML5 is still sandboxed. Not as much has HTML4, but integration with PIM, BBM connect etc? I am not sure how you would accomplish that without a plug in.

Also with the hosted solution, you now run into the browser PITA problem we developers hate. Same application, but hitting windows phone, huh well gotta disable functionality as it is IE 8 which doesn't support HTML5 fully.

Think you give Apple too much credit for predicting the death of flash. Adobe backed off once the W3 community signed off on a standard for the next generation HTML, HTML5. Apple wasn't the only one who had to accept that the way forward was already paved for the next generation HTML standard.

Good write up. But you did not mention the most brilliant part of the Apple appstore and the walled garden approach. No malware. This idea of apps being 100% safe and not needing a virus scanner etc. is very appealing to folks after decades of Windows malware on PCs.

That is incorrect and misleading. I think you misinterpret Apple's wall garden approach. Certainly, unlike Android, there is a greatly reduced risk, but Apple does not review all code for malware. They cannot manage all the apps in the App Store. Having to rely on the App Store does lessen the risk but does not eliminate it. With most folks jailbreaking their iPhones the risk is significantly increased. In fact, the jailbreaking sofware itself could be contaminated, as well as other software that is loaded onto the device.

Unfortunately I have to agree, HTML5 performance on my dev alpha A isn't awesome. Unless you are going all-out raw and writing from scratch, when referring to "HTML5" most people choose to adopt a framework like Sencha Touch or jQueryMobile or bbUI.js. I've tried prototyping my app in all three and the results were "OK" but not silky smooth and responsive like the equivalent Cascades version. Maybe I'm too picky, but annoyances like clicking something then having to click it again, or occasional checkerboxing while scrolling drove me up the wall. Plus I'm not even convinced the alleged "efficiency gains" over native are that great. Often I'd get cooking then suddenly hit a snag and spend a huge portion of my time troubleshooting or hacking around a tiny issue.

Having said that, I actually think RIM's approach is smart since by supporting Adobe Air, Android and best of all C++/Cascades, they aren't betting the farm on HTML5. Eventually the frameworks will mature and the hardware will make performance issues history. I think we're only at the beginning and it will be interesting to see how this ultimately develops.

Not to mention the tools are awesome to work with. I can create apps on my 5+ yr old laptop!

Keep in mind of course, you are limited to the resources you can use, for me (GPS location, local DB) was all I needed, along with the ability to share information with contacts on BBM and text msg...everything possible through HTML5....although I don't know if I will have it all ready by the January deadline.

Plus I can port my app quickly to iOS and Android, and not need to maintain multiple code bases which is going to be a key.

Hrm. As soon as I finished reading this post I went and looked up that exact same interview (Zuck's first since the IPO where he's now (in?)famously quoted as saying:

"I think the biggest mistake that we made as a company is betting too much on HTML5 as opposed to native."

But then he goes on to say that while he thinks the future is headed for HTML5, ("It's not that HTML5 is bad. I'm actually, long-term, really excited about it"), it just isn't there yet in terms of maturity to be able to take greater advantage of it ("We just never were able to get the quality we wanted...")

At least that's my interpretation.

To Umi's point, HTML5 kind of future-proofs RIM, allows them to be prepared if in fact the future is all aboot HTML5.

I think the answer is in the question. Facebook is a company that's large enough to be able to allocate the resources to building a dedicated native app for each platform. Not to mention it is a fairly major app with a lot of functions, as opposed to a mere website portal.

Facebook wasn't able to get it right. Even with their native app they're still not getting it right (considering how buggy the native iOS app is for me).

It's possible to build high performance HTML5 apps but you have to know what you're doing. If you're going to insert inline blocking JS calls all over the place in a pane that needs to scroll smoothly then... yes, it's going to be a stuttery, laggy experience.

I'm personally kind of pissed off at Facebook for their HTML5 screwup because right now a lot of companies have started thinking HTML5 is somehow inferior. It's not. It's just not the cheaper, easier to build than native solution. I'd dare say that building a good HTML5 app is no easier nor cheaper than a good native app.

Facebook in BB10 is HTML5 and gives great performance. Have a look at the demo.

Facebook did HTML5 for Apple.. But everyone knows how that went.. So MarkZ said.. That making HTML5 for Apple was the biggest mistake.. They have no choice but to make native app because of apple html5 performance issues.. Now they keep paying Apple money for the millions of downloads (for which facebook does not get a penny) but because of Apple app store they still have to pay apple.

Zuckermann was proved wrong with FastBook by Sencha. (http://www.sencha.com/blog/the-making-of-fastbook-an-html5-love-story)
when he said
"I think the biggest mistake that we made as a company is betting too much on HTML5 as opposed to native."
But then he goes on to say that while he thinks the FUTURE is headed for HTML5,
("It's NOT that HTML5 is bad. I'm actually, long-term, really excited about it"), it just isn't there yet in terms of maturity to be able to take greater advantage of it
("We just never were able to get the quality we wanted...")
THEY WERE NOT ABLE EVEN THOUGH HTML5 WAS READILY CAPABLE

CrackBerry is in no way Affiliated with BlackBerry. We take pride in our unbiased content, however do occasionally receive free products from vendors that we review or discuss. For more info click here.