To HTML5 or not to HTML5…that is the question

The following is a guest post by Catheryne Nicholson, Co-Founder and CEO at MommaZoo, a “village of help for school parents” startup in the Bay Area. MommaZoo provides a local parent network to discover and share help in transporting, caring, and educating kids. Between her multiple jobs and motherhood, she’s always multi-tasking. Back when she had the luxury to concentrate on single tasks, she built energy and emissions management, CRM, and defense software for C3, Siebel Systems, and Northrop-Grumman. She holds a Bachelor of Science in Aerospace Engineering, a Master of Science in Environmental Engineering, an MBA and is a registered Professional Engineer in Mechanical Engineering.

We knew from the start that we wanted MommaZoo to be accessible from as many devices as possible and have the widest reach possible. We wanted parents to use it on their phone while on the go, for example inviting others to join them at the playground. But also make longer forms of communication possible, like class newsletters.

So while MommaZoo’s primary platform is mobile, which nowadays mostly means iOS and Android, we also wanted to be available to laptops and desktops. We didn’t want to bet on a single proprietary platform. Allowing access from as many places and computing devices as possible motivated our choice of the web platform and developing with HTML5.

So should you develop in HTML5 or native?

Well, it depends.

HTML5 in and of itself doesn’t necessarily mean much. HTML5 is a standard still under development. It’s a set of specifications at various levels of development and support. Strictly speaking, a web page can be made HTML5 by changing one line in it. So writing an HTML5 app is mainly writing against parts of a new set of specifications that form the more modern parts of the web platform.

When building for mobile, the good news is that most mobile browsers are fairly recent and actively developed. When building on the web platform, the bad news is you still have to support old browsers. IE6, one of the worst browsers still in use, is almost dead. But IE8 isn’t much better. Thankfully, obsolescence happens faster on mobile (more on that later). In MommaZoo, we’ve mitigated some of the cost of supporting inadequate browsers by using the Chrome Frame for older versions of IE. We also don’t support the oldest Android versions.

A common question is whether HTML5 is mature enough. In most cases, you just need to know about the support across browsers to know. There are many resources to help you.

But more than anything else, Javascript performance is what made HTML5 possible (before version 5, HTML specifications limited themselves to markup while it now includes Javascript APIs). Browsers are in fierce competition to be the fastest Javascript engine on the planet and a lot of developer resources are spent on it. It’s what made most rich web applications you’re using today possible.

Overall, the platform is mature enough. Most Javascript runtimes are really good. A reasonable subset of the HTML5 specifications are finalized, well-supported and well-tested. The community is large and active. But as for any platform, it doesn’t mean there aren’t sharp corners when you get close to the edges. Just try to identify those early, assess whether you can stay away or how much bleeding it could cause.

For MommaZoo, by targeting the web platform, our cost of development can be kept reasonable while still maintaining a very wide reach. Our parent demographics require it. MommaZoo hasn’t been developed without pains however, and I’ll get into those difficulties and how to alleviate them in the next section.

Building for mobile on the web platform and HTML5 has a lot of advantages. This doesn’t mean that it’s easy or for everyone. The application has to be a good fit both in terms of visual complexity and of how much data it needs to load. I’m going to outline some of the portability and performance challenges we’ve faced and how we’ve alleviated them.

Portability

After the first 2 weeks of development I thought, “Oh, this looks easy: develop on the desktop and just check how it looks on mobile once in a while.” Until we started testing the broad spectrum of mobile devices our users have.

Mobile browsers have all sorts of quirks and you’ll quickly learn to hate them with a passion. The worse of all is probably the Android browser: We have all sorts of conditions in our code to handle it differently. Reload timing is different, parts of rendering are deferred for some reason, and it doesn’t even support animated gifs (are we in the 1990s?).

Mobile Safari is not much better. It seems to change opinions on what to do about cookies and local storage every other version. Apple is ‘really big’ on user experience and forcing people to retype their password every time is both user-friendly and secure (not). It also behaves differently if you open the site in mobile Safari or through a home shortcut because it relies on a different runtime. I could go on and on and on…

On the testing side, everything could work perfectly. Until you try one more device. Both devices are on Froyo so they should behave the same you say? Not necessarily. Mobile vendors like to use different snapshots version of Android. And what’s the minor version or your iOS device? Testing can therefore become very expensive as you have to test everything on as many devices as possible and automation across all of those is impossible.

Now, the positives

First, things are getting better. Fundamentally, mobile browsers are maturing at a very fast clip. What I’ve seen of Jelly Beans is very good so far and Chrome Mobile is consistent with the desktop version. Mobile Safari is also improving and the kinks are disappearing gradually. iOS 6 offers many interesting new functionalities for web development.

Second, and contrary to what I’ve read here and there, I’m very hopeful of the pace of obsolescence for older devices. Almost everyone gets a new phone after the end of their one or two years contract and the latest modern mobile browser comes with it. Tablets may change that a little, but so far Apple seems determined to not let people keep them for too long.

Performance

Mobile performance can be tough, users expect fast response times: more than 5s and you’ve lost. Yet you have to operate over lousy networks with bad reception. For example, the first school that has been using MommaZoo is tucked between 2 hills, making for very bad reception quality. Users don’t take that into consideration (and who can blame them). If it’s slow, your application will not be used.

So the three basic tenets of mobile performance are:

• Make as few requests as possible- Tests have shown over and over that mobile latency can be really high. The edge network for example has a latency ranging from 150ms to 500ms. I’ll let you do the math with 20 requests.
  • Minify all your Javascript.
  • Prefer bigger files over a lot of small files. Merge your Javascript files and CSS files in just 2 big files. Except if they’re over 100k.
  • Sprites. Really. Just count the images on your page, you’ll see.
  • If you have a single page web app with XHRs loading content, don’t do that for your first page load. Render it as much as possible on the server (templates, backbone.js inlined collections).
• Make small requests
  • Gzip everything.
  • Use few and small libraries. Forget jquery, use Zepto.js or similar. Consider the cost of everything you use.
  • Trim down the data returned by your XHRs as much as possible. Your server should always return exactly what’s needed, nothing more.
• Do your cache homework - The HTTP protocol has many caching options built-in. You need to know all of them as different resources will require different cache policies.
  • Images should be cached for a long time. If you change them, just use a different name.
  • CSS or Javascript files should rely on If-Modified-Since and your server should return a 304 when they haven’t changed. You still pay the latency price but remember, you should have a single CSS and a single JS file.
  • XHR data should either not be cached or use etags.
• Cheat(yes, that’s the 4th point, that’s what cheating is about)
  • Execute requests while the user is just looking at the page. The best time is right after another request completed.
  • When using external APIs like maps or analytics, always use the async versions.

We’ve seen dramatic improvements using most of those techniques (in the order of 5x to 10x). But we’re not done yet, performance work is never ending. We have several ideas to reduce our load times even further, like caching slow changing data in the browser’s local storage and only ask for deltas from the server. The application cache is also interesting even though it comes with headaches.

Conclusion

All things considered, I’m very happy with our decision to target the mobile web. It may not work for everyone: if your UI is very involved and graphics intensive, you may want to evaluate your options a little more. Native development – if you’re targeting PCs (and you Mac users, are PC users despite what the Apple ads say), iOS and Android – is signing up for very high development costs. The web platform, even with its growing pains, is allowing us to stay small and nimble and for a startup like MommaZoo, it makes all the difference.