ハクソク

世界を動かす技術を、日本語で。

JavaScriptはもう必要ない: 現代のCSSが素晴らしい理由の概要

270日前原文(lyra.horse)

概要

  • 現代のWeb開発 ではJavaScriptフレームワークの肥大化が問題視されている現状
  • HTMLとCSSのみ でも多くの機能や美しいデザインが実現可能であることの提案
  • モダンCSS の新機能や書きやすさの向上についての紹介
  • パフォーマンス・アクセシビリティ の観点からCSS活用の利点を解説
  • JavaScript不要 なサイト構築のアイデアやCSSの力を再評価する内容

モダンWeb開発の課題とCSSの再評価

  • JavaScriptフレームワーク （例：React, NextJS）の肥大化によるパフォーマンス低下問題
    • 数秒のロード時間や ランダムなエラー 発生
    • node_modules フォルダの巨大化によるストレージ圧迫
  • 多くのサイトで 追跡スクリプトや悪いコード が混在し、ユーザー体験を損なう傾向
  • Webフレームワーク 自体にも適材適所が存在し、全てのサイトに必要ではない
  • HTML/CSSのみ で実現できる機能の多さに注目
    • eコマースやダッシュボード以外では JavaScript不要 の場合が多い

CSSへの誤解とその実力

  • CSSが 難しい・使いにくい という誤解
    • 多くの開発者が CSS基礎を学ばず に敬遠しがち
    • CSSは単なる装飾言語ではなく、 強力なドメイン特化言語
  • FlexboxやGrid などのレイアウト機能の進化
    • DevToolsのサポートにより、 直感的な操作 が可能
  • SassやTailwind などの登場は、過去のCSS記述の難しさへの対応策
    • 近年は CSS自体の進化 で書きやすさが大幅に向上

モダンCSSの新機能と書きやすさ

  • ネスト記法 による可読性・保守性の向上
    • 親子関係や状態疑似クラス（&:hover等）が 直感的に記述可能
  • 相対カラー や color-mix() など、色操作の柔軟性
    • JavaScript不要で ダイナミックなカラースキーム 生成が可能
  • 新しいメディアクエリ構文 や lh単位、 scrollbar-gutter など、細やかなUI調整
  • Baseline によるブラウザ対応の明確化
    • 主要ブラウザでの サポート状況が一目で分かる

CSS活用のメリット

  • JavaScript無効化環境 でも問題なく表示可能
    • セキュリティ・プライバシー重視ユーザーへの配慮
  • HTML/CSSのみ で実装できる機能例
    • ボタンのホバー効果、トーストアニメーション、入力バリデーション等
  • パフォーマンスの高さ
    • CSSアニメーションは ブラウザのコンポジタスレッド で処理されるため、 滑らかさ・省電力性 が向上
    • 低スペック端末でも快適動作
  • 開発・保守コスト削減
    • 冗長なJavaScriptや外部ライブラリの導入不要

CSSを選択する理由

  • ユーザー体験向上 と パフォーマンス最適化
  • アクセシビリティ・セキュリティ の観点での優位性
  • 新機能の充実 により、CSSだけで十分な表現力を獲得
  • 必要に応じてWeb Animations API を利用し、JSからCSSアニメーションを制御可能

まとめ

  • CSSは過小評価されがちだが、現代のWeb開発において再評価すべき技術
  • JavaScriptを多用する前に、CSSやHTMLで実現可能かを再検討 する姿勢が重要
  • モダンCSSの活用 で、より速く・美しく・アクセシブルなWeb体験の提供が可能

Hackerたちの意見

まあ、こういう記事には賛同しやすいタイプなんだけど、「一部のユーザーはJavaScriptを望んでいない」っていう価値提案には全然共感できないな。ちなみに、俺はアーチユーザーで、ブラウザスクリプトやウェブクローリングにかなり時間を使ってきたし、普通の人よりも信者って感じなんだけど。そんなニッチなユーザーの好みは、ほとんど無視されるべきだと思う。確かに「noscript」な世界がもっと良くなればいいけど、個々の「草の根」運動が「JavaScriptなし」をその有用性の一部にするべきだとは思わない。CSSが勝つ理由は、IE6の時代に戻るような、非常に皮肉な呼びかけよりもずっと説得力がある理由がたくさんあると思う。全体的に見れば、この記事に関してはちょっとしたマイナーなポイントだけど（ちなみにこの記事は素晴らしいと思ってる）、今の「トレンド」をそのまま言ってるだけなんだ。

└

同意するよ。noscript派は役に立たないし、ターゲットにする価値も感じない。ただ、逆の側面をもっと強調したいんだ。コードを少なく書いてプラットフォームを使うことは、ものすごく価値があると思う！少なくして、ブラウザにやらせるのはすごくいい勝利だよね。

└

ちなみに、俺はnoscriptを使ってインターネットを利用してるけど、JavaScriptが必要なサイトでも全然使えるよ。拡張機能から有効にすればいいだけだから、普段使ってるサイトには全く邪魔にならないし、パフォーマンスやバッテリー、セキュリティにもいい感じ。noscriptを一週間以上使ってみたことある？君の視点はちょっと誤解を招くかもしれないな。俺もnoscriptを使う前は全く同じことを思ってたから。ちなみに、俺はこのブログ記事の作者だよ。

└

JavaScriptを望まないユーザーについては軽く触れてるけど、ほとんどの記事はCSSの機能を見せることに費やされてるね。もう一つの動機はパフォーマンスだけど、動機についてはあまり強調してないと思う。個人的には、技術を見せることに焦点を当てるのは生産的だと思うよ。

└

一部のユーザーはJavaScriptを望んでいない 正解、ほとんどの人がそうだね。

└

僕にとっての魅力は、数バイトの宣言的なCSSで、たくさんの行数が必要な命令的なJSよりも簡単に実現できることだね。変な挙動も少なく、フレームワークの互換性の問題も減るし、インタラクティブになるまでの時間も短い。noscript環境で動くのも、ただのおまけみたいなもんだ。でも、心の奥ではDSSSLが恋しいな。

今日はベースラインの広範な利用可能性について知ったよ。もっと健全なフロントエンドアプリケーション（ロジック）技術に向かって進んでほしいな（今のリーダー、Typescript NextJSはそれじゃないと思うけど）。でも、最近のCSSはかなり健全に感じられるようになってきたのはありがたいね。

└

Vite（現代のフロントエンドフレームワークの大部分で使われている）は、デフォルトでベースラインの広範な利用可能性のためにプロダクションバンドルをビルドするよ: https://vite.dev/guide/build.html#browser-compatibility

名前にハイフンが含まれていれば、要素を自由に作ってもいいよ 意味のあるタグを機械可読性のために使うことはもう無理かな。

└

既に自分のニーズに合った要素があるなら、たくさんのdivを使うよりずっと読みやすいよね。わざわざ新しい要素を作る必要もないし。

└

それに、ハイフンがなくても大丈夫だよ！そのまま使えばいいんだ。

└

最近の機械可読性の使い道って何なの？

うーん、CSSの構文は本当にクソだよね。10〜15種類の言語を知ってるけど、CSSが一番読みづらくて理解しにくい。CSSよりx86アセンブリの方が理解しやすいよ。CSSは基本的にレンダラーを動かすための事前トークン化された入力だけど、半端にしか作られてなくて、本当のトークンでも人間が書けるものでもない。RFCの中で「こういうのはやめとけ」っていう例としてASN.1の代わりにCSSが入るべきだと思う。

└

同感だな。HTML/CSS/JSの中で一番嫌な部分だと思う。

└

10〜15種類の言語を知ってるけど、CSSが一番読みづらくて理解しにくい。CSSは15言語を知ってても難しいよね。多くのプログラミング言語を理解して、その機能の一部を書けるけど、全部を知ってるとは言えないな。それには日々の努力が膨大に必要だと思う（参考：https://en.wikipedia.org/wiki/Illusion_of_explanatory_depth）。僕にとってCSSを理解する最良の方法は、レンダリング後に評価することだね。何十年も書いてきたから。

そのウィッシュリストのCSS機能のうち2つは既に仕様として存在してるよ：> n-th child variable sibling-index()とsibling-count()を見てみて。https://developer.mozilla.org/en-US/docs/Web/CSS/sibling-ind... > 再利用可能なブロック @functionと@mixinのドラフト仕様を見てみて。https://drafts.csswg.org/css-mixins-1/ と https://css-tricks.com/functions-in-css/ どちらもChromeでは既に使えるよ。

ネスティングが追加されたのは本当にありがたいけど、全体的に見ると、CSSって本当に変な言語だと思うし、正直言ってひどいと思う。もしかしたら私が使い方を間違えてるのかもしれないけど、すごく複雑でごちゃごちゃしてる。時々、ただ古代のルーンを並べ替えてるだけみたいに感じることもある。テキストのスタイリングと、ブロックやインライン要素のレイアウトシステムが組み合わさってるけど、継承はなくて、ただの包含だけ。スタイリングとレイアウトを組み合わせるのは間違いだったと思うし、根本的に壊れてるものにどんどん機能を追加しても、修正にはならない気がする。

└

これは全部本当だね。でも、これが現状なんだ。もっと強い概念的な整合性を持ったモデルが設計できて、CSSをコンパイル先として使えるんじゃないかって考えちゃう。例えば、コンテナクエリや計算を使えば、数学だけでより一貫性のあるレイアウトシステムが実装できるかもしれない。残念ながら、今あるプリプロセッサ言語は、CSSの半端なアイデアの上にさらに半端なアイデアを重ねるだけで、文法糖は良いっていう原則に従ってる。

└

CSS1は1996年頃、実質的にはスタイリングだけだった。主な目的は、HTMLからフォントタグなどを取り除くことだった。CSS2は限られたレイアウトを含んでたけど、人気のあるブラウザのサポートが遅れたせいで、ほとんど誰も標準を学ばず、特定のブラウザがなんとか部分的に動くようにするためのスタイリングの雰囲気だけを学んだ。

└

「CSSに対する多くのネガティブな意見は、使い方をよく知らないことから来ていると思う。多くの開発者は、もっと面白いJavaやTypeScriptを学ぶためにCSSの基本をスキップして、その後理解できないスタイリング言語について文句を言う。」って記事に書いてあったけど、これは君みたいな人のことを言ってるよ。ちゃんと学ぼうとせずに、自分が知っていると思い込む傲慢な人たちのこと。

CSS初心者におすすめの本ってある？仮にバックエンド開発者が、ブログやチュートリアルみたいな自由な冒険じゃなくて、現代のCSSを学べるようなガイド付きの本があればいいんだけど。

JavaScriptなしで、ウェブサイトのライトモードとダークモードを切り替えるボタンがあるべきだってずっと思ってた。でも、（LLM以前の時代に）どうやってやるか分からなくて諦めて、結局JavaScriptを使った。そろそろそれを更新する時だね。このブログがやる気をくれた。

└

それって単に prefers-color-scheme じゃない？

└

いいけど、設定を持続させるためにはやっぱりJSが必要だから、あんまり役に立たないかもね。テスト用には、ブラウザのスキームをオーバーライドできる拡張機能があるよ（Firefoxの場合だけど）。

CSSの最悪なところは、たくさんの人がそれを学ぼうとしないで、1日使わされた後に強い意見を持つことだよね。

└

20年前にCSSを学んだんだけど、個人的には「クソスタイルシート」って名前に変えるべきだと思ってる。でも、それだと「カスケード」っていう主要な欠点が消えちゃうんだよね。いろんなことから学んだように、「継承」ってあんまり良いアイデアじゃない。特に5人のチームでグローバルに適用されるものに関しては。「ここを調整したら、あっちの同僚がやってることが全部台無しになる」ってのは良い機能じゃないよね。主な機能は、特定のルールを覆すための複雑なルールを与えること。これが全ての基盤になると、頭痛の種になる。ターゲットを絞るための複雑な方法を提供して、時間が経つにつれてさらに複雑になっていった。まともな人なら、こういうのを避けることを学ぶはず。そうしないと、.foo > .bar:nth-child(2n) ~ .baz みたいなことになっちゃう。で、それを調整すると、結局マークの全く関係ないものを壊すことになる。しかも、最もシンプルなレイアウトを作るのも一苦労だった。やったことあるけど、これは挑戦だと思って取り組んだ。でも、挑戦であるべきじゃなかった。ここは飛躍的に改善されたけど、最初からそうあるべきだった。ルールをカスケードさせることじゃなくてね。他の批判、構文とかは細かすぎて重要じゃない。使えることができるなら、構文は何でもいいよ。でも、実際にはそうじゃなかったし、今もそうじゃない。ウェブページのレイアウトを作るのにフルタイムの仕事にするべきじゃない。

└

CSSの最悪なところは、多くの人がそれを学ぶことを気にしないことだ。 どうして人々は20以上の仕様を深く学ばずにCSSを使うなんてことができるの？それは許せない！ツールを使うときに問題があるなら、人を責めるんじゃなくてツールを見直すべきだよ。人は変わらないから。バンドソーを使うときにもっと気をつけろって言わないで、安全機能を取り付けるんだ。

そうなんだけど、そのラジオタブってアクセス可能なの？WAI-ARIAのガイドラインに従うなら、アクティブなタブが変わるときにaria-selectedやtabindex、aria-controlsをJSで更新する必要があると思うんだけど。間違ってたらいいな。アクセシビリティって、しばしば後回しにされがちだし、HTML/CSSを直接使えばアクセシビリティが自動的に備わっているって思われていることもあるよね。アプローチを選ぶときに、これを念頭に置いておくといいかも。

└

記事読んだ？著者は、複数の場所でアクセシビリティについて具体的に触れていて、ブラウザのバグを回避するための追加の手段を講じているよ。

└

そう思う？ブログを読む人たちが自分の例を基にウェブサイトの一部を作るかもしれないから、アクセシブルであることを確実にしたいと思ってる。アクセシビリティのバックグラウンドはないけど、できる限り頑張ってるよ。いろんなアクセシビリティツール（例えば、キーボードナビゲーションやスクリーンリーダー）で自分の作ったものを試してみたり、どう扱うべきかを調べたりしてる。ラジオタブに関しては、キーボードでナビゲートできて、スクリーンリーダーとも連携していて、WAI-ARIAの例で言われているコンテンツへのタブ移動の実践に従っているよ。