TL;DR: Romantische Vorstellung eines alternativen Browserkonzepts für die einfache aber dezidierte Umsetzung mächtiger Geschäftsanwendung; aktuell ohne bedienbaren Prototypen.
Bei diesem Thread schwebt mir vor allem vor, eure Meinung zu diesem Thema zu hören. Positive und negative Rückmeldung sind sehr willkommen.
Mich zwickt dieses Thema eigentlich schon seit Jahren. Ich entwickle aktuell vor allem Backoffice-Applikationen, die möglichst effizient in der Nutzung und gleichzeitig leicht aktualisierbar sein sollen. Bislang stellt der Webbrowser das Fundament solcher Applikationen dar. Ich hoffe, ich muss hier keinem erst erklären, warum ich keine Desktopanwendungen auf Basis von Swing, WinForms/WPF oder Qt/Gkt schreibe.
Was ist eine Backoffice-Anwendung?
Unter diesem Begriff fasse ich alles zusammen, was einem eingeschränkten Nutzerkreis zur Verfügung gestellt werden soll, damit hier Daten erstellt, gepflegt und überwacht werden können. In der Regel benötigt ein User einen Account mit Zugangsdaten und gff. einem Set von Rechten. Beispiele für solche Anwendungen sind SugarCRM, Magento (Admin), Piwik, Horde, Plesk und die vielen Apps, die Unternehmen intern einsetzen, um vom Standard abweichende Aufgaben zu erledigen. Auch zu nennen sind die Händlerbezogenen-Verwaltungsseiten von PayPal, Ebay, Amazon etc.
Man könnte hier sicher noch viel mehr Anwendungen aufzählen, jedoch sind die Möglichkeiten von HTML(5)-basierten WebApps beschränkt, weswegen es noch einen sehr aktiven Markt für normale Desktop-Anwendungen gibt. Da wird meiner Ansicht nach HTML5 auch nicht viel dran ändern, schaut man auf:
Der traditionelle Webbrowser (aktuell auf Basis von HTML5) ist für diesen Einsatzzweck nicht ausgelegt und wird sich auch in absehbarer Zeit nie richtig für diese Art von Tools anfühlen. Die Probleme liegen dabei auf der Hand:
Javascript ist keine geeignete Plattform, um ernsthafte Applikationen zu bauen. Sicher gibt es genug Beispiele, die beweisen, dass es geht. Aber im Ernst: Es ist leicht sich hier etwas besseres vorzustellen.
Auch wenn es hier Tools wie TypeScript, Coffeescript und Haxe gibt, wird Javascript nie als Basis für Webapplikationen jedes erdenkliche Problem lösen können. Zumal der Webbrowser auf Grund von z.B. ständig präsenten Gefahren nie so viele Möglichkeiten zulassen kann, wie ein Entwickler bei traditionellen Desktopanwendungen hat:
Desktopanwendungen geraten aber immer mehr ins Abseits. Die einfache Verfügbarmachung einer WebApp und den niedrigen Kosten für den Betrieb des Servers und der (theoretisch nur noch mit einem Browser ausgestatteten Clients), sowie die sehr leichte Einführung von Updates, sind für Unternehmen sehr interessante Argumente.
Sicher ist jetzt jedem klar, worauf das jetzt hinausläuft. Ich bin auch nicht der erste, der sich mal mit dem Gedanken befasst hat, wie hier eine Alternative aussehen könnte. Und zugegeben: Dieses Vorhaben ist sehr Umfangreich – wenn auch bei Weitem nicht so umfangreich wie einen weiteren HTML5-Kompatiblem Webbrowser zu schreiben.
Die Idee ist eigentlich simpel. Auf Basis von einer Beschreibungssprache wie XML und einer neuen, die den Einsatzzweck besser ausgelegten Sprache als Ersatz für JavaScript, soll ein Browser entstehen, der Ideal ist, um damit Geschäftsanwendungen umzusetzen. Dabei soll diese Anwendung jedoch nicht ausschliesslich auf einem Client-Device ausgeführt werden, sondern soll vor allem eine mehrbenutzer-fähige Server-Komponente bekommen, die den eigentlichen Betrieb der jeweiligen Anwendung übernimmt. Man kann sich das so vorstellen, dass man einen Client hat, der fast nur Befehle bekommt, wie und was angezeigt werden soll (für die, die das Prinzip kennen: X-Window-System). Startet man eine Anwendung, muss man zunächst eine Adresse angeben, auf der die gegenseitige Serverkomponente des Browsers auf eine Verbindung wartet. Dort geschieht dann das, was heute im Allgemeinen im HTML-Browser des Clients passiert: Eine dynamische Sprache wie Javascript treibt eine Anwendung an, die analog im HTML-Browser durch HTML und CSS dargestellt werden würde. Die Anwendung läuft serverseitig ständig und überlebt auch ansichtsändernde Vorgänge auf Client-Seite. Wird der Client geschlossen (zum Beispiel weil das anzeigende Device ausgeschaltet wird, oder Strom verliert), dann läuft die gestartete Anwendung auf dem Server solange weiter, wie noch ausstehende Aufgaben laufen. Danach (oder nach Ablauf einer Frist) wird die Anwendung beendet.
Das primäre Ziel ist es, mit so wenig Aufwand wie möglich das zu tun, was am naheliegendsten ist und sich mit Mitteln eines HTML-basierten Webbrowsers nur schwerlich umsetzen lässt: Anwendungen, die Entwicklern nahezu den gleichen Möglichkeiten bieten, wie herkömmliche Desktop-Anwendungen und Anwendern (bzw. Sachbearbeitern) eine sehr zugängliche GUI zum schnellen Abarbeiten von Aufgaben zur Verfügung stellen. Folgende Features sind meiner Ansicht nach dafür sinnvoll:
Viele der aufgezählten Features sind auch mit normalen Webbrowsern möglich - das ist mir bewusst. Es geht vor allem um die effektive Bereitstellung neuer Geschäftsanwendungen. Als Faustregel soll gelten: Es soll so einfach sein mit dem Businessbrowser datengetriebene Businessapplikationen zu erstellen, wie es mit HTML möglich ist, eine einfache Webseite zu erstellen. Eine komplexe ansprechende Webseite mit dem Businessbrowser zu erstellen ist so umständlich, wie eine flexible datengetriebene Businessapplikation mit HTML und Javascript umzusetzen.
Ich könnte dazu jetzt noch ewig viel schreiben, aber ich denke, das wäre hier jetzt kontraproduktiv. Könnt ihr euch vorstellen, dass so eine Entwicklung Sinn macht?
Bei diesem Thread schwebt mir vor allem vor, eure Meinung zu diesem Thema zu hören. Positive und negative Rückmeldung sind sehr willkommen.
Mich zwickt dieses Thema eigentlich schon seit Jahren. Ich entwickle aktuell vor allem Backoffice-Applikationen, die möglichst effizient in der Nutzung und gleichzeitig leicht aktualisierbar sein sollen. Bislang stellt der Webbrowser das Fundament solcher Applikationen dar. Ich hoffe, ich muss hier keinem erst erklären, warum ich keine Desktopanwendungen auf Basis von Swing, WinForms/WPF oder Qt/Gkt schreibe.
Was ist eine Backoffice-Anwendung?
Unter diesem Begriff fasse ich alles zusammen, was einem eingeschränkten Nutzerkreis zur Verfügung gestellt werden soll, damit hier Daten erstellt, gepflegt und überwacht werden können. In der Regel benötigt ein User einen Account mit Zugangsdaten und gff. einem Set von Rechten. Beispiele für solche Anwendungen sind SugarCRM, Magento (Admin), Piwik, Horde, Plesk und die vielen Apps, die Unternehmen intern einsetzen, um vom Standard abweichende Aufgaben zu erledigen. Auch zu nennen sind die Händlerbezogenen-Verwaltungsseiten von PayPal, Ebay, Amazon etc.
Man könnte hier sicher noch viel mehr Anwendungen aufzählen, jedoch sind die Möglichkeiten von HTML(5)-basierten WebApps beschränkt, weswegen es noch einen sehr aktiven Markt für normale Desktop-Anwendungen gibt. Da wird meiner Ansicht nach HTML5 auch nicht viel dran ändern, schaut man auf:
- SAP/GUI (hier gibt es jetzt auch einen Webclient, der ist aber mies)
- MS-Access
- beinahe sämtliche Warenwirtschaftssysteme
- beliebige Konfigurationstools
- etc
Der traditionelle Webbrowser (aktuell auf Basis von HTML5) ist für diesen Einsatzzweck nicht ausgelegt und wird sich auch in absehbarer Zeit nie richtig für diese Art von Tools anfühlen. Die Probleme liegen dabei auf der Hand:
Javascript ist keine geeignete Plattform, um ernsthafte Applikationen zu bauen. Sicher gibt es genug Beispiele, die beweisen, dass es geht. Aber im Ernst: Es ist leicht sich hier etwas besseres vorzustellen.
Auch wenn es hier Tools wie TypeScript, Coffeescript und Haxe gibt, wird Javascript nie als Basis für Webapplikationen jedes erdenkliche Problem lösen können. Zumal der Webbrowser auf Grund von z.B. ständig präsenten Gefahren nie so viele Möglichkeiten zulassen kann, wie ein Entwickler bei traditionellen Desktopanwendungen hat:
- Zugriff auf Systemfunktionen
- Fenster mit vielen Optionen (Modal, Toolbox)
- Layouting (Anchor-Layout, XY-Layout)
- Reiche Komponenten (Grids, Inputs für fast jegliche Art von Datentyp, viel Kontrolle)
- Aufbau und Laufzeit der Anwendung belasten einen Server theoretisch nur minimal
Desktopanwendungen geraten aber immer mehr ins Abseits. Die einfache Verfügbarmachung einer WebApp und den niedrigen Kosten für den Betrieb des Servers und der (theoretisch nur noch mit einem Browser ausgestatteten Clients), sowie die sehr leichte Einführung von Updates, sind für Unternehmen sehr interessante Argumente.
Sicher ist jetzt jedem klar, worauf das jetzt hinausläuft. Ich bin auch nicht der erste, der sich mal mit dem Gedanken befasst hat, wie hier eine Alternative aussehen könnte. Und zugegeben: Dieses Vorhaben ist sehr Umfangreich – wenn auch bei Weitem nicht so umfangreich wie einen weiteren HTML5-Kompatiblem Webbrowser zu schreiben.
Die Idee ist eigentlich simpel. Auf Basis von einer Beschreibungssprache wie XML und einer neuen, die den Einsatzzweck besser ausgelegten Sprache als Ersatz für JavaScript, soll ein Browser entstehen, der Ideal ist, um damit Geschäftsanwendungen umzusetzen. Dabei soll diese Anwendung jedoch nicht ausschliesslich auf einem Client-Device ausgeführt werden, sondern soll vor allem eine mehrbenutzer-fähige Server-Komponente bekommen, die den eigentlichen Betrieb der jeweiligen Anwendung übernimmt. Man kann sich das so vorstellen, dass man einen Client hat, der fast nur Befehle bekommt, wie und was angezeigt werden soll (für die, die das Prinzip kennen: X-Window-System). Startet man eine Anwendung, muss man zunächst eine Adresse angeben, auf der die gegenseitige Serverkomponente des Browsers auf eine Verbindung wartet. Dort geschieht dann das, was heute im Allgemeinen im HTML-Browser des Clients passiert: Eine dynamische Sprache wie Javascript treibt eine Anwendung an, die analog im HTML-Browser durch HTML und CSS dargestellt werden würde. Die Anwendung läuft serverseitig ständig und überlebt auch ansichtsändernde Vorgänge auf Client-Seite. Wird der Client geschlossen (zum Beispiel weil das anzeigende Device ausgeschaltet wird, oder Strom verliert), dann läuft die gestartete Anwendung auf dem Server solange weiter, wie noch ausstehende Aufgaben laufen. Danach (oder nach Ablauf einer Frist) wird die Anwendung beendet.
Das primäre Ziel ist es, mit so wenig Aufwand wie möglich das zu tun, was am naheliegendsten ist und sich mit Mitteln eines HTML-basierten Webbrowsers nur schwerlich umsetzen lässt: Anwendungen, die Entwicklern nahezu den gleichen Möglichkeiten bieten, wie herkömmliche Desktop-Anwendungen und Anwendern (bzw. Sachbearbeitern) eine sehr zugängliche GUI zum schnellen Abarbeiten von Aufgaben zur Verfügung stellen. Folgende Features sind meiner Ansicht nach dafür sinnvoll:
- Ein Teil der Business-Logik wird in den serverseitigen Part des Geschäftsbrowsers verlagert. Das entspricht dem Vorgehen vieler SinglePage-Anwendungen im JS/HTML-Bereich (ExtJS, AngularJS, EmberJS, Backbone etc), wobei die Anwendung hier Clientseitig läuft. Dieses Prinzip ist entfernt vergleichbar mit dem von Vaadin.
- Dinge, die man in der Geschäftswelt oft benötigt, werden schon mitgeliefert:
- Grid (mit Filtermöglichkeiten, Sortierung und ggf. Pivotfunktionalität)
- eine reiche Palette an Input-Feldern für beliebige Datentypen (Verhalten und Darstellung anpassbar)
- Layouts
- Value-Binding mit Live-Updatefunktionalität (vgl. AngularJS)
- Möglichkeit, Elemente für den Verlauf einer Hintergrundaktion leicht zu blockieren.
- etc
- Mächtige Möglichkeiten, eigene Eingabeelemente zu erstellen.
- Wörterbücher mit gebräuchlichen, multilingualen Phrasen, die häufig immer wieder so zum Einsatz kommen (vgl. Iconfonts für sprachunabhängige Symbolik)
- Einbindung in die Geschäftsumgebung: LDAP/SSO, Drucker, (eingeschränkter) Zugriff auf das lokale Dateisystem, Zugriff auf das Intranet
- Zwischenspeicher: SQL-Ähnliche Puffer-Datenbank, die sich bei Bedarf automatisch neue Daten vom Server zieht. Der Geschäftsbrowser kommuniziert so vornehmlich mit dieser Pufferdatenbank, um Daten auszutauschen.
- Keine URLs, kein Zurückbutton: Da man die Möglichkeit hat, Entitäten in einem Fenster zu öffnen, statt auf einer neuen Seite, kann man sich in fast allen Fällen den Zurück-Button sparen. Die Arbeit mit Tabs stellt sich zwar zum Teil als sehr komfortabel dar, aber die jetzt sehr andere Herangehensweise durch die neuen Möglichkeiten macht ein grundsätzliches Umdenken in dieser Hinsicht erforderlich. Trotz des Hash-Parts der URL haben SPA’s in der Regel auch mit dem Zurückbutton und der Möglichkeit, Bookmarks anzulegen, zu kämpfen.
Viele der aufgezählten Features sind auch mit normalen Webbrowsern möglich - das ist mir bewusst. Es geht vor allem um die effektive Bereitstellung neuer Geschäftsanwendungen. Als Faustregel soll gelten: Es soll so einfach sein mit dem Businessbrowser datengetriebene Businessapplikationen zu erstellen, wie es mit HTML möglich ist, eine einfache Webseite zu erstellen. Eine komplexe ansprechende Webseite mit dem Businessbrowser zu erstellen ist so umständlich, wie eine flexible datengetriebene Businessapplikation mit HTML und Javascript umzusetzen.
Ich könnte dazu jetzt noch ewig viel schreiben, aber ich denke, das wäre hier jetzt kontraproduktiv. Könnt ihr euch vorstellen, dass so eine Entwicklung Sinn macht?
Kommentar