Skip to content

What Business Executives Should Know about HTML5 and Hybrid Technologies

2013 May 20

Hybrid and HTML5 technologies are now the de facto standard for mobile development. We see few enterprises developing large-scale external-facing applications using pure native technologies, primarily because of the flexibility and OS platform reach hybrid provides.

While there are many benefits to hybrid technologies, there are also challenges that surprise many organizations. Furthermore, we have seen many technology organizations minimize the technology risks when pitching the hybrid approach to the business teams. Most of the times these are honest mistakes, but business teams should understand the basics of mobile development to ensure their projects stay on track.

We act as sherpas to both business and technology teams as they execute their mobile strategy – often after helping them build their mobile strategy. In addition we’ve been hard at work developing our own line of mobile products using hybrid technology to fill gaps in the marketplace. We know first hand the many, many pitfalls in developing mission-critical mobile applications – especially in highly regulated industries.

Probe your teams designs and [require good architecture]. The line of business will ultimately be held accountable.

We believe line of business teams should understand the following concepts in order to work more effectively with their technology partners:

  1. What does Hybrid mean?
    In a mobile application context, the term hybrid refers to a pattern of using a mixture of browser and native OS technologies. In practice, most hybrid applications are really web applications wrapped with a native shell that provides limited access to native-app only functionality, including the ability to be deployed to the app store. HTML5 blurs this description by also providing access to native functionality through browsers that until recently was only available to native applications. Cordova (aka PhoneGap) is a critical tool for bridging web and native technologies.
  2. What is HTML5?
    HTML5 is simply the next version of the standard web browser markup language HTML. HTML5 provides standard access to functionality, such as the camera or GPS, that previously was only available to native applications. It’s important to note that HTML5 is a standard specification and not an implementation. Browser makers do the actual implementation and are responsible for deciding how close they’ll follow the spec (if at all) and in what timeframe to implement the features. There are entire web sites devoted to tracking HTML5 functionality in browsers. http://caniuse.com is one example.
  3. Hybrid projects are not necessarily faster – initial time to market might be slower
    Almost by definition, hybrid projects target more than one OS and therefore become more complex. Many organizations erroneously think the task will be easier because hybrid uses familiar web technologies like JavaScript, CSS and HTML. However, learning the syntax isn’t the hard part. Understanding how that syntax behaves in new environments and how users change their behavior in the new environments requires a learning curve. Furthermore, that familiar syntax is indirectly interacting with native technologies which means developers may have less fine-grained control of processes they don’t fully understand. Add in the truly terrible debugging visibility (see #6 below) and you could find yourself in a mess.
  4. Thorough testing remains vitally important and hybrid doesn’t reduce the impact on testing
    Remember that each browser version on each version of  each OS actually does the work of executing your hybrid code. In theory they all follow the standard, but not always. Sometimes it’s a bug and sometimes it’s a conscious decision. Hybrid doesn’t change your test plan much. You need a thorough testing strategy for validating your functionality in general, then validating across OS and browser version combinations as well as with variations of signal strength, online and offline modes, and so on.
  5. Performance is almost certainly slower with hybrid
    By definition you’re adding at least one more layer of software above actual processor execution. In practice you’re often adding many more layers and reducing your control and visibility significantly. You have to be really good – and sometimes lucky – to approach the performance of native technology with hybrid applications. The key is to accept this and use hybrid technology where performance isn’t an issue and native technology where performance is critical – while balancing your need for a cross-platform code base.
  6. Debugging is awful with hybrid. Simply awful.
    The good news is that debugging is much better than it used to be. Chrome and Firefox browsers have good JavaScript, HTML and CSS debuggers. Apple has added JavaScript DOM viewing capabilities in the Mac version of Safari that enables seeing the details of an attached iOS device such as an iPhone or iPad. There are also other great niche tools like JSConsole that are indispensable. However, you cannot get the same debugging visibility of JavaScript code running as an app on a native OS. Oftentimes even old-fashioned print statements to the console don’t work well leaving you blind as a bat wasting hours or days on a stupid missing quote character syntax mistake that would have taken twenty seconds with compiled code like Java or Objective C. The technology and techniques will certainly improve, but beware for now. This means bugs will get fixed slower, estimates will be less precise, and projects will take longer than expected.
  7. Great software design is even more important with hybrid
    Software design skills are critical when you’re trying to cover many operating systems with one code base (possibly including targets that don’t even exist yet), while working with more blunt tools. Hybrid app architects must thoroughly understand where each native technology varies from the common approach and plan for it to change over time as the project evolves. Furthermore, performance considerations will almost necessarily change some of the application flow as the final app is tuned and bottlenecks are removed.
  8. Server side components are critical with hybrid and are often overlooked until it’s too late
    For some reason, mobile developers underestimate the need for “mobile application server” components. I’ve been debating this with developers since 2007 in the early mobile banking days. I continue to see teams dash ahead building an app without a mobile-specific server-side component built-in and they ultimately end up building a mobile application server themselves bit-by-bit as they discover they need functionality. Unless you’re an application server company, this is probably a huge waste of your resources and your time to market is delayed significantly. Many developers will delight in getting to build that infrastructure. Probe your teams designs and prevent this from happening. The line of business will ultimately be held accountable.
  9. Hybrid requires deep understanding of all your underlying mobile operating systems – don’t choose it so your technology team doesn’t have to learn each OS
    Historically, hybrid and HTML5 technology has been chosen because “the teams don’t need to learn new technology.” While hybrid has many benefits, your teams must understand the nuance of how the underlying operating systems work to be successful. Successful hybrid applications that do anything innovative, require digging into the native components. Often projects require extending existing native functionality by writing a Cordova extension, for example, that implements native OS functionality on each platform using a single JavaScript API call. Teams that choose hybrid because they don’t know native, will end up learning native technologies under duress and ultimately time-to-market and software quality will suffer.
  10. Don’t compromise on a stunning user experience
    Last but definitely not least, your user experience will make your app a success or failure. The unspoken truth is that hybrid is often chosen out of developer laziness and the user suffers. Developer laziness isn’t necessarily a bad thing in that it often creates productivity improvements and innovation. However, the business team must unceasingly be the voice of the user. It is difficult to provide the same level of usability and performance with hybrid as with targeted pure-native technologies, but it is possible. The team has to design for an amazing UX and the testers and project sponsors must insist that developers continue to find ways to delight the user when faced with technical roadblocks. They will be tempted repeatedly.
Be Sociable, Share!
No comments yet

Leave a Reply

Note: You can use basic XHTML in your comments. Your email address will never be published.

Subscribe to this comment feed via RSS