Channels ▼
RSS

Embedded Systems

Overcoming HTML5's Limitations


Today, enterprise developers typically select their development approach from a spectrum that spans from pure native development on one end to pure HTML5 development at the other. Aside from the familiarity of this topic in the current context of the mobile computing explosion, this discussion is surprisingly familiar in a more historical context.

A quick Web search uncovered an article from 1997 contrasting the merits of client-server development using a fat client model vs. pure Web-based development. The article aptly noted that, at the time, there was a spectrum from fat client to Web client, and that applications could exist at different points on that spectrum. The article concluded (correctly, with the benefit of hindsight) that Web development should be the path of choice for enterprise development.

Rather than relearn the lessons of history the hard way (that is, after building a portfolio of native mobile apps), it makes sense to remember why the Web won the enterprise:

  • HTML is an open, cross-platform standard for app development. No similar alternative exists today for cross-platform native mobile app development.
  • Web applications solve a major headache for IT: Upgrades are instant, and IT can be assured that users are always running the latest version of an application. These benefits enable IT to update applications at a much faster pace that meets the dynamic needs of the business.
  • Mobile devices, much like desktops and laptops, are all slightly different. The challenges of hardware fragmentation, variations in behavior across OS versions, and unintended client application interactions are a never-ending challenge in managing a portfolio of fat client applications.

With these benefits in mind, it would seem obvious that HTML5 is the right strategic choice for developing mobile enterprise apps. However, much like the early Web, there are challenges with HTML5 that must be addressed before it is truly enterprise ready.

Overcoming HTML5's Limitations

Whenever HTML5 is suggested as a solution, it encounters these principal objections:

Lack of Features. The main objection to HTML5 development is that the breadth of device features accessible via HTML5 is limited. However, applications that need access to device features outside of the HTML5 standard can bridge that gap with browser plugins. As with desktop browsers, mobile browser plugins are a smaller piece of code that is easily ported across browsers and platforms as needed and can be accessed via JavaScript from within an HTML5 application. Plugins like PhoneGap (now Apache Cordova) successfully bridge the device feature gap with a community-supported project that is maintained across all major device OSs and browser platforms and is easy to extend as needed for a particular application.

Security. Security is and should be of primary concern as enterprises embrace mobility and select a development methodology for mobile apps. Unlike the device feature gap, there is no tidy solution to securing enterprise applications available on laptops and desktops that can be easily migrated to mobile devices. In this case, the migration to mobile presents an opportunity to address security better and more cleanly.

I believe the first line of defense should be separating the browser for the trusted Web from the browser for the untrusted Web. Mobile devices come with the untrusted browser installed already, so the enterprise needs to ensure that enterprise mobile apps are only run in a trusted browser.

Beyond this separation of trusted vs. untrusted browsing, the trusted browser itself must protect the data managed by the browser and the connection to the corporate network used by the browser against infiltration from malware on the device. There is no way to prevent the device from being infected by malware, but it is possible to select a browser that can at least defend against a sophisticated malware attack. (Separately, the enterprise should also be securing the data accessed by the browser, but that is a separate topic.)

Performance. Rounding out the top enterprise objections to HTML5 is the concern that native applications perform better than their HTML5 counterparts. While this is true in general, the more important question is for what category of applications is this performance difference perceptible to an end user? As in the desktop world, real-time and media driven applications (games, video editing, etc.) stress the performance limits of the device. Data-driven applications, which include the vast majority of enterprise applications, do not. While there will always be a niche for native apps, it is just that — a niche that should only be used when the business needs offset the significant cost and complexity of developing, delivering, and supporting native apps.

Selecting an HTML5 Development Platform

If an enterprise chooses to move ahead with HTML5, it is important to avoid pitfalls in choosing technologies for developing mobile apps. The first pitfall is using a hybrid-native approach when deploying mobile HTML5 apps. The second pitfall is relying on proprietary platforms that masquerade as standard HTML5.

While the idea of using native code to bridge the gap between the standardized features of HTML5 and the latest device features available in native development SDKs is a sound one, the hybrid-native approach offered by most vendors implies a deployment scheme that defeats many of the benefits of HTML5 development. Leveraging our historical analogy for a moment, imagine if the browser plugin architecture were instead replaced by a browser packaging architecture back in 1997. Every time a Web application needed a non-standardized feature of HTML or JavaScript, the developer would package the HTML and JavaScript application code with a slightly customized browser used to execute the code. The user would then download a new browser specifically designed to run each such Web application. Sounds ridiculous, doesn't it?

A plugin-enhanced browser is far different from an application that ships with a browser, but the model of hybrid-native packaging today is to ship the browser with the app. Thanks to the offline capabilities of HTML5, there is no reason that a pure HTML5 application cannot deliver the same functionality online and offline as a hybrid-native application. The difference is solely in the associated overhead of delivering, upgrading, and maintaining the app. Along all of these dimensions, a pure HTML5 app is, I believe, a superior choice.

Beyond the deployment challenges of hybrid-native app architectures, many hybrid-native vendors offer a highly proprietary app development platform masquerading as a standards-based HTML5 environment. The benefits of an open, standards-based approach include avoiding vendor lock-in, leveraging the skill-set of developers trained in the enterprise Web, and ensuring that your apps can benefit from the vast array of JavaScript and HTML5 tools available as open source or from third parties. Development methodologies that convert code written in HTML5 or JavaScript to native applications or that package interpreters or virtual machines with the application are inherently vendor-specific regardless of the language in which the application code is written.

Conclusion

Mobility is an opportunity for every enterprise to enable productivity anytime and anywhere. Reaching that goal requires extending the enterprise applications that drive business processes to mobile devices while also developing new applications that leverage the unique capabilities of mobile devices. The benefits of embracing mobility are significant; however, realizing those benefits requires selecting the right app development methodology and supporting technology stack.

Selecting pure HTML5 development as that development method ensures that the lessons (and investments) of 15 years of enterprise Web development are not lost. Choosing a browser technology that addresses the enterprise's requirements for security and performance without compromising on HTML5's benefits ensures a successful and cost-effective strategy for application development and mobilizing the enterprise.


Guest editor Seth Hallem is the Co-Founder and CEO of Mobile Helix.


Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
 

Video