インモビインモビ

見たことがありますか Grugの繁殖開発者？これはURLを使用したエッセイです。穴居人が開発者になり、主に複雑さに対する集会である哲学をまとめるように書かれています。穴居人は愚かな単純な脳を持っています、それを手に入れますか？それには良い点があり、私はそれに大きく同意します。穴居人の角度は、それを読んで、脳に固執するための巧妙な癖です。

（読みにくいと思うなら、私は見たことがあります 「翻訳」）。

バックエンドアーキテクチャに関しては、Grugが意味することに関連するのはかなり簡単だと思います。複雑な要件を備えた広大なシステム、互いに話し合っているサービス、API、サードパーティの依存関係、データ操作方法など。フロントエンド開発には独自の複雑さがないということではありませんが、CSSの少しを指すことはあまり明白ではありません。 それ、それが複雑さが大きくなったところです。

たとえば、2000行のCSSが終わりましたか？コンポーネントごとに3つのレベルのネストされたDOMを超えていますか？セレクターの特異性は平均ですか？ブラウザのサポート要件があまりにも遠くに戻ったときですか？入力ソースが多すぎるときですか？

私は確かに、おそらくそれを理解したり認めたりすることなく、 恐れている 彼らのCSSの。ミームが進むにつれて、他のバーのバースツールを蹴るかどうかは誰も完全に確信していないので、誰も触れたくありません。

テイラートロッシュオン 最近のChangelogポッドキャストは言った：

コードベースの一部があなたを怖がらせ始めている場合、すぐに注意が必要です。すべてのエンジニアが触れることを恐れているコードベースの一部がある場合、物事はさらに悪化します。それは嫌悪感で成長し、誰もがそこに出て外に出て蓄積したいからです。あなたはすべてを壊すことなくそれを捨てることができる方法について考え始めたいです。

テイラーがCSSについて話しているとは思わないが、私にとっては完全にマッピングしている。 CSSは、開発者が触れることを恐れている状況に陥る可能性があります。それが、私がスコープされているCSSで強気な理由の1つです（実際のCSSに対するためらいにもかかわらず @scope）、CSSモジュールやシャドウDOMのように。あなたが意図せずに他の場所でスタイルに触れていないというかなり高い自信でCSSを編集できるなら、それは良いことです。

現在、CSSのネイティブ機能であるCSSネスティングは、これをある程度助けていると感じています。ユニークなクラスを書くと、ネストされた方法で選択したものはすべて、クラス名を繰り返すことなく、そのクラスにscopedされます。加えて、それは人間工学的にちょうどいいです。しかし、かなり重要なゴッチャがありますが、確かに、キリアンバルホフのThe Gotchas of CSS Nestingを読むまで、私は本当に知りませんでした。ルールが適用される順序はファンキーになる可能性があり、特異性も予期しない場合があります。キリアンの一例：

main, #intro {
    & div {
        ...
    }
}

として終わる：

:is(main, #intro) div { ... }

これにより、0,0,1から移動します main div 1,0,1まで、それをはるかに具体的にします。

営巣するゴトカスがCSSの複雑さが野生になった究極の例であるかどうかはわかりませんが、それはほんの少しの潜在的な突起です。私はSASS全盛期に人々が指摘することを覚えています @extend 複雑なコードの臭いとして、それらは間違っていませんでした。

おそらく、NPMのスケールと普及のおかげで、疑わしいサードパーティコードの山は、フロントエンドの複雑さの懸念のもう1つの原因です。ミシェル・バーカーはこれに入ります フロントエンド開発の複雑さを減らす 彼女はジャック・フランクリンの最近の講演で反minatingしているところです。

ノードモジュールフォルダーをすばやく見ると、内部の複雑さのWebがすばやく公開されます。障害の単一のポイントは、使い古された「ハウスオブカード」のメタファーのように、スタック全体を倒すことができます。

依存関係を減らすと、私は手足に出かけ、将来の頭痛を救うという意味ではほぼ常に「価値があります」と言います。またはGrugが言うように：

ある日コードベースは理解でき、無grugは仕事を成し遂げることができます、すべてが良いです！

翌日不可能：複雑さの悪魔の精神がコードと非常に危険な状況に入りました！