HTML5 ist nicht mehr nur ein Konferenz-Buzzword. Dieses Jahr haben wir es zum ersten Mal in einer produktiven Unternehmensumgebung eingesetzt — eine interne Anwendung für die Verwaltung von Versicherungsschäden. Keine Plugins, kein Flash, kein Silverlight. Reines Web. Und es funktioniert überraschend gut.
Warum gerade jetzt?¶
Vor zwei Jahren hätte es keinen Sinn ergeben. Internet Explorer 8 war der Unternehmensstandard und die HTML5-Unterstützung darin war praktisch nicht vorhanden. Doch 2012 hat sich die Situation dramatisch verändert. IE9 und IE10 liefern solide HTML5-Feature-Unterstützung, Chrome und Firefox aktualisieren sich automatisch, und mobile Browser sind noch besser aufgestellt.
Unser Kunde hatte zudem einen spezifischen Grund: Er wollte, dass die Anwendung auf iPads funktioniert, die das Management zu nutzen begonnen hatte. Und das iPad hat kein Flash. Das bedeutete entweder die Benutzeroberfläche umschreiben oder in der Vergangenheit verharren. Die Wahl war klar.
Canvas für Datenvisualisierung¶
Einer der größten Gewinne mit HTML5 ist das <canvas>-Element. Zuvor nutzten wir Flash-basierte Bibliotheken für Diagramme und Visualisierungen (FusionCharts) oder generierten Bilder auf dem Server. Beide Ansätze hatten erhebliche Nachteile — Flash erforderte ein Plugin und serverseitiges Rendering war langsam.
Wir wechselten zur JavaScript-Bibliothek Highcharts, die direkt in Canvas rendert (mit SVG-Fallback). Ein Dashboard mit 15 Diagrammen rendert in 200 ms statt der bisherigen 3 Sekunden. Interaktivität — Zoom, Tooltip, Drill-down — funktioniert flüssig ohne eine einzige Serveranfrage.
Web Storage statt Cookies¶
Enterprise-Anwendungen müssen typischerweise Zustände auf der Client-Seite speichern — Dashboard-Layouts, Filter, zuletzt geöffnete Datensätze. Früher wurde dies mit Cookies gelöst (4 KB Limit, wird mit jeder Anfrage gesendet) oder serverseitigen Sessions (Serverlast, Load-Balancing-Komplikationen).
HTML5 Web Storage (localStorage) bietet 5–10 MB Speicherplatz direkt im Browser. Benutzereinstellungen laden sofort, ohne Roundtrip zum Server. Und sessionStorage ist ideal für temporäre Daten, die das Schließen des Tabs nicht überleben sollen.
In unserer Anwendung speichern wir die komplette Dashboard-Konfiguration, den Suchverlauf und Formularentwürfe in localStorage. Der Benutzer kann den Browser schließen, am nächsten Tag wiederkommen und genau dort weitermachen, wo er aufgehört hat.
Offline-Modus mit Application Cache¶
Das war ein Game-Changer für unsere Schadenregulierer im Außendienst. Versicherungsvertreter fahren zum Schadenort, oft mit unzuverlässiger Verbindung. Mit HTML5 Application Cache (einer Manifest-Datei) lädt die Anwendung die notwendigen Assets und Daten herunter und funktioniert auch offline.
Die Implementierung ist nicht trivial — man muss das Manifest sorgfältig verwalten, die Cache-Invalidierung handhaben und Daten synchronisieren, wenn die Verbindung wiederhergestellt wird. Aber das Ergebnis lohnt sich: Vertreter füllen ein Formular im Feld aus, und die Daten werden automatisch synchronisiert, sobald ein Signal vorhanden ist.
Formulare und Validierung¶
HTML5 führt neue Input-Typen ein — date, email, number, tel, url. Auf mobilen Geräten erscheint automatisch die richtige Tastatur (numerisch für Telefonnummern, @-Tastatur für E-Mail). Auf dem Desktop validiert der Browser das Format ohne eine einzige Zeile JavaScript.
Natürlich reicht die native Validierung für eine Enterprise-Anwendung nicht aus. Wir haben eine eigene JavaScript-Validierungsschicht hinzugefügt (jQuery Validation), aber HTML5-Attribute wie required, pattern und min/max dienen als erste Verteidigungslinie. Und es ist natürlicher für Benutzer — Fehlermeldungen erscheinen direkt neben dem Feld, nicht als Alert-Box.
WebSocket für Echtzeit-Benachrichtigungen¶
Versicherungsschäden haben einen Workflow — Meldung, Zuweisung, Untersuchung, Regulierung, Abschluss. Wenn sich der Status ändert, müssen andere Benutzer sofort davon erfahren, nicht erst nach einem Seitenneuladen.
Zuvor verwendeten wir Polling (eine AJAX-Anfrage alle 30 Sekunden). Mit WebSocket haben wir eine persistente Verbindung und der Server sendet Benachrichtigungen in Echtzeit. Die Latenz sank von 30 Sekunden auf unter 100 ms, und die Serverlast nahm paradoxerweise ab, weil Tausende unnötiger Polling-Anfragen entfielen.
Was uns (negativ) überrascht hat¶
Nicht alles ist rosig. Cross-Browser-Kompatibilität bleibt schmerzhaft. IE9 unterstützt zwar Canvas und Web Storage, aber nicht WebSocket. Wir mussten SockJS als Fallback verwenden (Long-Polling für ältere Browser).
Performance auf älterer Hardware ist ein weiteres Problem. Client-Computer in Unternehmen sind keine Gaming-Maschinen. Eine JavaScript-lastige Anwendung auf einem Core 2 Duo mit 2 GB RAM und IE9 ist nicht gerade flink. Wir mussten intensiv optimieren — Lazy Loading, Virtualisierung langer Listen, Minimierung von DOM-Manipulationen.
Welches Framework?¶
2012 ist die Auswahl an JavaScript-Frameworks… interessant. jQuery ist gesetzt. Für die Anwendungsstruktur wählten wir Backbone.js — leichtgewichtig, genau richtig meinungsstark, mit guter Dokumentation. Knockout.js war der zweite Kandidat (MVVM-Pattern, Two-Way-Binding), aber letztlich bevorzugten wir die Einfachheit von Backbone.
Angular von Google steht am Horizont, aber es ist zu frisch für den Enterprise-Einsatz. In ein bis zwei Jahren schauen wir es uns wieder an.
Zusammenfassung¶
HTML5 im Enterprise funktioniert — wenn man weiß, wo die Grenzen liegen. Entscheidend ist, auf echter Unternehmens-Hardware zu testen, Fallbacks für ältere Browser bereitzuhalten und Offline-Szenarien nicht zu unterschätzen. Die Ära der Plugins geht zu Ende. Das Web als Plattform für Geschäftsanwendungen ist da.
Brauchen Sie Hilfe bei der Implementierung?
Unsere Experten helfen Ihnen bei Design, Implementierung und Betrieb. Von der Architektur bis zur Produktion.
Kontaktieren Sie uns