Rome, wie Deno. Nur für Babel!

Rome: Linter, Compiler, Type-Checker – JavaScript-Tooling der nächsten Generation wird zum Monolithen
Keine Kommentare

Rome heißt das neue Projekt von Sebastian McKenzie, der an der ursprünglichen Entwicklung von Babel beteiligt war. Mit Rome möchte er, fast wie Ryan Dahl bei Deno, einige der Grundideen des JavaScript-Universiums neu definieren. Ein Linter ist eigentlich ein Compiler, sagt McKenzie und spricht sich gegen die Zerteilung des Ökosystems in zu viele kleine und kleinste Packages aus. So soll auch Rome nicht nur ein Linter bleiben, sondern viel mehr werden.

Aus Erfahrung lernt man: Das gilt offenbar auch für diejenigen, die einige der heute bekanntesten Tools und Implementierungen des JavaScript-Ökosystems geschrieben haben. So hat Ryan Dahl mit Deno quasi die zweite Generation der serverseitigen Laufzeitumgebungen für JavaScript geschaffen, nachdem er bereits Node mitentwickelt hatte. Sebastian McKenzie, der zu den Erfindern des Transpilers Babel gehört, hat nun ein ebenfalls neues Projekt präsentiert und erklärt, dass auf seinen Erfahrungen mit dem bekannten Transpiler aufbaut. Rome, so heißt der neue Entwurf, liegt als Beta-Version vor und umfasst bislang vornehmlich einen Linter. Dabei soll es aber nicht bleiben. Rome soll Ideen aufgreifen, die ursprünglich auch für Babel vorgesehen waren, dort aber nicht implementiert werden konnten und wird am Ende zahlreiche Funktionen vereinen. McKenzie verfolgt ein ehrgeiziges Ziel. Rome soll zu einer monolithischen Toolchain wachsen und damit ein anderes Konzept verfolgen als die meisten Tools, die derzeit in der JavaScript-Welt verwendet werden.

Rome: Der Linter als erster Schritt

In der jetzt veröffentlichten Beta des Linters von Rome ist davon aber noch nicht viel zu sehen. Im Linter wird wird neben ECMAScript auch TypeScript und React unterstützt, derzeit sind etwa 100 Linting-Regeln in das Tool integriert. Inspiriert wurden die Linting-Regeln von ESLint, somit stellt der erste Schritt zur Toolchain keine allzu große Neuerung dar. Die Feature-Entwicklung für den Linter ist laut Blogpost zum Release sogar schon weitgehend abgeschlossen. Bislang könnten jedoch noch Bugs auftreten, die in der Beta-Phase behoben werden sollen. So weit, so normal.

JavaScript Days 2020

Einstieg in Vue: Teil 1

mit Maximilian Lang und Krzysztof Piechowicz (adesso SE)

Wie man zu TypeScript migriert

mit Golo Roden (the native web)

Neben dem Beheben der Bugs am Linter geht es nun aber weiter damit, Rome um viele weitere Features zu erweitern, damit Rome zur angedachten monolithischen Toolchain werden kann.  Linter, Compiler, Bundler, Test Runner, Dokumentations-Generator, Formatting, Minifizierungstool, Type-Checker und mehr sind laut Dokumentation vorgesehen. Nichts davon soll auf anderen Tools beruhen, alle Features soll neu gebaut und in einem einzigen, großen Package veröffentlicht werden. Der Sprachsupport soll neben JavaScript und TypeScript auch HTML, JSON, Markdown und CSS umfassen. Derzeit seien bereits erste Teile aller Komponenten entwickelt worden, wie McKenzie im Blogpost zum Beta-Release des Linters erwähnt. Das Projekt wurde Anfang des Jahres Open Source gestellt, nachdem McKenzie bereits seit 2017 privat daran gearbeitet hatte. Inzwischen haben sich einige Mitwirkende gefunden, die zu Rome beitragen, sodass jetzt das erste Beta-Release erfolgen konnte.

Monolith statt kleinster Pakete

Liest man sich die Motivation hinter der monolithischen Toolchain durch, fallen Parallelen zur Erzählung von Ryan Dahl auf, als er Deno vor mehr als zwei Jahren vorstellte. Dahl gab sich damals vornehmlich selbst die Schuld an den konzeptuellen Fehlern von Node.js. So weit geht McKenzie nicht. Beide Entwickler gehören jedoch zur Generation der Erfinder von Tools und der Funktionsweisen dahinter, die heute die Arbeit am Web bestimmen. Und beide kritisieren die Standards, wie sie heute sind. So ist Deno beispielsweise in einer Sandbox verpackt und greift so einen der ursprünglichsten Gedanken hinter der Entwicklung der Browser-Technologien wieder auf, der in Node nur bedingt umgesetzt ist. Browser sollten von Anfang an verhindern, dass Inhalte auf das System ausbrechen können; das ist über lange Zeit hinweg nicht gut gelungen. Deno will es anders machen und zur Sicherheit im Browser beitragen, indem es selbst als Sandbox fungiert. Auch an anderen Stellen hat Dahl heute bewusst andere Wege gewählt als damals mit Node. In das neue Projekt sind zahlreiche Erfahrungen eingeflossen, die er seitdem gesammelt hat.

McKenzie kritisiert auf einer ähnlich grundlegenden Ebene, dass das JavaScript-Ökosystem zu stark in kleinste Packages zersplittert ist und die Chancen auf Synergien in der Funktionsweise von Webtech-Tools dadurch zu wenig genutzt werden. Ein Linter sei im JavaScript-Ökosystem eigentlich nur ein Compiler, wie er im Blogpost zu Rome erklärt. Beide Tools verarbeiten den Code und geben eine besser für bestimmte Zwecke geeignete Version sowie Fehlermeldungen aus. Der Unterschied liege nur darin, welche Art von Änderungen vorgenommen werden. Darum empfindet McKenzie es als logischen nächsten Schritt, der starke Fragmentierung des Ökosystems entgegenzutreten und das Tooling in einem einzigen Package zu vereinen. Bei Babel empfindet er eine solche Änderung als nicht mehr möglich, da der Compiler sich in eine andere Richtung entwickelt hat. Darum hat er eine neue Lösung geschaffen, die dieses Problem löst.

Genau wie bei Deno und Ryan Dahl wird ihm vermutlich nicht die gesamte Community zustimmen. Es ist dennoch spannend zu sehen, wie das Web neu gedacht wird – von denen, die vor Jahren die heutigen Standards geschaffen haben.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu:
X
- Gib Deinen Standort ein -
- or -