JavaScript fuer Eclipse-Entwickler

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.

2.2 Eine visuelle Tour durch Orion
    Im Zentrum von Orion stehen eine Reihe von „Task“-Seiten, die flexibel sind, sowohl in Bezug auf die Orte der Ressourcen, mit denen sie interagieren, als auch was ihre Erweiterungsmöglichkeiten betrifft. Bevor wir auf technische Details und deren Bedeutung eingehen, wenden wir uns den