Suche
Texteditor auf Basis von Electron

Neuer Code-Editor Xray soll Performance und Erweiterbarkeit vereinen

Marcel Richters
Xray

© Shutterstock / Digital_Art

Vier Jahre sind inzwischen seit dem Launch des Texteditors Atom vergangen. In so einer langen Zeit gibt es viel zu lernen und noch mehr, was sich mit dem Gelernten ausprobieren lässt. Die Entwickler von Xray haben sich genau das zur Aufgabe gemacht.

Auf den ersten Blick erscheint Xray wie ein normaler Texteditor, der auf Electron basiert. Aber Xray gehört zur „nächsten Generation“ Texteditoren und steckt voller „radikaler Ideen“, wie im GitHub-Repository zu lesen ist. Diese Ideen sollen in Xray nach und nach durchprobiert werden, ohne dabei die Stabilität von Atom zu gefährden.

Der experimentelle Editor soll vor allem vier Dinge bieten: Hohe Performance, Kollaborationsmöglichkeiten, Erweiterbarkeit und Webkompabilität. Um das zu erreichen, fließen laut Entwicklern die Erfahrungen ein, die in den vier Jahren seit dem Launch von Atom gemacht worden sind. Experimentell ist der Editor übrigens nicht nur was die Funktionen angeht. Auch die Programmiersprache – nämlich fast 80% Rust – ist eher ungewöhnlich.

Die primären Eigenschaften von Xray

An oberster Stelle stand bei der Entwicklung von Xray die Performance. So soll das Öffnen eines neuen Anwendungsfensters bei einem Median-User nur 150ms dauern, der Gesamteindruck des Editors soll „leichtgewichtig“ und „responsive“ sein. Auch der Speicherverbrauch soll konstant niedrig und die Stapelverarbeitung möglichst schnell gehalten sein. Aber wenn es die Geschwindigkeit verbessert, nehmen die Entwickler auch höheren Speicherverbrauch in Kauf, zumindest in einem gewissen Rahmen.

Die Schnelligkeit und Leichtgewichtigkeit von Xray sollen sich kollaborativ so gut nutzen lassen wie alleine. Alle relevanten UI-Elemente sollen von Beginn an auf Zusammenarbeit ausgerichtet sein, Interaktionen mit dem Dateisystem und anderen Ressourcen werden abstrahiert, damit sie besser über Netzwerkverbindungen arbeiten.

Damit User Xray nach Belieben erweitern können, haben die Entwickler APIs eingebaut, die zwar viele Möglichkeiten bieten, aber Responsiveness, Stabilität und Sicherheit nicht gefährden sollen. Allerdings werden bewusst noch keine genauen Informationen zu den Implementierungen ausgegeben, da die Entwickler so eine Destabilisierung des noch entstehenden Ökosystems des Editors verhindern wollen.

Eine Eigenschaft, die noch nicht ganz auf sicheren Füßen steht, ist die Webkompabilität von Xray. Ziel der Entwickler ist es, eine einheitliche Nutzungserfahrung zwischen GitHub.com und dem Editor herzustellen. Auch Electron-Anwendungen sollen hierzu genutzt werden. Sollte dieses Feature allerdings zu ernsthaften Problemen bei der Performance führen, könnte es in der finalen Version auch gestrichen werden.

Die Architektur von Xray

Electron hat den Entwicklern von Xray zu viel Overhead für das Ziel der guten Performance, gleichzeitig halten sie Electron aber für eine „plattformübergreifende, erweiterbare Benutzeroberfläche“. Wie also beides verbinden? Mithilfe von Webtechnologie wie Styling durch CSS und Text-Rendering mit WebGL sollen User dabei unterstützt werden, die UI-Elemente zu nutzen, die sie für ihre Arbeit brauchen. Dafür steht ein Scritping-API zur Verfügung, und laut Entwicklern eignet sich die mit ausgelieferte JavaScript-VM ganz hervorragend für die geplanten Aufgaben.

Xray Editor

Die Architektur von Xray baut auf einer Dynamic Library geschrieben in Rust auf. Quelle: GitHub.com/Atom/Xray

Außerdem kommt als Programmiersprache Rust zum Einsatz, nur die View Logic soll sich auf JavaScript stützen. Davon versprechen sich die Entwickler von Xray, dass der „Fußabdruck“ für Laden und Ausführen möglichst klein bleibt. Das robuste Type-System von Rust soll die Wartung effizienter machen, als es bei dynamischerem Code der Fall wäre. Außerdem soll mit der multi-Thread-Orientierung von Rust paralleles Berechnen besser funktionieren als mit JavaScript.

Entwicklung als Lernprozess

Derzeit liegt der Fokus der Entwickler noch auf dem Lernprozess. Zwar wolle man Code in „production-quality“ schreiben, aber Features, die nicht zum Lernprozess beitragen, werden eher aufgeschoben. Welche Features es sind, die derzeit eingebaut werden, soll detailliert dokumentiert werden. Die Entwicklern nennen das „Documentation-driven Development“.

Ebenfalls Teil des Entwicklungsgrundsatzes ist die Nutzung von nur einem Repository. Der gesamte Code sollte in einem Strang entstehen. Builds sollen Fingerprints auf Komponentenbasis haben und die Komponenten möglichst detailliert sein. Um diese Ziele zu erreichen, wollen die Entwickler (gut ausformulierte) Pull-Requests und Problemmeldungen bis zum Ende des nächsten Werktages beantworten. Sollte dies nicht möglich sein, versprechen sie, sich zeitnah um die Angelegenheiten zu kümmern.

Anspruchsvolle Ziele

Es sind hehre Ziele, die sich die Entwickler von Xray gesteckt haben. Gleichzeitig haben sie aber auch schon einen klaren Zeitplan für deren Umsetzung. So soll bereits im ersten Quartal 2018 ein Entwickler-Release der Standalone Editor Component stattfinden. Das CRDT-basierte Text Storage ist bereits vorhanden, auch die Arbeit am WebGL-basierten Text-Rendering schreitet voran. Wer Interesse an dem Projekt hat, kann sich auf der GitHub-Seite informieren und findet dort auch die Möglichkeit, beizutragen.

Geschrieben von
Marcel Richters
Marcel Richters
Marcel hat Soziologie an der Goethe-Universität in Frankfurt am Main studiert und danach als E-Commerce-Manager gearbeitet. Seit Februar 2018 unterstützt er das Team von JAXenter als Redakteur. Daneben arbeitet er als freier Journalist in der Mainmetropole.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: