- ブラウザが標準で提供するネイティブ機能をまず使えば、Webアプリを作る際に追加の言語やツールチェーンに依存する範囲を減らせる
- Reactは
props、state、コンポーネントのようなパターンでUI開発の信頼性を高めたが、開発の中心をHTMLからJavaScriptへ移した
- その間にW3C、WHATWG、IETF、TC39はWebの基本言語に数千もの改善を加え、主要ブラウザがそれを統合したことで、Reactが必要とされた理由の一部は弱まった
- HTML FirstはReactに満足している開発者を説得するというより、HTML中心のアプローチに関心のある人が考えを整理し、同僚と議論するための言葉を提供しようとする流れである
- Webの基本言語とブラウザ機能だけでも、高速でアクセシブルなソフトウェアを作れるのかを改めて問い直そうという、実務的な問題意識に近い
HTML Firstが目指す開発スタイル
- HTML FirstはWebソフトウェアを作るとき、HTML、CSS、JavaScriptとブラウザのネイティブ機能を優先する
- 核心は、Webプラットフォームの上に追加される抽象化レイヤーを減らすことにある
- 追加の言語やツールチェーンも、減らすべきレイヤーに含まれる
- 目標は、ブラウザがすでに提供している機能を中心に据え、必要な場合にのみその上にツールを載せる開発スタイルである
React以後に複雑化したWeb開発
- React以前は、インターフェースをHTMLで書き、HTMLが標準でサポートしていない部分をjQueryのようなツールで補うやり方が一般的だった
- 代表的な例は非同期リクエストの送信とDOM更新である
- Reactのようなライブラリは、従来のWeb開発におけるさまざまな問題を解決した
- 親要素から子要素へデータを明示的に渡す
propsとstateのパターンは、特定種類のバグを減らした
- UI、スタイル、動作をコンポーネントとして束ねることで、他人が作ったものを自分のコードベースへ簡単に導入できるようにした
- こうした利点を得るには、主にHTMLを書く方式から、主にJavaScriptを書く方式へ移行する必要があった
- JavaScriptはより複雑な言語として扱われる
- Reactが導入した多くの概念やツールも合わせて学ばなければならなかった
- 業界は複雑さが増したにもかかわらずこのトレードオフを受け入れ、こうしたライブラリはWebアプリを作る基本的な方法になった
- React以前の新規開発者はHTMLとCSSを先に学び、その後でJavaScriptを学んでいた
- React以後はJavaScriptとReactを先に学び、その後に残りを学ぶ流れへ変わった
Webプラットフォーム改善がもたらした再検討の契機
- W3C、WHATWG、IETF、TC39は、React型の手法が広がるあいだに、Webのネイティブ言語へ数千もの改善を追加した
- これらの改善はChrome、Safari、Firefox、Edgeに統合された
- その多くは、人々がReactを使っていた理由の一部を直接扱っている
- ソフトウェア開発コストが上がり、ブラウザ改善が広く展開されるにつれて、追加されたレイヤーが今でも本当に必要なのかと問う人が増えている
- HTML Firstの考え方は、まだ業界では少数派に属する
- このアプローチは、すでにHTML中心の開発に関心を持つ人が、自分の考えを強固にし、同僚と意思疎通するための言葉と概念を得るのを助けることに焦点を当てている
- 核心的なメッセージは、Webのネイティブ言語と機能を主に使うだけでも、美しく、高速で、使いやすく、アクセシブルなWebソフトウェアを作ることは可能であり、実用的で、合理的だということである
1件のコメント
Hacker Newsの意見
ここのアイデアは気に入っているが、正直 例が弱い
「可能ならスタイルと動作をインラインのHTML属性で定義せよ」という部分の例は、実際には動かなさそうだし、スタイルをさらに追加しようとすると、
ClassList.addに渡す文字列パラメータだけがどんどん大きくなる構造になる個人的には
button:active { background: green; }のほうがずっと読みやすいが、筆者は「動作の局所性（Locality of Behaviour）」というアプローチのために、これを複雑だと見ているようだ「ライブラリが必要なら、JavaScriptやカスタム構文中心ではなくHTML属性を活用するライブラリを使え」という話には同意するが、推奨例の「on input put me into #output」は、悪い例として挙げられているライブラリよりも不自然で、単にフレームワークなしのJavaScriptでも十分に見える
「HTMLにコンパイルされる隠れたレイヤーより『生の』HTMLを好め」という例としてRailsのERBタグヘルパーを使うなと言っているが、これらのヘルパーは、最小限のテンプレートで直接書くとかなり汚くなるものをいろいろ処理してくれる。例では、一意なDOM ID、Turboタグ、繰り返し処理のような現実的な部分が抜け落ちている
スタイル設定と動作は分離されるべきで、両者は参照だけでつながるのが、意味のある規模では唯一筋が通る
技術的には1つのPythonアプリにすべてのSQLデータベース接続とハードコードされたSQLを長い1ファイルに入れることはできるが、それが悪い習慣であるのと同じように、この原則も似て見える
この部分が混乱する: 「ライブラリが必要なら、JavaScriptやカスタム構文中心ではなくHTML属性を活用するライブラリを使え」
ところが推奨例として _hyperscript [0] を示している。これは カスタム構文中心のライブラリであり、HTML属性の中に新しく覚える必要のある言語のスクリプトを入れているだけだ。本気なのか分からない
[0] https://hyperscript.org
例もかなり弱い。素朴な解決策、つまり最初のTipsだけでも同じようにうまくいく
_という属性に難解なDSL文を値として入れる例は、本当に奇妙で分かりにくく見えるむしろ明示的な
onclickや他のイベント属性の中に素のJavaScript文を入れて、何が起きるのかすぐ分かるほうがよさそうだ趣旨は分かる。HTMLの 組み込み機能 を使うのはきれいで単純だ
だが10年前も実用的ではなかったし、今もそうだ。htmxのようなものがReactのようなより重い解決策より特に優れているとも感じない
こういうアプローチを見るたびに尋ねる質問はいつも同じだ。ドロップダウン、複数選択、日付ピッカーはどう見えるのか。ブラウザごとに日付ピッカーは存在するのか。はい。見た目と動作はブラウザ間で一貫しているのか。いいえ。スタイリングで揃えられるのか。これもいいえ
複数選択も似ている。複数項目を選ぶためにShift/Ctrlクリックを要求するのは、ユーザー体験の観点では完全に駄目だ。標準要素はいまだにそう動作し、変更できない。複数選択だけでなく通常の選択要素も見た目がひどく、概して変更しにくい
新しいフレームワークごとにこうした サードパーティ製コンポーネント が生まれるのには理由がある。組み込み要素だけでは十分ではないからだ。MDNのArrayページで組み込み機能が毎年増えても、自分のプロジェクトの90%がまだlodashに依存しているのと同じ理由だ。10年前より良くなったのは確かだが、まだ足りない
ユーザーは異なるブラウザを使うかもしれないが、1人のユーザーは訪問するすべてのWebサイトで同じブラウザを使う可能性が高い
だから自分の考えでは、日付ピッカーが1つのWebサイト内で全ブラウザにわたって一貫していることよりも、1つのブラウザ内で全Webサイトにわたって一貫していること のほうが重要だ。もちろんカスタム機能が必要なら話は別だ
リストから連続した10個や15個の項目を選びたいとき、現時点では Shift+クリック より良いUIをあまり知らない
すべてのWebサイトのUIコンポーネントがそれぞれ間抜けなスタイルを新しく発明するより、実際のサイトデザインを除けばブラウザのネイティブなルック＆フィールに従ってくれたほうがずっと良い。もちろんブラウザ側も、それを見栄えよくすることに気を配る必要がある
input要素はインタラクション方式がブラウザごとに大きく異なることで悪名高く、ほとんどの他のHTML要素は代表的な動作が1つに定まっているほとんどの主張には同意するが、この記事は少し矛盾しているように感じる。Tailwindを勧めながら、同時に「ビルド段階を避けよ」と言っているからだ
巨大な CSS/JS リソースを配布するのは、包摂性の原則にも反する。高速なインターネットや十分に高性能なコンピュータを持たない人も多い
実のところ、Tailwind が出力するクライアント側 JavaScript についてはまったく知らない。最後に触ったのは 2.x なので、変わった点があるかは確かではない
CSS のサイズについても自分の経験は逆で、Tailwind の出力は手書きの CSS よりたいていずっと小さかった
もちろん素の CSS にも反対ではないが、それも少なくとも同じくらい簡単にひどい状態にできる
ただし記憶では、完全な Tailwind が提供するすべての機能を提供しているわけではない。全体として Fresh は実質的に Preact と Twind の上に大きく構築されていて、まずそれらのライブラリを受け入れる必要があることを率直に示していない点がもどかしかった
この記事の文脈で勧めるには少し変だという点にはある程度同意するが、ビルド段階は極めてミニマルにできるし、成果物が依然として中身を確認できる CSS である点も良い
個人サイトで Tailwind を使っているが、それ以外はすべて素の HTML だ。スタイルを書くときに CLI を監視モードで動かすのは、特に気にならない
どちらも驚くほど速く、10,000 個以上でもパースできる
理論や単純な例では面白いが、これを適用した大きなプロジェクトと、実際にどのような違いを生んだのかを見てみたい
記事の前半にある目標は素晴らしいが、助言そのものには少し失望した。ごく基本的な状況以外でどう機能するのかがあまり見えず、その目標をどう達成するのかはなおさら分からない
Web プラットフォームを最大限活用することには賛成だし、複雑さをできるだけ減らすことにも完全に賛成だ。しかし、これらの原則がそれを達成するかどうかにはかなり懐疑的で、むしろ同じことをする複数の方法を作って複雑さを増やす可能性もあるように見える
善意で言えば、この原則を実際に検証したのか、それとも期待どおりに機能すると仮定しているだけなのか、このリストだけでは分からない
本気で尋ねている。人々はこの主張をよく持ち出すが、いつも理解できなかった
自分の見方では、Web の 95% は小規模から中規模のプロジェクトだ。ほとんどの技術はここに焦点を当てるべきだ。単純なプロジェクトには単純な解決策を使い、複雑さは後から追加すればよい
私たちが失った半ば客観的なものの一つはアクセシビリティだ。リンクをクリックイベントリスナー付きの div で不用意に再実装したせいで、サイトの大部分をキーボードで操作できない
これはかなり心配だ。規制が来れば、私たちが捨てたものを取り戻すために慌てふためくことになる
それでも、有名な「HTML ファースト」サイトの事例を見つけにくいという点にはある程度同意する。信じてはいるが、実際にうまく展開された事例は見たことがない。ただ、その理由は純粋に教育にあるのかもしれない。HTML が強力になった頃には、フロントエンド開発教育はすでにフレームワーク中心に深く固まっていた
著者が実際に 2 人以上が参加し、現行ブラウザの 99% をサポートするプロジェクトでこれをやったようには見えない。また、自分のコードも実行していないようだ。私の画面が味わい深くないだけかもしれないが、
onlickは div のハンドラではない動いているように見えるが実際には動いていない製品を作ると、彼らは理解しない。すると、過大に約束して過小に提供する道へ追い込まれる
単体テストのあまり知られていない利点の一つは、経営陣には見えないコードが接続される前に、より多くの品質保証を受けられるようにすることだ。最初の画面が出てからリリースまでの気まずい期間を縮めてくれる
1999 年に素の HTML、CSS、素の JS で最初の Web サイトを作り、Geocities でホストした
その後、PHP/WordPress/Yii/Laravel、Ruby/Rails/Sinatra/Jekyll、React/Typescript、ClojureScript でサイトやアプリを作ってきた
今では React、TSX コンポーネント、CSS-in-TS、Effects、Context が居心地のよい家のように感じる。ついに Web/フロントエンドのための完全なプログラミング言語が手に入った感覚だ。関数型・リアクティブプログラミングのような現代的原則の上に、フロントエンドのために明示的に作られた言語だ
ようやくソフトウェア開発ができるようになった。それ以前の HTML、CSS、素の JS、PHP は、ただのハックに近かった。Rails はフルスタックには良かったが、フロントエンドで輝いたわけではない
Web スタックがアプリにも対応できるようになったら、フレームワークを飛ばすつもりだ。今はサイトには十分かもしれないとは認める
今年は諦めた。もはや、バンドラーやトランスパイラ、そして付随してくるありとあらゆるガラクタを抱えた React、Vue、Angular の怪物たちと戦い続けるのは不可能になった
Node と npm は、作ってから数秒しか経っていないプロジェクトにさえ「深刻な脆弱性 7 件と致命的な脆弱性 8 件」があると投げつけてくる。何千ものファイルをダウンロードしなければならず、その中には boolean 値のラッパーみたいなものまで入っていることがある
Python のバックエンドサーバーがフロントエンドも一緒に配信していた時代は、自分にとっては終わったように思う
実際のところ、あなたにも、ほかの誰にも、重たい JavaScript フロントエンドの肥大化は本当に必要ない。単に拒否すればいい
バックエンドやキャッシュから軽量なページを配信し、どうしても必要なら気の利いた処理は CSS でやればいい
高速なレンダリング時間と、世界中からのアクセシビリティを手に入れられる
ただ正直に言うと、この記事の例は変だ。エラーやさまざまな便利機能を自動で出力してくれる Phoenix のフォームヘルパーではなく、なぜ素のタグを手書きしなければならないのか分からない。精神は理解できる
核心的な論点は、ユーザーが View Source を押して何が起きているのか理解できるべきだ、ということのように思う。Web サイトなら同意する
Web アプリ、少なくとも 50 行を超えるものなら、型のある言語を使いたくなる可能性が高い。技術的には、特殊コメントによる型注釈と TypeScript コンパイラを付けた
.jsを使うこともできるが、あまり楽しくはなかった以前はこの考えにかなり強く惹かれていたし、最近のほとんどのサイトが読めない HTML の 1 行の塊になっているのは悲しい。依存関係なしに単一の HTML ファイル 1 つで全部をデプロイすることには、美しさと優雅さがある。ネットワークリクエストは 1 回で済む
結局、編集を楽にするために「ビルドシステム」を作りはしたが、自分のビルドシステムは
catだ。人間が読める 1 つのファイルに入った、自己完結型のポータブルソフトウェアになるわけだ同じ文脈で、Web 開発のいちばん素晴らしい点は、Notepad と標準ブラウザだけで最初の対話型プログラムを作れることだ。HTML ファイルをブラウザにドラッグ＆ドロップするだけでいい。魔法のようだ
追記：自己完結型 HTML の予想外の利点を見つけた。ソフトウェアがビット腐敗に強くなる。昔のプロジェクトを Web Archive で開いてみたら、外部 JS ファイルが保存されていなかった。悲しい。一方これは、すべての JS が HTML の中にあるのでちゃんと読み込まれる。勝利だ
https://web.archive.org/web/20210508133239id_/https://andai....
これは昔の SodaPlay Constructor へのオマージュだ。エディタは作れなかった。ソースを見るのは自由だ
DOM ビュー、ネットワークタブ、ヒープビュー、組み込み JavaScript の整形表示機能がある
もちろん「ソースを表示」は今でも重要だが、HTMX の人たちが言うほど、その重要性が今も絶対的なのかは疑問だ
今は
data:URL があるので、これはさらに簡単になった。HTTP サーバーさえ不要なfile://URL の問題を避けるのにも役立つhttps://github.com/tc39/proposal-type-annotations
「動作の局所性」は、あまりにも大雑把に定義されたルールです。関心の分離に反するものを新しい名前で呼んでいるだけです
CSSを遠隔の不気味な作用と呼ぶのも大げさすぎます。良い原則はいくつかありますが、論証はかなり弱く、もっとずっと単純に言えたはずです
「赤くて弾むボタンを青くて揺れるボタンに変える」ために、どのクラスに新しい実装が必要で、どれを再利用できるのかを探して、3〜7個のインターフェースやクラスの迷路をたどらなければならないなら、10分で済みそうだった変更が、半日かけてコンパイラや以前の開発者を心の中で罵る作業になります
もちろん抽象化はすべきですが、1つのコンポーネントを修正するために6つのファイルを触らなくてもいいように、動作を一か所にまとめる方法も必要です
https://htmx.org/essays/locality-of-behaviour/#conflict-with...
Tailwindを使うということは、サードパーティライブラリがCSS仕様を代わりに抽象化し、その抽象化された準仕様がビルド設定に従って守られると信じることになります
何を分離すべきなのか？ どの線に沿って分けるのか？ その線はどう決めるのか？ どの関心事を別のクラス、フレームワーク、マークアップなどへ切り出すのがいつ妥当なのか？ いつは一緒に置いておくほうがよいのか？
答えは「状況による」です
何も分離しなければスパゲッティになり、いつでもどこでも最大限に分離すれば、スパゲッティと同じくらい保守しにくい過剰抽象化コードになります
デフォルトがうまく機能するなら、カスタマイズは必須ではありません。そのためCSSなどによる効率面の利点は、単純さより後回しになります
HTMLを文書／表現言語と見るなら、スタイリングを否定することはできません。CSSはスタイリングだけでなくアニメーションも追加します
いずれにせよCSSはアスペクト指向プログラミングと見ることもできます
ここで描写されている本当の問題は、言語やフレームワークをまたぐ優れたツールが不足していることです
可能なときにより単純なフレームワークに頼るのは理にかなっています。しかし、ビルドステップをなくそうという発想は、ほとんど完全な冗談に近いものです
ビルドステップをより効率的にし、必要なら本番環境に含めなければよいのです
また、なぜHTMLに属性を追加することを優先すべきなのかも分かりません。文書を作ってWebサイトとしてホスティングするのでしょうか？ それ以外のどんな世界で、それが好まれるのでしょうか？ CSSは探索しにくいものではなく、むしろより良いCSSの慣行を促すべきです
フロントエンドのスクリプトがスタイリングを曖昧にすることはありますが、必要なければそのやり方に依存しなければよいだけです。JavaScriptで属性を入れるよりスタイルシートに入れるほうが簡単なので、これはすでに当然の話です
必要なものだけを使えという類の助言の一部は筋が通っていて明白です。しかし残りは混乱しているか、露骨にばかげています。HTMLページ全体をコピーできることがなぜ良いことだと仮定されているのかも分かりません。正直どうでもよく、いくつかのページのHTMLを見られなくても、HTMLを学ぶためのリソースは文字通りすでに何百万とあります
全体として首をかしげます
この記事全体がアンチパターンであり、悪い助言です。複雑なWebサイトを作る中で成長痛を経験したことのない人が書いたように読めます
最初は私たちもこのようにWebサイトを作っていましたが、副作用、衝突するクラス名、ひどい内部可観測性のせいで壊れ始め、Reactが救いに来ました
望ましいパターンはプログレッシブエンハンスメントであり、出力はきれいで圧縮されたHTMLであるべきで、JavaScriptがそれを補強するべきです。つまりビルドステップが必要です。この記事の助言とは正反対です
バックエンドですでにNodeJSを使っていないなら、本当に必要なときでない限りReactJSは避けたほうがよいです