そんなに多くは要らないよ：ループ、属性の条件分岐、ノードの条件分岐があれば十分。実際、これを言語を超えて実現できるかもしれない。

でも、Reactはテンプレートじゃないよね。

TC39のシグナル提案で、その一部が進展しているよ。

もう大丈夫だよ。LLMと暗号通貨のおかげで、この無駄がちっぽけに見える。

双方向データバインディングとjsxのクローンがあれば、みんなが本当に必要とするものはそれだけだと思う。

繰り返し学んできた基本的な教訓は、APIやABIは最終的なものではないってことだ。よくわからないけど、getElementByIdは25年間も安定してるよね。「安定したAPIなんて存在しない」って言うのは、持続可能なインターフェースを作れない人たちの言い訳だよ。これは個人的な諦めの表れであって、宇宙的な不可能性じゃない。反例はたくさんあるし、アプリケーションのニーズは他のニーズと同じように無限だよ。これらのニーズを満たすためには、新しいAPIを追加するべきで、動いているものを壊すべきじゃない。

ほとんどの有用な時間を、みんなが回避しようとしている古いものとして過ごすことになる。でもその過程で、基本的な機能がもう一段階支えられているんだ。ユーザーの要求によって新たなギャップやユースケース、盲点が常に発見されるから、漸進的なアップデートはそれだけでは価値がない。

ウェブ標準のすべての機能は、手間をかけて維持しなければならない余分なコードを意味するし、標準準拠のブラウザを作ろうとする誰もが実装しなければならない余分なコードでもある。https://servo.org/ のようなプロジェクトが、時間をかけて追いつくチャンスがあることを見たいんだ。常に拡大する範囲を追いかけるのではなくてね。ウェブプラットフォームには、ネイティブプラットフォームが持っているあらゆる機能があってほしい（もちろんプライバシーやサンドボックスの制約はあるけど）。そしてウェブ開発者の体験が素晴らしいものであってほしい。でも、これらは追加の複雑さの影響とバランスを取る必要があるよね。この場合、ネイティブテンプレーティングは本当に開発者の体験を改善するのかな？メリットがコストを上回るとは思えない。

私たちが何度も学んできた基本的な教訓は、APIやABIは最終的なものではないってこと。ウェブではそうじゃない。一度ウェブに出たものは、その形のまま永遠に依存する人がいるから。だから、20年前の決定から「スムーシュゲート」に至るAPIが今でも存在するんだよね。https://developer.chrome.com/blog/smooshgate

だからこそ、バージョンがあって古いバージョンとの後方互換性を維持してるんじゃないの？「古い」インターフェースを変えないのもそのためでしょ？

これがXSLTを再現しようとしてる感じがするのも仕方ないかな。私はXMLのファンじゃなかったけど、XSLTはエコシステムの素晴らしい特徴だったよね。今でもブラウザで広くサポートされてるし！XMLがダメなところで流行ったのは本当に残念だった—設定やIPCなど—でも、XSLTの驚くべき変換能力を持つマークアップ言語として輝くところでは衰退してしまった。XSLTが失敗したのは、実際のDSLであり、宣言的で純粋な関数型DSLだからだと思う。人々はDSLについて大きなことを語りたがるけど、結局は人気のあるホスト言語の手続き的意味を抽象化できない単純な構文の演習になってしまう。難しいタスクを簡単にするようなデザインされたDSLに直面すると…人々は学ぶ気になれないんだよね。

「テンプレーティングに良い構文がどういうものか、我々は知っている。」って聞いて、思わず笑っちゃうよね。知らないよ。この記事は、パフォーマンスやセキュリティが見栄えの良いレイヤーでは解決されないことを受け入れられていない。これは、人気の要求が常識を圧倒する時に繰り返されるウェブ技術のミスだよ。なぜなら、最下層の労働力が違いを理解できず、すべてのデザイン決定を左右するから、採用がトレーニングやメンテナンスよりも重要になるから。より良いパフォーマンスやセキュリティが欲しいなら、測定しなきゃダメで、見た目を気にして目を背けてはいけない。

テンプレートの良い構文がどうあるべきか、実はよくわからないんだよね。HTML自体が複雑すぎるし、BladeやHTMXみたいなものでさらに複雑にしようとした人もたくさんいるし。なんか、俺はHTMLよりもJSの方が好きなんだよね。JSXを使ったReactコンポーネントはいいバランスだと思う。みんながそう思うわけじゃないけど、それでいいんだ。

「テンプレートの良い構文がどうあるべきか、私たちは知っている」って言ってるのを聞くと、笑っちゃうよね。実際、全然わかってないし。良いテンプレートって、ほぼ視覚的なものだと思うんだよね、記号的なものじゃなくて。どうしてそんな結論に至ったの？ あなたが言ってるのは、HTML+CSSに対する一般的な不満であって、生成方法についてじゃないように思えるんだけど。それに、なんで絶対位置について言及するの？ HNでこの意見を何度も聞くけど、確かに絶対位置には必要な場面もある。でも、ページやアプリのレイアウトに使うと、ほとんどの場合、ちょっとしたコンテンツ（テキストでも！）や画面サイズの変更で絶対に崩れちゃうから、ほんとに悪夢だったよ。印刷の新聞レイアウトだってこんな風にはできないし、タイポグラフィが関わってくるからね。多分、あなたが言ってることに誤解があるのかも。でも、CSSを多く使ってた頃（今も結構やってるけど）、誰かが絶対位置を使って「ほぼ完成」ってレイアウトを作った時は、それを直すのがすごく時間の無駄だったし、フレックスやフローを使って再構築する方がいつも早かった。絶対位置をメインのレイアウトツールにすると、問題が基本的に修正不可能だったから。calc()やビューポートユニットを使う技術があるかもしれないけど、私の経験では、絶対位置は完全に静的なコンテンツやビューポートの寸法以外には適してないよ。

人々は、絶対位置を賢く使うことで達成できることを再現するために、途方もない努力をするんだよね。ウェブには、どんなデバイスのサイズや向き、能力に関わらず「ドキュメント」が見栄え良くなる必要があるから。普通のアプリ（例えば、Windowsアプリ）にはそんな要求はないし、モバイルアプリには標準化されたサイズのセットがある。ウェブだけが両方を持ってるんだよね！

「テンプレートの良い構文がどういうものか、私たちは知っています。」って言われると、思わず笑っちゃうよね。まず、ウェブプラットフォームの進歩を訴えてる人に笑うのはあんまり良くないと思う。みんなに利益があるんだから。次に、確かに今は良いテンプレート構文が何か分かってるよね。基本的にはjsxだし、Reactのファンじゃない私が言うんだから間違いない。これがウェブ全体を席巻したし、いろんなフレームワークに適応されてる。全てのjsテンプレーティングシステムが共通の属性に収束してるのは否定できないよね：テンプレートは式として、ネストによる構成、特定のテンプレート構文じゃなくて普通のJavaScriptでの制御フロー。

私たちは良いものが何かを知ってる。完璧なものが何かは分からないかもしれないけど、完璧が良いものの敵である必要はないよね。

ReactとSvelteの間には表面的な類似点しかないって言いたいな。確かに、どちらもHTMLに基づいた構文だけど、動作は全然違う。Reactは、（ほとんど）普通のJavaScript関数がマークアップの遅延表現（JSXの形で）を返す唯一の主要なフレームワークだよ。Reactにはループや条件付きレンダリングのテンプレートレベルの概念がないから、普通のJavaScriptを使うことになるんだ。

これには、Reactの人たちがDOM APIを直接呼び出すのは大罪だと思っている部分があると思う。時には、refをキャッチするのもいいし（あえて言うけど、IDでコンポーネントをクエリするのもね）、直接作業をするのも全然問題ない。実際、「速い」ライブラリや低リレンダリングのライブラリは、ほとんどそういうことをしてるよ（フォーム関連のものとか）。

Reactは好きじゃないけど、この意見には反対だな。まず、すでに宣言的DOMをオプトアウトしてinnerHTMLやrefを使うことができるし。次に、宣言的なものよりもDOMの命令的な制御でできることって、実用的じゃないことは何かある？ attachShadow()やshowModal()みたいな特定のメソッドしか思いつかないけど、それでも宣言的にするのは10行のコンポーネントでできることだし。

これを書いたのは、半端な仕様で無謀に突っ走って、解決するどころか問題を増やしてしまった人の一人だってことは覚えておくべきだね。「解決策」を押し進めるために20以上の新しいウェブ仕様が必要だって言ってるけど、ユーザー空間がすでにやってることをかろうじて実現するだけで、彼らのやってることに100%賛成じゃない人を完全に無視して、ガスライティングしてる感じ。サファリは15年前に、こういうのは宣言的な方法が必要だって主張してたんだよね。

記事にはDOM部分の提案がリンクされてて、これは一つの有用な低レベルAPIになるね。VDOMベースのフレームワークにはあまり合わないけど、他のフレームワークにとっては動作を簡素化し、最適化の余地を広げることができる。フレームワークなしのプロジェクトにも役立つし、特にシグナルの提案も採用されたらいいね。