Geschichten aus 1001 Plugins

Das ist die Geschichte von einem, der auszog abzuklären, wie man eine grosse konventionelle Applikation als moderne, interaktive Web-Applikation programmieren könnte, und der zwar nicht mit einer Antwort, aber doch mit einer Erleuchtung wieder nach Hause kam.

Wenn man sich Moneysoft ansieht, wird einem schnell klar, dass bei einer Realisierung als Web-Applikation ein rein Server-seitiger Ansatz mit statischem HTML ohne Einsatz von Javascript nicht genügt. Nur ein Beispiel hierzu: Man kann heute einen Anwender nicht mehr 20 Dinge eingeben lassen in einer Datenerfassungs-Maske und ihm erst nach dem Abschicken aller Daten sagen, dass alles falsch ist. Eine unzulässige Eingabe auf einem Textfeld erfordert eine sofortige Fehlermeldung, und das heisst im Browser Einsatz von Javascript in irgendeiner Form.

Ich habe darum abgeklärt, wie man heute denn so Web-Applikationen mit einem hohen Anteil an Logik im Client programmiert. Welche Javascript-Frameworks gibt es, die sich bewährt und Reife erlangt haben? Welche Programmier-Muster haben sich etabliert? Welche Regeln befolgen erfahrene Programmierer bei der Entscheidung, was Client-seitig und was Server-seitig implementiert werden soll?

Angetroffen habe ich einen Dschungel, wie ich ihn mir so nicht hätte träumen lassen: Buchstäblich Dutzende miteinander konkurrierender Javascript-Frameworks, Bibliotheken oder wie immer man das nennen mag. Sammlungen mit Hunderten von Plugins bei mindestens einem dieser Frameworks. Viele dieser Dinge mit mehreren Releases, die dazu noch oft in unglaublich schneller Folge erscheinen. Grosse verwirrende Tabellen, was in welchem Browser in welcher Version wie gut funktioniert – oder eben nicht. Und für Leute, die übermütig werden, weil sie meinen, sie hätten es geschafft, lange Abhandlungen darüber, was man alles anders machen muss, damit es auch mit Tablets und Smartphones gut klappt.

Blickt man auf jedes noch so kleine Problem, das sich beim Bauen von Web-Applikationen typischerweise stellt, wie z.B. ein schlauer Editor mit interaktiven Formatierungens-Funktionen als Aufsatz für Textboxen, entdeckt man nicht etwas, das sich als Standard etabliert hat, sondern einen wilden Haufen miteinander konkurrierender Lösungen verschiedenster Grösse und Qualität.

Ok, sagte ich mir, das ist wohl eben so, wenn sich etwas so stürmisch entwickelt wie das Internet, seine Standards und die Geräte, mit denen man auf Websites zugreift. Aber wie baut man da Software, die man bezahlen kann und die nicht nächstes Jahr schon völlig obsolet ist?

Ich kann mir ganz verschiedene Strategien vorstellen, wie man versuchen könnte, sich in diesem Dschungel sinnvoll zu bewegen und länger als ein paar Monate zu überleben. Man könnte die Client-Logik sorgfältig so wählen, dass mit möglichst wenig Javascript-Einsatz ein möglichst grosser Gewinn an Benutzerfreundlichkeit herausschaut: Weniger Javascript bedeutet weniger Abhängigkeiten und potentiell weniger Ärger.

Man könnte versuchen Wahrsager zu spielen und vorherzusehen, was sich in Zukunft einmal durchsetzen könnte, wenn sich die Situation dereinst einmal stabilisieren wird, und dann darauf wetten. Auf der einen Seite Pech, wenn man falsch wettet, aber aber der anderen Seite auch nicht sooo schwierig: jQuery wird auf jeden Fall unter den „Siegern“ sein, wenn Sie mich fragen.

Man könnte auch einen Satz von Open-Source-Komponenten zusammenstellen, der jetzt gut funktioniert, und diesen dann „adoptieren“, spricht selbst weiterentwickeln und an neue Browser und Standards anpassen – mindestens ein paar Jahre lang, bis man etwas Neues machen kann.

Ich hatte grosse Mühe, im Internet brauchbare Diskussionen darüber aufzutreiben, wie man die Strategie findet, die für die jeweils eigene Situation angebracht ist. Viele Leute scheinen noch nicht einmal die Notwendigkeit einer Strategie zu empfinden, und mixen frisch-fröhlich die neuesten Versionen von einem Dutzend oder mehr Plugins zu Web-Applikationen zusammen, als ob es kein Morgen gäbe.

Ich fühlte mich weit davon entfernt, eine Entscheidung darüber zu treffen, welchen Weg die Megos AG einschlagen müsste auf dem Weg zu einem Moneysoft.web, und war am Schluss ziemlich beunruhigt über die ganze Situation.

Aber dann dann kam sie, die eingangs angesprochene Erleuchtung, eines Abends kurz vor dem Einschlafen, und brachte zwar nicht die Antwort auf die Frage nach der Strategie, aber trotzdem ein Ende meiner Zweifel, ob das je etwas werden wird:

Frage: Wie ist es überhaupt möglich, dass es diese riesige Zahl an Javascript-Bibliotheken und -Plugins gibt? Antwort: Es muss einfach und nicht allzu zeitaufwendig sein, so etwas zu bauen. Und das wiederum heisst, dass es eine Obergrenze gibt, wie komplex und kompliziert diese Software überhaupt sein kann: nicht sehr.

Auf die eine oder andere Weise werden wir das darum in den Griff kriegen.

Zu guter Letzt noch ein Link: Ich habe im Zuge der beschriebenen Abklärungen gute Web-Applikationen gesucht, die von der Art der Funktionalität her mit Moneysoft vergleichbar sind (welche man breit gefasst als „Verwaltung administrativer Daten“ umschreiben könnte), und bin dabei auf smallinvoice gestossen. Funktioniert ausgezeichnet, sogar im relativ exotischen Opera-Browser, mit dem ich normalerweise unterwegs bin, was ein sehr gutes Zeichen punkto Einhaltung von Web-Standards darstellt, und wurde offenbar von einem vergleichsweise kleinen Team unter Schweizer Leitung gebaut. Geht doch!

Veröffentlicht in Keine Kategorie. Schlagwörter: , , . Leave a Comment »

Schreibe einen Kommentar

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s

%d Bloggern gefällt das: