Dart Sass の発表
2016年10月31日 Natalie Weizenbaum 投稿
ここ数ヶ月間、私は静かに新しいプロジェクトに取り組んでいました。本日、Dart Sass を世界に発表する準備ができました。これは、高速でインストールが簡単、そしてハックしやすいように設計された、Sass の全く新しい実装です。まだ完成していません。私は sass-spec を着実に進めています。そのため、今日はバージョン 1.0.0-alpha.1 をリリースするだけです。しかし、ダウンロードして試してみたり、issueを提出 するには十分に安定しています。
スタンドアロンのアーカイブは、リリースページからダウンロードできます。展開してフォルダをパスに追加し、dart-sass を実行するだけです。Dart は JavaScript にもコンパイルされるため、npm がインストールされている場合は、npm install -g dart-sass を実行して JS バージョンをインストールできます。また、あなたが Dart ユーザーである場合は、pub global install sass を使用してインストールできます。
なぜ Sass を書き直すのか？なぜ Sass を書き直すのか？ パーマリンク
過去数年間、Sass には主に2つの実装がありました。Ruby Sass はオリジナルで、主に私が Chris の多大な協力を得て書きました。これは高レベルでハックしやすいため、新機能の反復や最初のリリースが行われる場所です。そして、LibSass は、もともと Aaron と Hampton によって作成され、現在は Marcel と Michael によってメンテナンスされている C++ 実装です。これは低レベルで、非常に高速でインストールが簡単で、他の言語に埋め込むのも簡単です。特に、Node.js バインディングは、JavaScript の世界で Sass を使用するための非常に人気のある方法です。
各実装の強みは、もう一方の弱点を補完します。LibSass が高速でポータブルな場合、Ruby Sass は遅く、Ruby ユーザー以外にはインストールが困難です。Ruby Sass が反復しやすい場合、LibSass の低レベル言語は新機能の追加を大幅に困難にします。補完的な関係は健全な場合がありますが、どちらのソリューションも必要なほど優れていない可能性があることも意味します。それは、5月に Marcel が正式に LibSass チームを離れた[1]ときにわかったことです。
2人分の労力がなくなると、LibSass が Chris と私が言語に変更を導入したい速度に追いつけるかどうか確信が持てなくなりました。そして、Ruby Sass が大規模なスタイルシートを使用するケースには遅すぎることが、長い間明らかになっていました。私たちは、CSS を高速に生成し、かつ新機能を迅速に追加できる新しい実装が必要でした 。
なぜ Dart なのか？なぜ Dart なのか？ パーマリンク
私たちは多くの可能な言語を検討し、最終的にいくつかの理由から Dart に決定しました。第一に、Dart は非常に高速です。Dart VM は一般的に JavaScript VM よりもはるかに高速であり、初期ベンチマーク[2] では、大規模なスタイルシートの場合、Dart Sass は Ruby Sass より 5〜10 倍高速であり、LibSass より約 1.5 倍遅い程度であることが示されています。私は、慣用的な JS 実装よりも約 1.5〜2 倍高速であると推測していますが、確実には言えません。そして、Dart のパフォーマンスは常に向上し続けています 。
同時に、Dart は扱いやすいです。C++ よりもはるかに、そしてある程度はこのような大規模なプロジェクトでは Ruby よりもさらに扱いです。確かに、JavaScript ほど多くの人が Dart に精通しているわけではありませんが、言語の実装は外部からの貢献を受ける傾向はあまりありません。私は新しい実装のほとんどの作業を行う予定であり、Dart は私が個人的に最も快適に扱える言語です（Sass に取り組んでいないときは、Dart チームにいます）。Dart を使用することで、より多くの速度が得られます 。
Ruby や JavaScript とは異なり、Dart は静的に型付けされているため、すべての値の型はコードを実行しなくても特定できます。C++ とは異なり、ガベージコレクションされているため、後片付けを心配する必要があまりありません。これにより、記述、変更、および保守が容易になります。おそらくもっと重要なことは、他のプログラミング言語への翻訳が容易になることです。これにより、LibSass が新機能をより迅速に取得するのに役立ちます 。
Dart を選択した最後の理由は、他のいくつかの言語だけが誇ることができるものです。それは、JavaScript との互換性です。Dart は JavaScript にコンパイルでき、これは Node.js で直接使用したり、場合によってはブラウザで実行したりできます。node-sass 上に構築された Sass エコシステムの大部分があり、Dart Sass の JS バージョンを node-sass とできる限り API 互換性を持たせることを目指しています。これにより、既存のツールやビルドシステムに簡単に組み込むことができます 。
唯一の欠点は、速度が低下することです。Dart Sass は、Dart VM で実行するよりも V8 で実行する方が約 2 倍遅くなります。ただし、これにより、Ruby Sass よりも 3〜4 倍高速になります。最終的には、JS コンパイルされたバージョンのユーザーが、できる限り摩擦なく Dart VM バージョンに移行するための簡単なパスも提供したいと考えています 。
他の実装はどうなるのか？他の実装はどうなるのか？ パーマリンク
LibSass の開発については何も変更されていません。Michael は Sass 3.5 の機能を追加するために懸命に取り組んでおり、新しい言語機能が追加されるにつれてそのプロセスが継続されると予想されます。唯一の違いは、LibSass が、妥当な パフォーマンスを備えた唯一の実装ではなくなるため、そのバージョンをリリースするために最新バージョンの言語と厳密に互換性がある必要がなくなることです。
柔軟性が向上すると、ユーザーが最も必要とする機能を優先する、より高速な LibSass リリースにつながります。厳密な互換性とは、CSS カスタムプロパティのサポートのような重要な機能が、対応する Ruby Sass リリースにあった:root 統合のようなすべての小さなトリッキーなエッジケースも実装されるまでリリースできないことを意味していました。可能な限り多くの互換性を目指しますが、それが速度を妨げることはありません 。
一方、Ruby Sass は、新しいメンテナーが現れない限り、最終的には廃止されます。私たちは、移行を突然にしてエコシステムを分断するリスクを冒したくありません。Chris と私は、1年間メンテナンスを行うことを約束しています。これには、Dart Sass の新しい追加機能と同期して言語を維持することが含まれます。その期間後にメンテナーとしてボランティアをする人がいれば、来年中にその人にメンターをつけ、コードベースを教えることに非常に興奮します。しかし、誰も名乗り出ない場合、Ruby Sass は正式に非推奨と見なされ、メンテナンスされなくなります 。
Ruby Sass の開発を停止するという決定を軽々しく行っているわけではないことを強調したいと思います。これは大きな変化であり、私にとっては簡単なことではありません。私は約 10 年間 Ruby Sass に継続的に取り組んでおり、その歴史を手放すのは難しいことです。しかし、Chris と私はこれを十分に議論し、これが正しい動きだと確信しています。私たちは Sass に費やす時間が限られており、最大規模のユーザーの多くにとって実行不可能であるほど遅い実装にその時間を費やすことはもはや意味がありません 。
次は？次は？ パーマリンク
Dart Sass の最初の安定バージョンをリリースする前に、私たちのToDoリストにはいくつかの大きな項目があります 。
-
完全な sass-spec 互換性。Dart Sass が間違った動作をする言語の隅がまだいくつかあります。特に
@extendに関してです。個々の非互換性に対処することが特に難しいとは考えていませんし、sass-spec は非常に包括的なので、失敗するスペックの数をゼロになるまで着実に減らしていくことが問題です 。 -
npm パッケージでの node-sass
render()のほぼ互換性。node-sassrender()API は、JavaScript の世界における LibSass の主なエントリポイントです。これは、ビルドシステムが Sass を実行する方法、ユーザーがカスタム Sass 関数を定義する方法、および Eyeglass がモジュールを Sass に渡す方法です。既存のエコシステムが JS コンパイルされた Dart Sass で動作するように、この API を十分に忠実にサポートしたいと考えています。 -
Ruby Sass での Dart Sass 互換性。Dart Sass が Ruby Sass と意図的に異なる場合がいくつかあります。特に、Ruby Sass の動作がバグと見なされる場合です。Ruby Sass に非推奨メッセージを追加し、最小限の中断で済む場合は、新しい 動作のサポートを追加する必要があります。
ブラウザでの Sass のサポートや、Dart VM 上の Sass の node-sass 互換ラッパーの提供など、最終的にはやりたいことがたくさんありますが、それらは最初の リリースを妨げるものではありません。
未来へ向けて未来へ向けて パーマリンク
今後数ヶ月で、Dart Sass を安定させ互換性を持たせ、Sass 3.5 の機能を LibSass に取り込むために多くの作業が行われるでしょう。2017 年初頭には、Dart Sass の安定版リリースと LibSass の 3.5 リリースが見られる可能性が高いと思います。その時点で、私たちは大きな機能に目を向け、Sass 4.0 とその全く新しいモジュール システムに向けて取り組み始めるでしょう。
Dart Sass は大きな変化ですが、刺激的な変化でもあります。これにより、新機能をより迅速にユーザーに提供し、それらの機能をより高速に実行できるようになります。ユーザーがリファレンス実装を簡単にインストールして実行できるようになります。また、初めて純粋な JavaScript Sass で Sass を実行するためのパフォーマンスの高い方法を提供します。メリットは大きく具体的であり、それらはコストに見合う価値があると確信しています 。