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.

HTML5 LogoSo 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.

Advertisements

Tags: , , , ,

Categories: Apps, Mobility, Startups

Author:Jeanne Roué-Taylor

I'm fascinated by disruptive technology and its impact on our world. I manage sales operations for an excellent startup with a unique team of highly experienced data scientists.

Subscribe to the blog

Subscribe and receive an email when new articles are published

11 Comments on “To HTML5 or not to HTML5…that is the question”

  1. November 14, 2012 at 5:04 am #

    Great quote from the Gartner conference. HTM5 is “write once, debug everywhere”, showing that it is still immature, but the view is that it is still the best approach for multi-platform app development.

  2. November 14, 2012 at 7:17 am #

    I completely agree with Ian. QA is a nightmare. However the good thing is that you can get bug fixes out to users quickly and seamlessly. You don’t have to wait for approval from any store and your users don’t have to download any updates. That makes up for the debugging pain.
    Catheryne, MommaZoo CEO and Co-founder

  3. William Stark
    November 14, 2012 at 7:59 am #

    Some great tips here. We already came up with some of those when developing our app but it’s nice to be able to get more from others in the same situation and have all of them in a single place.

  4. Alexis
    November 14, 2012 at 10:24 am #

    Thanks for the exhaustive summary, very helpful. Did you consider frameworks like Phonegap before deciding on HTML5? What’s your opinion?

    • November 14, 2012 at 12:35 pm #

      We did consider PhoneGap and still are. Given that PhoneneGap is mostly a shell and reuses the exact same set of technologies, we would just have to wrap our website. It’s another great advantage of developing for the web.

      The tradeoff here is in the publication medium: simply the web or each of the app stores. So far we’ve avoided the app stores, mostly because it’s a sizable effort. But if we find it could benefit our distribution and how people discover us, we would do it.

      • November 14, 2012 at 1:33 pm #

        First off, let me complement you on this is a well written article explaining the trials and tribulations of building web applications for mobile. Could you elaborate on what you use from the new HTML5 standard? What things, in your opinion, are ready for primetime and general use in other apps? I get the sense you don’t really use any new facilities offered by HTML5. Then why call the article HTML5 or not. It seems it should have been native or not.

      • ZC
        November 15, 2012 at 10:12 am #

        Thanks for these great tips. How are you guys doing the automation testing? Anything interesting you found in that area?

      • November 15, 2012 at 2:18 pm #

        @ZC. I wish there was a way to automate testing. Despite our best efforts to catch all bugs prior to an update, we inevitably find a user with a slight variation of version in browser/OS/platform in which a feature doesn’t work as intended. If anyone in the audience has suggestions on testing or automation, please chime in!

  5. November 15, 2012 at 1:52 pm #

    @reallybradnews We use the docytpe 🙂 More seriously we use a variety of features that are part of the HTML5 specs, like the placeholder attribute, localStorage, the history API, the new forms, etc. To your point and as we say in the post though, what made mobile web apps possible are much more the maturity and performance of the browsers than any single spec. Still, HTML5 brings some nice and very useful additional features.

  6. November 15, 2012 at 10:12 pm #

    Good article. Yes HTML5 – and a little polyfill doesn’t hurt either. I’ve met folks who argue that only native gives you the best experience on mobile – and for a long time that was true. But today that is highly questionable for many applications today. HTML5/JS/CSS3 based applications are becoming indistinguishable from native applications. With multi-core GPU’s optimised for CSS – you get rich smooth graphics on the latest devices. The cost of supporting 3-4 native code lines (iOs, Android, Windows and RIM (yes – in some countries they’re still hanging on…)) should be enough to deter anyone from going native.
    You did not discuss hybrid – which is a good bridge between native and web – if you need to go beyond the HTML5 spec. It’s the best of both worlds – BUT – as with any technology – it has it’s value in certain use cases and those might not suit yours. HTML5 on mobile is still in it’s infancy – but the good news is that mobile adoption is still growing rapidly (Samsung sold 57 million smartphones in Q3 2012) and existing smartphone users tend to refresh devices every couple of years (compared to desktop/XP/IE6 users) so the pace of adoption and increased access should make anyone question any native development work over HTML5.

Trackbacks/Pingbacks

  1. To HTML5 or not to HTML5…that is the question | Successful … | Software Engineering Software - November 16, 2012

    […] Continue reading here: To HTML5 or not to HTML5…that is the question | Successful … […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: