Ankündigung von Dart Sass

In den letzten Monaten habe ich still an einem neuen Projekt gearbeitet. Heute bin ich bereit, Dart Sass der Welt anzukündigen. Es ist eine völlig neue Implementierung von Sass, die darauf ausgelegt ist, schnell, einfach zu installieren und leicht zu bearbeiten zu sein. Es ist noch nicht vollständig – ich arbeite mich stetig durch sass-spec –, daher veröffentliche ich heute nur die Version 1.0.0-alpha.1. Aber es ist solide genug, damit Sie es herunterladen, damit spielen und beginnen können, Fehler zu melden.

Sie können ein eigenständiges Archiv von der Release-Seite herunterladen – extrahieren Sie es einfach, fügen Sie den Ordner zu Ihrem Pfad hinzu und führen Sie dart-sass aus. Dart kompiliert auch zu JavaScript, sodass Sie, wenn Sie npm installiert haben, die JS-Version installieren können, indem Sie npm install -g dart-sass ausführen. Und wenn Sie selbst ein Dart-Benutzer sind, können Sie es mit pub global install sass installieren.

Warum Sass neu schreiben?Warum Sass neu schreiben?  Permalink

In den letzten Jahren gab es zwei Hauptimplementierungen von Sass. Ruby Sass war das Original, hauptsächlich von mir mit erheblicher Hilfe von Chris geschrieben. Es ist High-Level und leicht zu bearbeiten, daher ist es, wo wir neue Features iterieren und wo sie zuerst veröffentlicht werden. Dann gibt es LibSass, die C++-Implementierung, die ursprünglich von Aaron und Hampton erstellt und jetzt von Marcel und Michael gepflegt wird. Es ist Low-Level, was es sehr schnell und einfach zu installieren und in andere Sprachen einzubetten macht. Insbesondere seine Node.js-Bindings sind eine sehr beliebte Möglichkeit, Sass in der JavaScript Welt zu verwenden.

Die Stärken jeder Implementierung ergänzen die Schwächen der anderen. Wo LibSass schnell und portabel ist, ist Ruby Sass langsam und für Nicht-Ruby-Benutzer schwer zu installieren. Wo Ruby Sass einfach zu iterieren ist, macht die Low-Level-Sprache von LibSass es erheblich schwieriger, neue Features hinzuzufügen. Eine komplementäre Beziehung kann gesund sein, aber sie kann auch bedeuten, dass keine der beiden Lösungen so gut ist, wie sie sein muss. Das haben wir im Mai festgestellt, als Marcel das LibSass-Team offiziell verlassen hat^[1].

Ohne die Anstrengungen von zwei Personen waren wir uns nicht mehr sicher, ob LibSass mit der Geschwindigkeit mithalten konnte, mit der Chris und ich Änderungen in die Sprache einführen wollten. Und es war seit langem klar, dass Ruby Sass viel zu langsam für Anwendungsfälle mit großen Stylesheets war. Wir brauchten eine neue Implementierung, die CSS schnell generieren *und* neue Features schnell hinzufügen konnte konnte.

Warum Dart?Warum Dart? Permalink

Wir haben eine Reihe möglicher Sprachen in Betracht gezogen und uns aus verschiedenen Gründen für Dart entschieden. Erstens ist es *wirklich schnell* – die Dart VM ist im Allgemeinen viel schneller als JavaScript-VMs, und frühe Benchmarks^[2] deuten darauf hin, dass Dart Sass für große Stylesheets 5-10x schneller ist als Ruby Sass und nur etwa 1,5x langsamer als LibSass. Ich wage zu vermuten, dass es etwa 1,5-2x schneller wäre als eine idiomatische JS-Implementierung, aber ich kann das nicht mit Sicherheit sagen. Und die Leistung von Dart wird ständig besser besser.

Gleichzeitig ist Dart einfach zu handhaben – viel mehr als C++ und in gewissem Umfang sogar mehr als Ruby für ein so großes Projekt. Zugegebenermaßen sind nicht so viele Leute damit vertraut wie mit JavaScript, aber Sprachimplementierungen erhalten ohnehin selten viele externe Beiträge. Ich werde den Großteil der Arbeit an der neuen Implementierung erledigen, und Dart ist die Sprache, mit der ich mich persönlich derzeit am wohlsten fühle (wenn ich nicht an Sass arbeite, bin ich im Dart-Team). Die Verwendung von Dart gibt mir viel zusätzliche Geschwindigkeit.

Im Gegensatz zu Ruby oder JavaScript ist Dart *statisch typisiert*, sodass der Typ jedes Werts ermittelt werden kann, ohne den Code auszuführen. Im Gegensatz zu C++ ist es *garbage collected*, sodass wir uns nicht so viele Gedanken über die Bereinigung machen müssen. Das macht es einfach zu schreiben, einfach zu modifizieren und einfach zu warten. Vielleicht noch wichtiger ist, dass es die Übersetzung in andere Programmiersprachen erleichtert, was LibSass helfen wird, neue Features schneller zu erhalten schneller.

Der letzte Grund, warum wir Dart gewählt haben, ist etwas, das nur wenige andere Sprachen aufweisen können: JavaScript-Kompatibilität. Dart kann zu JavaScript kompiliert werden, das direkt in Node.js verwendet oder sogar potenziell in einem Browser ausgeführt werden kann. Ein großer Teil des Sass-Ökosystems basiert auf node-sass, und wir beabsichtigen, die JS-Version von Dart Sass so API-kompatibel wie möglich mit node-sass zu gestalten, damit sie sich problemlos in bestehende Tools und Build-Systeme integrieren lässt lassen.

Der einzige Nachteil ist ein Geschwindigkeitsverlust: Dart Sass ist beim Ausführen auf V8 etwa doppelt so langsam wie beim Ausführen auf der Dart VM. Dies platziert es jedoch immer noch solide 3-4x schneller als Ruby Sass. Letztendlich hoffen wir auch, eine einfache Möglichkeit für Benutzer der JS-kompilierten Version zu bieten, mit möglichst geringer Reibung zur Dart VM-Version zu wechseln möglich.

Was passiert mit den anderen Implementierungen?Was passiert mit den anderen Implementierungen?  Permalink

An der Entwicklung von LibSass ändert sich nichts. Michael arbeitet hart daran, Features aus Sass 3.5 hinzuzufügen, und wir gehen davon aus, dass dieser Prozess fortgesetzt wird, wenn neue Sprachfeatures hinzugefügt werden. Der einzige Unterschied ist, dass LibSass nicht mehr strikt mit der neuesten Version der Sprache kompatibel sein muss, damit diese Version gestartet werden kann, da es nicht mehr die einzige Implementierung mit angemessener Leistung sein wird Leistung.

Mehr Flexibilität führt zu schnelleren LibSass-Releases, die die von den Benutzern am meisten gewünschten Features priorisieren. Strikte Kompatibilität bedeutete, dass wichtige Features wie die Unterstützung für CSS-Custom-Properties (CSS custom property support) nicht veröffentlicht werden konnten, bis alle kleinen kniffligen Randfälle, die in der entsprechenden Ruby Sass-Version vorhanden waren, wie :root unification, ebenfalls implementiert waren. Wir werden uns weiterhin um so viel Kompatibilität wie möglich bemühen, aber wir werden uns nicht davon abhalten lassen, die Geschwindigkeit zu verbessern verbessern.

Ruby Sass hingegen wird irgendwann verschwinden, es sei denn, es erscheint ein neuer Maintainer. Wir wollen den Übergang nicht überstürzen und das Ökosystem gefährden: Chris und ich verpflichten uns, es ein Jahr lang zu pflegen, was die Synchronisierung der Sprache mit allen neuen Ergänzungen in Dart Sass beinhaltet. Wenn jemand daran interessiert ist, sich nach diesem Zeitraum ehrenamtlich als Maintainer zu engagieren, würden wir ihn gerne betreuen und ihm im kommenden Jahr den Code erklären. Wenn sich jedoch niemand meldet, wird Ruby Sass offiziell als veraltet und unbeaufsichtigt betrachtet behandelt.

Ich möchte betonen, dass wir die Entscheidung, die Entwicklung von Ruby Sass einzustellen, nicht leichtfertig treffen. Dies ist eine große Veränderung, und sie ist für mich nicht einfach – ich arbeite fast zehn Jahre lang ununterbrochen an Ruby Sass, und es ist schwer, diese Geschichte loszulassen. Aber Chris und ich haben dies gründlich besprochen, und wir sind davon überzeugt, dass dies der richtige Schritt ist. Wir haben nur begrenzt Zeit für Sass zur Verfügung, und es macht keinen Sinn mehr, diese Zeit in eine Implementierung zu investieren, die so langsam ist, dass sie für viele unserer größten Benutzer unerschwinglich ist Benutzer.

Wie geht es weiter?Wie geht es weiter? Permalink

Bevor wir die erste stabile Version von Dart Sass veröffentlichen, stehen noch einige wichtige Dinge auf unserer To-do-Liste Liste.

• Vollständige sass-spec-Kompatibilität. Es gibt immer noch eine Reihe von Ecken der Sprache, in denen Dart Sass Fehler macht, insbesondere in Bezug auf @extend. Ich gehe nicht davon aus, dass einzelne Inkompatibilitäten besonders schwierig zu beheben sind, und sass-spec ist ziemlich umfassend, daher geht es nur darum, die Anzahl der fehlschlagenden Specs stetig zu reduzieren, bis sie Null erreicht erreicht.

• Nahezu kompatible node-sass render()-Kompatibilität im npm-Paket. Die node-sass render() API ist der Haupteinstiegspunkt zu LibSass in der JavaScript-Welt. Sie ist die Art und Weise, wie Build-Systeme Sass ausführen, wie Benutzer benutzerdefinierte Sass-Funktionen definieren und wie Eyeglass Module an Sass übergibt. Wir möchten diese API mit ausreichender Genauigkeit unterstützen, damit das bestehende Ökosystem mit JS-kompiliertem Dart Sass funktioniert funktioniert.

• Dart Sass-Kompatibilität in Ruby Sass. Es gibt einige Fälle, in denen Dart Sass bewusst von Ruby Sass abweicht, insbesondere wenn das Verhalten von Ruby Sass als Fehler angesehen wird. Wir sollten Deprecation-Meldungen in Ruby Sass hinzufügen und, wenn wir dies mit minimaler Unterbrechung tun können, die Unterstützung für das neue Verhalten hinzufügen Verhalten.

Es gibt noch viel mehr, was wir irgendwann tun möchten, wie z. B. die Unterstützung von Sass im Browser und die Bereitstellung eines node-sass-kompatiblen Wrappers für Sass auf der Dart VM, aber das blockiert nicht die anfängliche Veröffentlichung Veröffentlichung.

Auf in die ZukunftAuf in die Zukunft Permalink

In den nächsten Monaten werden wir viel Arbeit in die Stabilität und Kompatibilität von Dart Sass stecken und die Sass 3.5-Features in LibSass integrieren. Ich glaube, dass Anfang 2017 eine stabile Version von Dart Sass und eine 3.5-Version von LibSass erscheinen werden. Dann werden wir uns auf die großen Features konzentrieren und uns auf Sass 4.0 und sein brandneues Modulsystem zubewegen System.

Dart Sass ist eine große Veränderung, aber auch eine aufregende. Es wird uns ermöglichen, neue Features schneller an die Benutzer zu bringen und diese Features schneller auszuführen. Es wird den Benutzern ermöglichen, die Referenzimplementierung trivial zu installieren und auszuführen. Und es gibt uns eine performante Möglichkeit, Sass zum ersten Mal in reinem JavaScript Sass auszuführen. Die Vorteile sind groß und greifbar, und ich bin zuversichtlich, dass sie die Kosten wert sind Kosten.

---

1. Ich sage „offiziell“, weil er immer noch zum Projekt beiträgt, wenn er kann, nur nicht in einer offiziellen Maintainer-Kapazität. ↩︎

2. Vorbehalte gelten: Ich bin kein Benchmarking-Experte, und diese Tests waren *ad hoc* und wurden anhand nicht repräsentativer Quell-Stylesheets durchgeführt. Wenn jemand Interesse daran hat, an wissenschaftlicheren Benchmarks zu arbeiten, lassen Sie es mich bitte wissen! ↩︎