Web 2.0 für den Desktop

Wenn es euch so geht wie mir, habt ihr eine Menge cooler Ideen für Anwendungen und eine grobe Vorstellung wie diese Ideen sich schnell und leicht in Rails umsetzen ließen.

...wenn bloß die Anwendungen selbst als Webanwendungen geeignet wären.

Meine "Finanzbuchhaltung" sieht zum Beispiel so aus: Meine Arbeitszeiten werden auf einem Zettel eingetragen, wenn dieser voll ist, tippe ich ihn in OpenOffice Calc ab. Um daraus Rechnungen zu machen, öffne ich in Writer meine Rechnungsvorlage, passe die Posten an, übertrage von Hand die Anzahl der Stunden und suche aus alten Rechnungen die Adresse heraus um Sie -- wieder von Hand -- in das Adressfeld zu posten.

Das hat in der Vergangenheit ausgereicht, aber allmählich wird mir dieses Prozedere zu blöd. Als Datenbankanwendung in Rails wäre diese Aufgabe trivial zu lösen. Eine Tabelle mit den Kunden, eine Tabelle mit den Stunden, eine Tabelle mit Rechnungen, eine mit Rechnungsposten. Mit wenigen Zeilen wären die Assoziationen hergestellt, als Frontend würde für's erste Streamlined reichen, das Rendern der Rechnungen kann schnell in HTML erfolgen.

Ich habe bloß keine Lust, eine solche Anwendung mit einigermaßen sensiblen Daten auf einem Webserver laufen zu lassen, andererseits schreckt mich aber auch die Mühe, das ganze in Objective C oder Java zu schreiben, der Overhead durch das Fehlen von Streamlined und ActiveRecord wäre kaum gerechtfertigt.
"Wenn ich doch bloß ein Framework wie Rails für Offlineanwendungen hätte" schießt es mir jedesmal durch den Kopf...

Dabei sind entsprechende Lösungen auf dem Weg. Joyent stellte diese Woche Slingshot vor, eine Umgebung die genau das ermöglicht:

Joyent Slingshot allows developers to deploy Rails applications that work the same online and offline (with synchronization) and with drag into and out of the application just like a standard desktop application. We have Joyent Connector and a select group of third party applications working under Joyent Slingshot. Joyent plans to have Slingshot available for general release on both Windows and Macintosh OS X in late April, 2007. If you would like to be considered for a spot an early release tester, please send email to slingshot [at] joyent.com You must be a Rails developer with an application we believe would help us put the final polish on Slingshot.

Slingshot schlägt damit in eine ähnliche Kerbe wie Adobes Apollo, Firefox 3 oder Dojo.

Das Problem der Offline-Verfügbarkeit für viele ein Manko webbasierter Applikationen auch wenn die Web 2.0 Prominenz von dieser Meinung abweicht (hier und hier). Applikationen und Technologien wie die genannten könnten könnten es endlich beseitigen. Interessanter finde ich aber, dass es dadurch auch möglich wird, dediziert Web-Technologien zu benutzen um für den Desktop zu programmieren. Wenn sich dieser Trend weiterentwickelt, würde vielleicht eine Menge der brillianten Köpfe, die da draußen ihre mehr oder weniger nützlichen Webanwendungen entwickeln, den Weg zurück zum Desktop finden.

Denkt man diesen Gedanken allerdings zuende, gelangt man schnell an die Frage: Wie sind wir eigentlich an die Stelle geraten an der wir uns zur Zeit in der Softwareentwicklung befinden? Was zieht alle Entwickler ins Web? Woher kommen die ganzen Grabreden auf den Desktop? Ich glaube kaum dass die Antwort wirklich da liegt wo die Web-2.0 Enthusiasten sie gerne hätten. Soziale Netze, REST-APIs und verschmelzende Datenbanken sind vielleicht nette Resultate der momentanen Situation, aber was einen Entwickler wirklich treibt, sich ins Netz zu begeben ist die Art und Weise wie dort entwickelt wird. Durch mächtige Tools, Sprachen, Protokolle und Frameworks wie Rails, Django, Ajax, HTML und REST sowie die vollkommene Kontrolle über den laufenden Code macht die Entwicklung im Web einfach irre Spaß.

Die Einschränkungen die diesen Elementen zugrunde liegen, sorgen aber gleichzeitig für 4 große Probleme:

  1. Die Interoperabilität zwischen Webanwendungen ist stark eingeschränkt. Und mit Interoperabilität meine ich Interoperabilität auf Benutzerseite. Eine noch so schöne API ist nach wie vor nur für Entwickler nutzbar. Der Benutzer der Daten von eine Anwendung zur nächsten transportieren will braucht dafür standardisierte Austauschformate und einfache Mittel diese Lesen, Schreiben und übertragen zu können.
  2. AJAX und Prototype haben HTML als Benutzerinterface zwar einen gigantischen Schritt weitergebracht, die Trennung zwischen Anwendung und Browser sorgt allerdings weiterhin für Einschränkungen. Drag-and-Drop über Webseiten hinweg? Nahtlose Einbindung von nicht-HTML Elementen? Fehlanzeige.
  3. Offline-Verfügbarkeit habe ich weiter oben bereits als Problem angesprochen. Hierüber lässt sich vielleicht streiten,
  4. Vor allem aber sind Webanwendungen für Aufgaben mit hoher Interaktivität oder großen Datenaufkommen nicht geeignet.

Aus diesem Dilemma sehe ich zwei Auswege: Fix Webapps oder Fix the Desktop

Fix Webapps

Daran, das WWW benutzbarer und mächtiger zu machen, arbeiten eine Menge schlauer Leute. Was mich daran stört, ist das grundlegende Vorgehen. Dabei wird HTML (nebst Unterstützungs-Technologien wie Javascript) allmählich zu einem schizophrenen Ungetüm umgebaut, das nicht weiss, ob es Dokumentenbeschreibungssprache oder GUI-Toolkit sein will. Die Anforderungen sind durchaus verschieden; Dokumente sind statisch und eher seriell aufgebaut während GUIs dynamisch sind, mit vielen parallelen Elementen.

Ersatztechnologien die traditionelles GUI-Design mit Netzwerktechnologien kombinieren und so (zumindest potentiell) dynamische Oberflächen und Kommunikation mit anderen Programmen ermöglichen sind seit Java verfügbar, konnten sich aber nie richtig durchsetzen. Ein Fehler dabei waren sicherlich die Orientierungsschwierigkeiten mit denen Java anfangs zu kämpfen hatte, ebenso das fürchterliche AWT-Toolkit.

Die größte Hürde war aber wohl, dass die frühe Desktop-Orientierung genau die Komplexitätsprobleme mit sich brachte, die Webentwickler heute vermeiden. Umständlich zu programmierende Klassenbibliotheken, wenig Unterstützung durch Frameworks, zuviele Freiheiten.

Gebranntes Kind scheut das Feuer, daher scheint es wahrscheinlich, dass auch die aktuellen Versuche von Adobe mit Flex sich nicht durchsetzen werden und die Entwicklergemeinde stattdessen den HTML-Weg beibehalten wird. Mit XML/XHTML und CSS3 sind damit dann vielleicht irgendwann tatsächlich brauchbare GUIs machbar.

Vielleicht.

Fix the Desktop

Wenn fehlende Frameworks den Desktop also so in Ungnade gebracht haben, wird die nahe Zukunft spannend. Während Java allmählich in die Jahre kommt, sind die .NET Sprachen und besonders C# 3.0 extrem vielversprechend. Das .NET Framework ist sicher nicht frei von Mängeln, besonders was die komplizerteren Windows Forms Controls angeht, aber verglichen mit den MFC ist .NET ein gewaltiger Schritt nach vorn.

Vorn heisst dabei allerdings mal wieder soviel wie "da wo Apple vor Jahren war". Nach meinen jüngsten Ausflügen in die Welt von Cocoa Programmierung mit Objective-C weiss ich womit ich meine nächsten Tools programmiere. Das Macs bei Entwicklern nicht zuletzt aufgrung von DHH und Rails an Popularität gewonnen haben ist kein Geheimnis. Der Mac ist wirklich eine Plattform auf der Softwareentwicklung Spaß macht. Dazu liefert Apple ein hervorragendes Framework und eine starke Programmierumgebung.

Genau das führt dann letztendlich auch dazu, dass tatsächlich coole Software entwickelt wird. Disco, Textmate, Delicious Library, Yep, und, und, und...

Wenn sich diese Kultur kreativer Software auf Basis starker Technologien und Fromeworks verbreitet, sei es nun durch .NET auf Windows oder durch die zunehmende Verbreitung von Macs (was mir natürlich lieber wäre :), stehen uns spannende Zeiten bevor.

2 thoughts on “Web 2.0 für den Desktop

  1. Hallo Jan,

    schöne Zusammenfassung des Dilemmas ;-) Eigentlich habe ich nach einer Rails-Fibu gesucht… Ich spiele durchaus auch mit dem Gedanken mir was eigenes in Rails zu zimmern, und das Ganze dann in einer VM lokal zu betreiben. Damit wäre auch dem Datenschutz genüge getan.

    Grüße,
    Ingo

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>