DOMテンプレーティングAPIの導入に最適な時期です

2025年6月27日原文(justinfagnani.com)

概要

Webプラットフォームに 宣言的テンプレートAPI を追加する提案
現状、DOM APIは強力だが テンプレート機能が標準で不足
テンプレートがないことで ユーザー・開発者・プラットフォーム全体に悪影響
現在は API追加の好機 であり、既存の知見も豊富
JavaScriptベースのテンプレートAPI導入が 現実的かつ効果的

Webプラットフォームに宣言的テンプレートAPIを追加するべき理由

Webプラットフォーム は最も成功したアプリケーション実行環境
DOM API のおかげで静的ドキュメントから動的なアプリケーションランタイムへ進化
DOMは強力だが、「 宣言的テンプレート」の標準APIが存在しない現状
データバインディング、イベントリスナー追加、プロパティ設定、XSS安全性、効率的な更新を 一貫して実現できるAPIが不在
これらのテンプレート機能は React、Vue、Angular、Svelte など全ての主要フレームワークの基盤
宣言的テンプレートの利点
- 命令型APIより記述性・可読性が高い
- XSS対策が容易
- 高パフォーマンスな差分更新
- 型チェックや静的解析が容易
- サーバーサイドレンダリング対応
テンプレート機能の欠如による影響
- ユーザー ：アプリの初回表示遅延、ライブラリのダウンロード待ち、不安定なセキュリティ
- 開発者 ：npmやCDNへの依存、学習コスト増大、ポータブルな知識の欠如、安全でないAPIの利用
- フレームワーク開発者 ：テンプレート実装の負担、性能・機能・サイズのトレードオフ
- プラットフォーム ：ネイティブ競合（Flutter、SwiftUI等）に対する競争力低下

なぜ今テンプレートAPIを追加すべきか

過去にも E4X やhtmlタグリテラルなどの提案があったが、更新性が弱く失敗
現在はフレームワークの進化により、 良いテンプレート構文やリアクティビティモデルの知見が蓄積
バニラJSやWeb Components コミュニティからも、使いやすいDOM操作・リアクティビティAPIへの強い需要
DOM Parts など低レベルAPIの提案も進行中だが、より高レベルな宣言的APIが必要
テンプレート記述の 構文・セマンティクスの共通化 が進み、標準化の好機

JavaScriptベースのテンプレートAPIの現実性

Tagged Template Literals （ES2015）によるテンプレート記述が既に実用化
React、Lit、Solid など多くのライブラリがこの方式で成功
JSXのような構文も人気だが、 標準化にはセマンティクス定義が必要 で課題が多い
現状でも JSX→Tagged Template Literal への変換ツールが存在し、ユーザー側で選択可能
将来的にJSX標準化が進めば、 テンプレートAPIをターゲットにできる下地作りが可能

HTMLベースのテンプレートAPIとの比較

多くの開発者が HTMLベースのテンプレートAPI を求めている現状
しかしHTMLベースは バインディング構文、式言語、制御構造、更新メカニズム 等の新規設計が必要
JavaScriptベースなら 既存の言語機能やエコシステムを活用可能
HTMLベースのAPIは将来的な拡張として検討し、まずは JSベースのAPI導入が現実的

まとめ

宣言的テンプレートAPI の標準化はWeb開発の生産性・安全性・パフォーマンスを大幅に向上
現状のDOM API では満たせないニーズをカバー
フレームワークの知見 を活かし、プラットフォーム全体の競争力強化
まずは JavaScriptベースAPI から導入し、将来的な拡張も視野に入れるべき

Hackerたちの意見

JSXを使う代わりに、Kotlinのレシーバーやビルダーのような構文があればいいなと思ってる。これがあれば、コンポーネントの階層を表現するのにすごく便利な一般的なDSLの構文が提供できると思う。HTMLテンプレートだけじゃなくて、設定やその他の色々なことを表現するのにも広く役立つはず。テンプレートやデータバインディングの実際の意味は、そういう構文機能を使った標準関数のセットにすればいいんじゃないかな。Jetpack Composeみたいにね。

└

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

ウェブにはネイティブなテンプレート、リアクティビティ、データバインディングが本当に必要だよ。何十億人ものユーザーがReactみたいなものをダウンロードして、パースして、実行するのにどれだけCPUや帯域幅が無駄になってるか想像もつかない。

└

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

└

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

└

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

└

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

繰り返し学んできた基本的な教訓は、APIやABIは最終的なものではないってこと。アプリケーションのニーズは、安定したAPIによって永遠に満たされることはないし、将来の問題はすべてアプリレベルの問題として考えられる。今回の提案は、プラットフォームの共通の問題がどう解決されるかの良い例だよ（Reactとか）。問題として認識されるまで上に積み上げられて、そこから下に押しやられるんだ。ポリフィルもその一例。こういう提案が成功すれば、一時的に注目を浴びるけど、その後は人々が回避しようとする古いものになってしまう。DOM APIやECMAのバージョン、古いブラウザ、システムの一部だけど触れられない技術のようにね。エントロピー、拡張、後方互換性を主要なユースケースとして考えることはできるのかな？

└

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

└

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

└

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

└

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

Hacker Newsで議論の続きを見る

ハクソク