HTML5 in Enterprise Web Applications

HTML5 is no longer just a conference buzzword. This year we deployed it for the first time in a production enterprise environment — an internal application for managing insurance claims. No plugins, no Flash, no Silverlight. Pure web. And it works surprisingly well.

Why Now?¶

Two years ago it wouldn’t have made sense. Internet Explorer 8 was the corporate standard and HTML5 support in it was practically nonexistent. But in 2012 the situation changed dramatically. IE9 and IE10 deliver solid HTML5 feature support, Chrome and Firefox auto-update, and mobile browsers are even better.

Our client also had a specific reason: they wanted the application to work on iPads, which management had started using. And the iPad has no Flash. That meant either rewriting the UI or staying in the past. The choice was clear.

Canvas for Data Visualization¶

One of the biggest wins with HTML5 is the <canvas> element. Previously, we used Flash-based libraries for charts and visualizations (FusionCharts) or generated images on the server. Both approaches had major drawbacks — Flash required a plugin and server-side rendering was slow.

We switched to the JavaScript library Highcharts, which renders directly into Canvas (with an SVG fallback). A dashboard with 15 charts renders in 200 ms instead of the previous 3 seconds. Interactivity — zoom, tooltip, drill-down — works smoothly without a single server request.

Web Storage Instead of Cookies¶

Enterprise applications typically need to store state on the client side — dashboard layouts, filters, recently opened records. Previously this was done with cookies (4 KB limit, sent with every request) or server-side session (server load, load-balancing complications).

HTML5 Web Storage (localStorage) offers 5–10 MB of storage directly in the browser. User preferences load instantly, without a roundtrip to the server. And sessionStorage is ideal for temporary data that shouldn’t survive closing the tab.

In our application we store the complete dashboard configuration, search history, and form drafts in localStorage. The user can close the browser, come back the next day, and pick up exactly where they left off.

Offline Mode with Application Cache¶

This was a game-changer for our field claims adjusters. Insurance agents travel to the site of a claim, often with unreliable connectivity. With HTML5 Application Cache (a manifest file), the application downloads the necessary assets and data and works even offline.

The implementation isn’t trivial — you need to carefully manage the manifest, handle cache invalidation, and synchronize data when the connection is restored. But the result is worth it: agents fill out a form in the field, and the data syncs automatically once there’s a signal.

Forms and Validation¶

HTML5 introduces new input types — date, email, number, tel, url. On mobile devices the correct keyboard automatically appears (numeric for phone numbers, @ keyboard for email). On desktop, the browser validates the format without a single line of JavaScript.

Of course, native validation is not enough for an enterprise application. We added a custom JavaScript validation layer (jQuery Validation), but HTML5 attributes like required, pattern, and min/max serve as the first line of defense. And it’s more natural for users — error messages appear right next to the field, not as an alert box.

WebSocket for Real-Time Notifications¶

Insurance claims have a workflow — filing, assignment, investigation, settlement, closure. When the status changes, other users need to know about it immediately, not after a page refresh.

Previously we used polling (an AJAX request every 30 seconds). With WebSocket we have a persistent connection and the server pushes notifications in real time. Latency dropped from 30 seconds to under 100 ms, and server load paradoxically decreased because thousands of unnecessary polling requests were eliminated.

What Surprised Us (Negatively)¶

Not everything is rosy. Cross-browser compatibility remains painful. IE9 does support Canvas and Web Storage, but not WebSocket. We had to use SockJS as a fallback (long-polling for older browsers).

Performance on older hardware is another issue. Client computers in corporations are not gaming machines. A JavaScript-heavy application on a Core 2 Duo with 2 GB RAM and IE9 is not exactly snappy. We had to optimize heavily — lazy loading, virtualizing long lists, minimizing DOM manipulation.

Which Framework?¶

In 2012, the choice of JavaScript frameworks is… interesting. jQuery is a given. For application structure we chose Backbone.js — lightweight, just opinionated enough, with good documentation. Knockout.js was the second candidate (MVVM pattern, two-way binding), but in the end we preferred Backbone’s simplicity.

Angular from Google is on the horizon, but it’s too fresh for enterprise deployment. We’ll revisit it in a year or two.

Summary¶

HTML5 in enterprise works — if you know where the limits are. The key is to test on real corporate hardware, have fallbacks for older browsers, and not underestimate offline scenarios. The era of plugins is ending. The web as a platform for business applications is here.