Webbasierte Tools aus dem Hause Eclipse

Eclipse Orion: Coding on the Web

Simon Kaegi

Januar 2011: Das Eclipse-Plattform-Team erstellt eine völlig neue Codebasis namens Orion mit dem Ziel, webbasierte Entwicklertools zu entwickeln und zu integrieren. Fünf Monate später: Version 0.2 wird veröffentlicht. Orion ist nun ein offizielles Projekt. November 2011: Ein regelmäßiger viermonatiger Releaserhythmus beginnt, und ein weiteres Zwischenrelease wird abgeschlossen. Sämtliche Entwicklungen auf der Clientseite werden in Orion selbst vorgenommen. 1.0 ist in der Planung und wird voraussichtlich im Spätherbst 2012 erscheinen.

Orion ist eine Suite von browserbasierten Entwicklungstools, die sich dennoch deutlich von der Eclipse-Desktop-IDE unterscheidet: Erstens haben wir zugunsten der User Experience auf Einfachheit gesetzt. Wir sind davon abgerückt, UIs zu entwerfen, in denen jedes Tool, das sich jemals als nützlich erweisen könnte, in einen eigenen Bereich gequetscht wird. Stattdessen haben wir die wesentlichen Kernkodierungsaufgaben herausgelöst und jeder Aktivität eine separate Webseite gewidmet. Zweitens ist uns klar geworden, dass wir als Entwickler ohnehin bereits webbasierte Tools wie Bugzilla, Hudson unter anderem in unserer täglichen Arbeit verwenden. Auch wenn wir noch so viel Wert darauf legten, könnten wir also niemals eine universelle Integrationsplattform bieten. Statt dessen ist unserer Meinung nach das Web selbst die Entwicklungsplattform der Zukunft. Mit Orion nehmen wir uns die Kernaktivitäten der Softwareentwicklung (Code-Editing, Projektnavigation, Suchfunktion und Source-Control-Systeme) vor. Zudem möchten wir zeigen, wie gemeinsame Workflows mit bereits eingesetzten webbasierten Tools unterstützt werden können und wie man bei Bedarf neue Tools hinzunimmt.

Designprinzipien

Orion war nicht der erste Vorstoß hin zu webbasiertem Tooling für das Eclipse-Plattform-Team. Wie sich manch einer erinnern mag, gab es vor einigen Jahren Experimente, die Eclipse IDE als eine Mischung aus HTML und Flash in den Browser zu bringen. Das stellte sich aber als speicherintensiv und komplex heraus. Ein Jahr später haben wir gemeinsam mit dem Mozilla-Team die Machbarkeit eines Java-Editors untersucht, der Kern-JDT auf dem Server als Sprachunterstützung und den auf Canvas basierenden Bespin-HTML5-Editor verwendete. Obwohl diese Experimente letztendlich nicht von Erfolg gekrönt waren, haben die Lektionen, die sie uns erteilten, das Design von Orion geprägt. Schon zu Beginn legten wir vier Leitlinien fest, die wir seitdem im Großen und Ganzen befolgen und die uns noch immer bei vielen Entscheidungen helfen:

  • Die Fähigkeiten des nativen Browsers nutzen: Im Prinzip war das eine Lektion, die wir von SWT gelernt haben. Es ist einfach unnötig, Tabs zu implementieren, wenn der Browser selbst schon Tab-basiert ist. Soweit möglich, sollte man es außerdem vermeiden, das Standardverhalten von Hyperlinks und eingebauten HTML-Input-Widgets zu überschreiben. Wichtig ist, dass der ZURÜCK-Button des Browsers funktioniert, und Dinge wie URLs sollten sowohl als Lesezeichen verwendet als auch öffentlich zugänglich gemacht werden können.
  • Task- und ressourcenorientiert vorgehen: Benutzer, für die der Eclipse-Desktop neu ist (und Entwicklern, die wir in der Webcommunity befragt haben), sind von den überladenen IDE-Fenstern unter Umständen geradezu erschlagen. Wir versuchen, jede Seite auf einen Task zu reduzieren und gegebenenfalls überflüssigen Schnickschnack zu entfernen. Das brachte uns auf die Formel: Seite = Task + Ressource. Beispielsweise editieren wir (Task) jede einzelne Quelldatei (Ressource) auf einer separaten Seite. Das funktioniert gut über Browser-Tabs und entspricht der Art, wie Entwickler normalerweise Änderungen in mehreren Dateien handhaben. Ein positiver Nebeneffekt dieser Strategie ist, dass Orion-Seiten verlinkt und auf vielen Ebenen verstanden werden können.
  • Performanz und Leichtgewichtigkeit anstreben: Für alle Orion-Seiten ist eine Ladezeit von weniger als einer Sekunde das Ziel. Wir legen Wert auf Techniken wie JavaScript-Build-Minifizierung und verwenden Image Sprites, damit die Seite schnell lädt und effektiver den Cache des Browsers nutzen kann. Einmal geladen, darf die Seite keine schlechtere interaktive Performance aufweisen als das Desktopäquivalent, sonst tut das dem Immersion-Effekt Abbruch. Daher haben wir uns, wenn es abzuwägen galt, für schnelle Parser und einfacheren Modularitätssupport anstelle der leistungsstärkeren, aber langsameren Alternative entschieden. Im Web ist Geschwindigkeit schlicht das Killerfeature.
  • Niedrige Einstiegsbarrieren für Anwender: Die Integration von neuen Tools sollte so trivial sein wie ein Link in das Tool zu setzen und zu Orion zurück zu verlinken. Tiefere Integration und Erweiterung ist mit Orion-Plug-ins möglich, und der nötige Aufwand sollte gut definiert und dokumentiert werden. Die Modularität und das API sind uns sehr wichtig. Wir sind der Meinung, dass Komponenten einen Wert an sich haben sollten. Was wir damit meinen: Dinge wie die UI Widgets, z. B. der Codeeditor, oder Teile der Grundarchitektur, z. B. der Plug-in-Support, sind so implementiert, dass sie unabhängig von anderen Teilen von Orion wiederverwendet werden können. Diese Komponenten haben deshalb keine Abhängigkeiten zu bestimmten JavaScript-Bibliotheken. So ist der Orion-Editor inzwischen schon von Mozilla für die in Firefox eingebauten Entwicklertools verwendet worden, und ein Mozilla-Entwickler hat Commit-Rechte im Orion-Projekt erlangt [1].

Wenn bei einem Release Eile geboten ist, kommt es vor, dass einige dieser Leitlinien unter den Tisch fallen. Oder sie sind schlicht nicht anwendbar. Nichtsdestotrotz haben sich diese Grundsätze mit Blick auf Orion bewährt. Jedes Mal, wenn wir eine Entscheidung zu treffen haben, bei der uns etwas gegen den Strich geht, wird sorgsam abgewogen; meist werden Bugs getrackt, um einen Ausweg zu finden. Die verwendeten Technologien werden sich mit der Zeit ändern, nicht aber die Designprinzipien.

Geschrieben von
Simon Kaegi
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.