- Webプラットフォームには現在、開発者が切実に必要としている宣言的テンプレートAPIが欠けている
- ほとんどの現代的なWebフレームワークではテンプレーティングが中核技術だが、標準DOM APIには安全かつ効率的にテンプレートを生成・更新する方法がない
- その結果、ユーザー、開発者、フレームワーク、さらにはプラットフォームのレベルに至るまで、不便さと性能低下の問題が発生している
- テンプレートAPIを導入する時期に来ており、近年のフレームワークの知見とJavaScriptの機能が十分に蓄積されたことで、実装と標準化はより現実的になっている
- テンプレート識別性、シグナルベースのリアクティビティなど多様なモデルを総合し、次世代テンプレートAPIの方向性が示されている
提案の要約
- この記事は、Webプラットフォームに宣言的テンプレートAPIを追加する提案の背景と必要性を説明している
- DOM APIは強力だが、標準DOMにはデータに基づいて安全かつ効率的に複数ノードを生成・更新するためのテンプレートAPIが存在しない
- React、Vue、Angularなど主要フレームワークはいずれも宣言的テンプレーティングを中核としており、開発生産性、セキュリティ、性能、静的解析、サーバーサイドレンダリングなど多くの利点を提供している
- テンプレートAPIの不在により、ユーザー、開発者、フレームワーク、そしてプラットフォームのすべてが、不必要な複雑さ、セキュリティ脅威、性能低下、参入障壁などに直面している
- 今こそAPIを導入すべき時期だと主張し、既存フレームワークの知見と現代的なJavaScript機能を活用した段階的な標準化を提案している
テンプレートの必要性と現在の問題
- DOM APIはWebプラットフォームの動的機能を支える基盤である
- しかし標準DOMには、データからDOMツリーを安全に定義し、効率よく更新する宣言的テンプレート手段がない
- 現代的なWebフレームワーク（React、Vue、Angular、Svelteなど）はすべて宣言的テンプレーティングを提供している
- 宣言的テンプレーティングが人気の理由は次のとおり
- 命令型APIと比べてより高い使いやすさと可読性を提供する
- XSSセキュリティを強化する。テンプレート内部のデータを自動でエスケープする
- 効率的で高速なレンダリング性能
- 静的解析、型チェック、インテリセンスなどによる開発生産性の向上
- サーバーサイドレンダリングをサポートする
現状の問題点
- ユーザー: ライブラリのダウンロードやレンダリング遅延により初期読み込みが遅くなる。クライアントコードのサイズ増加でUXが悪化する
- 開発者: テンプレート利用のために別途ライブラリ（npm、CDNなど）が必要。参入障壁となり、非標準の読み込みが必要になる
- フレームワーク: テンプレートエンジンを自前で実装する必要がある。性能、機能、コードサイズの間で重いトレードオフが存在する
- プラットフォーム: ネイティブアプリとの競争で不利。Flutter、SwiftUIなどは組み込みのテンプレートシステムを提供している
今が適期である理由
- 過去のテンプレート関連の試み（E4X、E4H、htmlテンプレートリテラルなど）は失敗したが、当時はDOM更新に弱点があった
- 近年、フレームワークとコミュニティの中でテンプレートAPIのベストプラクティスが十分に蓄積されてきた
- JavaScriptベースのAPIを提案できる。現在の標準JSにはタグ付きテンプレートリテラルがすでに存在する
- Vanilla JS開発者やWeb Componentsコミュニティでも、手軽なDOM操作への需要が継続的に高まっている
- DOM Partsのような低レベルプリミティブの提案も並行して進んでいるが、高レベルの宣言的APIのほうが、より大きな効用と発展の方向性を示せる
優れたテンプレート構文の事例分析
- 主流のテンプレートシステム（React-JSX、Vue、Svelte、Angularなど）は、突き詰めると非常によく似たマークアップ+バインディング構文に基づいている
- JS APIベースのテンプレートでは、テンプレート式がDOM記述を返し、別のレンダー関数がそれを実際のDOMに反映する構造が一般的である
- E4Xのような旧来の試みはDOMそのものを返しており、更新モデルに難があった
JavaScriptベースのテンプレートAPIの可能性
- タグ付きテンプレートリテラルによって、新しいJS機能を導入せずにテンプレートAPIを設計できる
- すでにJSX-to-Litなど、複数の実証例が存在する
JSX統合の議論
- JSXの標準化には複雑な意味定義とランタイムセマンティクスが必要であり、JSX自体は単なる構文にすぎない
- 現行の非標準JSXは純粋な構文変換なので、将来標準テンプレートAPIが導入されれば、JSX->テンプレートリテラル変換コンパイラへ接続できる
- 将来的に真のJSX標準化が行われる場合も、テンプレートAPIに合わせたデータ型受け入れ構造へ移行しやすい
HTMLベースのテンプレートAPIとの関係
- 多くの開発者やコミュニティがHTMLテンプレートシステムを求めている
- しかしHTMLベースのシステムは、バインディング、式言語、制御構文など新たな構文・式設計を必要とするため、はるかに大きな作業になる
- 近年、フレームワーク（Litなど）がHTMLテンプレートからJS APIへ移ってきた背景も同じである
- したがって、JSベースのテンプレートAPIをまず導入し、その後HTML APIへ段階的に拡張していく可能性が高い
リアクティビティ実装経験の成熟
- VDOM diffing（React）、テンプレート識別性（Lit）、シグナル（fine-grained signals、Solid/Svelte/Vueなど）など、多様なリアクティビティモデルが検証されてきた
- VDOMベースは遅い一方で、テンプレート識別性+シグナルモデルの組み合わせは高速で効率的であり、説明力も高い
- シグナルベースではすべてのデータをシグナルでラップする必要があるが、一般的なデータと混在させることも可能である
発展経路と期待される効果
- 提案されている宣言的JSテンプレートAPIは、Vanilla JS、Web Components、新しいフレームワークのすべてに直接的な利点をもたらす
- 既存フレームワークにとっても、コンパイルターゲット、ランタイムバックエンド、または直接サポートAPIとして活用できる
- 「再レンダリング」方式とシグナルベースのリアクティビティの両方をサポートする
- 将来のHTMLベース宣言的テンプレートや、宣言的カスタムエレメントへの拡張基盤を整えられる
- APIの範囲は狭く明確で、既存API（例: DOM Parts）との連携もしやすい
- ただし、表面上のAPIや構文は単純でも、下位のDOM Partsやスケジューラなど実装面の範囲は広く、標準化やテストなどの協業が必要である
まとめ
- 著者はGitHub issueでこの提案を議論しており、プラットフォームエンジニアなどコミュニティの参加を呼びかけている
1件のコメント
Hacker Newsの意見
「良いテンプレート文法を私たちは知っている」という言葉に笑ってしまうのは、実際にはその基準すらきちんと合意されたことがないと思うから。テンプレートは記号的(symbolic)な観点よりも視覚的(visual)な体験のほうが重要だと思う。昔のDreamweaverのようなツールがあれほど成功したのもこのため。多くのデザイナーがPhotoshopのようなツールから学び始めるのも同じ文脈だ。今のこの試みはXSLTを作り直そうとしているように見えて残念さがある。うまく作られていない構造物を、うまく作られた結果に結び付けることがテンプレーティングの本質的な問題だ。さらに、
labelとforのように結び付いてはいるが同じツリーに属していないエンティティを表現する問題もある。もし魔法が使えるなら、標準的なドキュメントレイアウトに無理やりすべてを奇妙に合わせようとしないでほしい。絶対位置(absolute positioning)をうまく使うだけでも多くのUI問題を効率的に解決できるのに、なぜこんなにも繰り返し数学的演算まですべて機械に強制的に任せようとするのか疑問だXSLTを作り直そうとしているという点には同感。XML自体は好きではなかったが、XSLTは本当に強力な存在だった。ブラウザでも今なお広くサポートされている機能だ。XMLは設定(Configuration)やIPCなどでは欠点が目立ったが、優れたマークアップ言語にXSLTの変換力が加わる部分については、むしろ十分に活用されなかったのが惜しい。XSLTが大衆化しなかったのは、本当に宣言的で関数型のDSLだったからだ。多くの人がDSLを肯定的に語るが、実際には人気言語の手続き的な意味論を薄く包んだだけのことが多い。よく設計されたDSLなら複雑なことを簡単に処理できるのに、学ぼうとする努力が足りないと思う
きちんとしたテンプレート文法で重要なのは視覚性だと言うが、なぜその結論に至ったのか知りたい。私にはHTML+CSS自体、つまり生成方法への不満のように聞こえる。絶対位置に言及した理由も気になる。絶対位置は確かに使うべき場面では有用だが、全体レイアウトのために使うとむしろ管理が難しく、画面サイズやコンテンツ量によって簡単に破綻する。新聞レイアウトでさえ実際には文字やタイポグラフィの微妙な要素が多く、絶対位置だけでは解決できない。CSSを深く扱うとき、絶対位置から始まったレイアウトを後でflexやflowへ再構成したほうが、かえって速く簡単に問題を解決できた経験が多い。
calc()やviewport単位をうまく使えば意味を見いだせるが、実際には完全に固定されたコンテンツやビューポートでない限り、絶対位置は適切ではない人々が、絶対位置をうまく活用すれば簡単かつ迅速に実装できるものを、あまりに複雑に遠回りして結局は同じ効果を出そうとしているという話は見たことがあるが、Webにはあらゆるデバイスのサイズ、向き、性能に応じて文書が良く見えなければならないという要件がある。一般的なアプリ（Windowsアプリなど）にはこうした悩みがなく、モバイルアプリも標準化された画面サイズだけを考えればいい。Webだけがこのすべてを扱わなければならない特性を持っている
「良いテンプレート文法」に皮肉っぽく反応するのは、進歩を主張する人に対してあまり礼儀正しい態度ではないと思う。そして今は良いテンプレート文法があると思う。代表例がjsxだ。私はReactのファンではないが、jsxがWeb開発に革新をもたらし、ほとんどのjsテンプレートシステムが「式としてのテンプレート」「ネストによる合成」「JavaScriptで制御フローを扱う構造」へほぼ収束したと思う
ReactとSvelteは表面的に似ているだけで、実際の動作方式はかなり違う。Reactは（ほぼ）普通のJavaScript関数がJSX形式の遅延(lazy)マークアップを返すことが核心だ。ループや条件付きレンダリングのためのテンプレート固有の構文がなく、すべて通常のJavaScriptで処理する点が主な違いだ
APIとABI(アプリケーションバイナリインターフェース)は決して最終的なものではない、ということを繰り返し学んでいる。アプリの要求は固定されず、時間とともに変わり続けるので、永遠に使える完璧なAPIは存在しない。今回の提案はその良い例だ。まずユーザーランドのライブラリ（Reactなど）が問題を解決し、やがて標準に降りてくる。Polyfillも同じパターンだ。こうした提案が成功しても、結局は古い技術となり、人々はそれを回避するために新しい方法を作る。DOM API、ECMA、古いブラウザも同じ運命だ。技術的エントロピー、拡張性、そして下位互換性そのものを標準のユースケースとして考えられるかを考えさせられる
Web標準の新機能追加は、結局メンテナンスに膨大なコード負担を生み、標準準拠ブラウザを作る際にも実装すべきコードが増え続ける。Servoのようなプロジェクトが少しでも追いつこうとすると、常に拡張だけを追いかける状況が繰り返される。Webプラットフォームがネイティブ環境のすべての機能を持てるようになってほしい（プライバシーとサンドボックスの制約内で）。開発者体験が優れることも望む。しかしこうした夢を実現するには、複雑性の増大という代償を考えなければならない。今回議論されているネイティブテンプレーティングが本当に開発者体験をはっきり向上させるのか疑問だ
下位互換性を維持してインターフェースを変えないのなら、バージョン管理がその役割を果たすのではないかと質問したい
古くなると回避やパッチが繰り返されるという主張だが、その過程で基盤機能が一段階引き上げられるという前向きな効果もある。漸進的な更新は、ユーザー要求が新しい抜け穴やユースケースを見つけ続けるとしても、十分に価値がある
「APIとABIは永遠に安定しない」という主張には同意しない。たとえばgetElementByIdは25年以上安定して維持されている。不変のAPIが不可能だというのは個人的な諦めに近く、世の中には多くの例外がある。需要に終わりはないのだから、新しいAPIを追加すればよい。動いているAPIを壊す必要はない
Webでは、一度公開されたAPIならその形式に一生依存する利用者が現れる。だから20年前の決定の余波が今なお続いていることがある。たとえば"smooshgate"のような事例で確認できる
リアクティブプログラミングの流行に触れつつ、ユーザーレベル(system)がこの領域を十分に試し、今ではさまざまなアプローチの長所だけを集めて本当の標準システムを作れると主張している。しかしRyan Carniato/Solid JSのようなところでは、今もsignalsを活用した新しい可能性を探っており、まだ探求は終わっていないと思う。さらに発展する余地は十分にある
Webにはネイティブのテンプレート、リアクティビティ、データバインディングが本当に必要だ。世界中の何十億ものユーザーがReactなどの重いフレームワークをダウンロードし、パースし、実行するために使っているCPUと帯域幅の無駄は想像を超える
LLMや暗号化演算の途方もない資源浪費と比べれば、こうした無駄は大したことではないように感じる
TC39でsignals関連のproposalが出てきており、そのおかげで一歩前進している
実際に開発に必要なのは、双方向データバインディングとjsxクローン程度で十分だ
Reactはテンプレートシステムではない
Web標準に高レベルのテンプレートシステムを導入する議論を見ていて、むしろ先に提供すべきなのはブラウザ組み込みの低レベルAPIだと思う。誰もが標準テンプレートシステムに同意するのは、ほとんど不可能に近い。一方で、ブラウザがDOMにdiffを適用する低レベルAPIを提供すればよい。たとえば次のようなメソッドがネイティブにあるとよい:
element.applyDiff(DocumentFragment | string, { method: 'innerHTML' | 'outerHTML' })。このようにdiffを適用すれば、現在のelementのフォーカス、inputの値、audio/videoの状態などを保持しつつ、非破壊的に更新できる。Idiomorphのようなjsライブラリはあるが、ネイティブソリューションのほうがはるかに高速になる可能性が高い今回の記事の著者は、この分野で最高レベルの経験者として紹介されている。Lit、Polymer、Googleのweb components、複数の中核DOM仕様に大きく貢献した人物だ
JSX方式の代わりに、Kotlinがreceiverとbuilderを活用してDSLを一般化したような文法アプローチを望む。こうした方式は単純なHTMLテンプレートを超えて、さまざまなコンポーネント階層、設定(config)、多様な状況で非常に有用になり得る。テンプレーティングとデータバインディングの実際の意味は、結局こうした文法機能を活用する標準関数セットにすぎず、これはJetpack Composeに似ている
宣言的(Declarative)テンプレーティングがjQueryより優れているのか、いつも確信が持てるわけではない。Reactをほぼ10年使っているが、SPAが複雑になるほどDOMの命令的(imperative)制御が恋しくなる。DOMの抽象化は漏れやすく(leaky abstraction)、結局は単純な「最後の書き込みが勝つ(last-write-wins)」のようなパターンのほうがかえって明快だ。宣言型テンプレートがこうした問題を解決すると言われるが、コンポーネント間でmutableな状態を共有し始めると、その限界があまりにも早く露呈する
この感覚は、React系の開発者がDOM APIを直接呼ぶことを罪悪視するために生じている部分もある。refを積極的に使ったり、idでコンポーネントを直接探して操作したりするのも問題ない。実際、高速で再レンダリングの少ないformライブラリなどはこのように動作する
私はReactが好きではないが、宣言的DOMから外れてinnerHTMLやrefなどを使うことに障壁はないと思う。命令的制御で可能ではあるが、実用上、宣言的にできないことは多くない。
attachShadow()やshowModal()も、10行程度追加すれば宣言的に簡単にラップできるRecordsとTuples proposalが進展していれば、JSXがその構造を活用して新しい意味論を持てたかもしれないが、実際にはそのproposalは停滞したどころか完全に撤回された（issue参照）。代わりにcomposites proposalで置き換えられた
このような高レベル機能の標準化議論は中止すべきだと思う。その代わりに低レベル特性を拡張し、上位ライブラリ実装にとってより価値のある方向へ集中すべきだ。標準提案にライブラリより明確な利点がなければ意味がない。ライブラリとして最低でも5〜10年以上広く検証された場合にのみ、標準化の議論を始めるべきだと思う