CSSを書くことの禅
これは未来だと私は言いたいですが、私たちはすでにそれを実行しています。
CSSを嫌うのが流行です。それには多くの理由がありますが、結局のところ、CSSは予測不可能だからです。スタイルルールを調整して、まったく関係がないと思っていたレイアウトを誤って壊してしまった経験がないのであれば（通常、出荷しようとしているとき）、あなたは初心者であるか、私たちよりもはるかに優れたプログラマーのどちらかです。
そこで、JavaScriptコミュニティは腕まくりをして取り組みました。過去数年間で、CSSを動作させることを目的としたライブラリが急増しており、これらは総称してCSS-in-JSと呼ばれています。
あなたが気づいていないかもしれないことは、CSSの最大の問題はCSS-in-JSなしで解決できるということです。それらの問題がなければ、CSSを書くことは単に許容できるだけでなく、楽しいものです。また、CSS-in-JSが導入する追加の問題に対する解決策を見つける必要もありません。
この記事は、CSS-in-JSコミュニティが行ってきた努力を批判するものではありません。これはJSエコシステムで最も活発なコーナーの1つであり、毎週新しいアイデアが生まれています。そうではなく、私の目的は、実際には本物のCSSを使用したシングルファイルコンポーネントに基づいた代替アプローチが、なぜ非常に楽しいのかを説明することです。
CSSの最大の問題
CSSのすべてはグローバルです。そのため、あるマークアップ用に意図されたスタイルが、別のマークアップに影響を与えることがよくあります。そのせいで、開発者は、ほとんどの場合、RSIのリスクを高めるだけの、野放しの名前空間規則（「ルール」ではない。適用するのが非常に難しいため）に頼ることがよくあります。
チームで作業しているときはさらに悪化します。他の人が書いたスタイルに誰も触れる勇気がありません。それらが何をしているのか、どのマークアップに適用されるのか、そしてそれらを削除するとどのような災害が起こるのかが不明確な場合が多いためです。
これらすべての結果が追加のみのスタイルシートです。どのコードを安全に削除できるかを知る方法がないため、比較的小さなプロジェクトでも、既存のスタイルを別の、より具体的なスタイルで元に戻すことがよくあります。
シングルファイルコンポーネントがすべてを変える
SFCの背後にある考え方は単純です。コンポーネントのスタイルと動作を記述する<style>および<script>属性を含む（オプションで）HTMLファイルにコンポーネントを記述します。Svelte、Ractive、Vue、Polymerはすべてこの基本的なパターンに従います。
（この記事の残りの部分では、明らかにSvelteを使用します。ただし、テンプレート言語の使用を考えるとぞっとする場合は、あなたの恐れは的外れですが、それは別の日のトピックです。SFCでJSXを使用できるVueを使用してください。）
その結果、いくつかの素晴らしいことが起こります。
- スタイルはコンポーネントにスコープされます。もうリークはなく、予測不可能なカスケードもありません。また、競合を防ぐために設計された難解なクラス名もありません。
- あなたのものを壊しているルールを見つけるために、フォルダ構造を探索する必要はありません。
- コンパイラ（Svelteの場合）は未使用のスタイルを識別して削除できます。もう追加のみのスタイルシートはありません！
それが実際にどのように見えるかを見てみましょう。
すべてのコードエディターはすでにCSSについて知っているので、追加のJS疲労を誘発するツールを使用せずに、オートコンプリート、リンティング、構文の強調表示などが得られる可能性が高くなります。
そして、それは単なるキャメルケースのいたるところに引用符がある偽物ではなく、本物のCSSであるため、私個人が欠かせない「開発ツールで調整し、ソースコードに貼り戻す」ワークフローを利用できます。CSSソースマップがすぐに利用できるため、問題の行をすぐに特定できます。これの重要性を誇張することはできません。WYSIWYGモードでは、コンポーネントツリーの観点から考えていないため、この厄介なスタイルがどこから来たのかを把握するための堅牢な方法を持つことが不可欠です。誰か他の人が最初にコンポーネントを書いた場合は、なおさらです。（これはCSSワークフローにおける最大の生産性向上であると約束します。ソースマップなしでスタイルを書いている場合、ほぼ確実に多くの時間を無駄にしています。私はそうでした。）
Svelteは、スコープを実現するために、セレクターを変換します（影響を受ける要素にも適用される属性を使用しますが、正確なメカニズムは重要ではなく、変更される可能性があります）。未使用のルールについて警告し、削除してから、結果を縮小し、それを.cssファイルに書き出すことができます。また、もしそうしたい場合は、スタイルをカプセル化するためにシャドウDOMを使用して、Webコンポーネントにコンパイルする実験的な新しいオプションもあります。
これはすべて、CSSが（css-treeを使用して）解析され、マークアップのコンテキストで静的に分析されるためです。静的分析は、動的に実行時にスタイルが計算される場合よりもはるかに困難な、スマートな最適化やa11yヒントなど、あらゆる種類の将来のエキサイティングな可能性への扉を開きます。私たちはまだ始めたばかりです。
しかし、[x]を実行するためのツールを追加できます！
動画に対するあなたの反応が「まあ、TypeScriptを使用して、各エディター用のプラグインを作成すれば、すべてのオートコンプリートと構文の強調表示などを取得できる」というものであれば、言い換えれば、CSSと同等のものを実現するために、補助プロジェクトの艦隊を構築、文書化、宣伝、および維持することが理にかなっていると考えるなら、まあ、あなたと私は決して同意しないかもしれません！
まだすべての答えを持っているわけではない
そうは言っても、CSS-in-JSは、いくつかの未解決の質問に対する答えを示しています。
- npmからスタイルをインストールするにはどうすればよいですか？
- 単一の場所に定義された定数を再利用するにはどうすればよいですか？
- 宣言を構成するにはどうすればよいですか？
個人的には、これらの問題は、上記のアプローチの利点を上回るとは感じませんでした。あなたは異なる優先順位を持っている可能性があり、それがCSSを放棄するのに十分な理由となるかもしれません。
しかし、最終的には、どうせCSSを知る必要があります。好きでも嫌いでも、少なくとも学習する必要があります。ウェブの管理者として、私たちには選択肢があります。ウェブ開発の学習曲線をさらに急にする抽象化を作成するか、CSSの悪い部分を修正するために協力します。私はどちらを選ぶかを知っています。