ブラウザメーカーは明確なセキュリティ上の理由からそれを拒否してる。だって、あくまでJavaScriptだけがそんなにひどくやらかすべきなんだから。

DOMを直接扱うのが難しい理由は、ある状態から別の状態に移行するために任意のパッチを実装しなきゃいけないから。Reactのようなフレームワークの全てのポイントは、その問題を避けるために自動的にパッチを作成して適用してくれることなんだ。これは非合理的じゃないよ。むしろその逆だね。

3年前にウェブ開発のビジネスを閉じたんだ。ウェブに関わる多くの人が、どうやって全てが機能するのか理解するための努力をしたくないと感じてるのに気づいた。彼らは「それ」をやるためのライブラリがどこかにあるはずだと思ってるけど、実際には標準のコンポーネントや機能を使えば簡単にできることなんだ。もう一つの問題は、過去のことに基づいて恐れを抱いている人たちがいること。確かに、ウェブで派手なことをするのはもっと難しかったけど、彼らは往々にして、昔はできなかったことをウェブにやらせようとしてる。今は基本的な組み込み機能を使えばできるし、その方が簡単なことが多いよ。

WASMがDOMアクセスを持たない理由は、多くの最近のDOM APIがJavaScriptオブジェクトやクラス（イテレータなど）を返したり期待したりするから。だから、DOMとWASMの間には薄いJSのグルーラッパーが必要になる。セキュリティは関係ないよ。パフォーマンスを除けば、WASM+最小限のJSグルーで、JSができることはすでに何でもできるから。

WASMが置き換えられるためには、含まれているページへの完全なDOMアクセスを得る必要がある。完全な置き換え、つまり全くJavaScriptが必要ない状態になるには、WASMがDOMにアクセスできる必要がある。でも、JavaScriptの代わりに書く言語として置き換えるためには、DOMバインディングを簡単に生成できるから、JavaScriptを介してトランポリンすることができる。これをWASMが登場して以来、みんなやってることだよ。WASMに直接DOMアクセスを与えることは新しいことを可能にするわけじゃなくて、単にJSバインディングをスリム化して、時間やメモリのパフォーマンスを改善する可能性があるだけ。> ブラウザメーカーは明確なセキュリティ上の理由からそれを拒否してきた。実際、彼らはそれを実現するためにかなりの道のりを進んでいる。正しく行うために時間をかけているだけで、これまでに少なくとも3つの異なる方向に進んできた。でも、最初からそれが最終的な目標であることは明らかだった。

なぜかわからないけど、ツリーモデルは大学教育を受けた開発者を怖がらせる。ツリーモデルを「怖がる」人はほとんどいないよ。DOMを扱う問題は、以下のようなことがあるから。 - 90年代のJAVAのように冗長で扱いにくいAPIで、最も簡単なことをするのに大量のボイラープレートが必要 - 自分のことを簡単にできるほど低レベルでもなく、既存のビルディングブロックから必要なものを作るには高レベルすぎる非常に貧弱なAPI - 完全に非合成的なAPI - 何かをするのを妨げるレンダリングシステムで、要素のボーダーを変更するだけでページ全体の再レイアウトを引き起こす可能性がある数百の落とし穴やコーナーケースに気を配らなければならない - 静的なウェブページ以上の複雑なものには非常にパフォーマンスが悪いレンダリングシステム（それすらもかろうじてこなしている）。人々が示す「驚くべきパフォーマンスの偉業」は、非常に注意深くコーディングされたものか、他のツールキット（例えば、canvasやwebgl）と同じ技術を使っているか、他の何かにとっては絶対的な基本条件だよ。先週のフロントページの記事では、3つの長方形をアニメーションさせるのに60%のCPUと25%のGPUが必要だったって書いてあった。https://www.granola.ai/blog/dont-animate-height > だから、DOMから逃げるために無駄な抽象化を使ってキャリアを投資する人が出てくる。過去15年ほどの抽象化は、DOMが非常にパフォーマンスが悪く、母親ですら愛さないようなAPIだから、DOMから逃げようとしてきたんだ。

現実的にどうやって複雑じゃなくなるのか想像するのも難しい。簡単だよ。2つの標準が必要だった。1つは「アプリケーションのためのウェブ」で、VM、標準ライブラリ、バイトコード、RPC、UIフレームワーク、コントロールの標準ライブラリに基づいて構築されているもの。そしてもう1つは「ウェブページのためのウェブ」で、これはHTML5以前の時代には解決済みの問題だった。JavaやFlash（セキュリティの観点からは非常に問題があるけど）は、「アプリケーションのためのウェブ」を構築するための基盤としてHTML5+/CSS3+/JS/WASMよりも良かったかもしれないけど、GoogleやMicrosoft、MozillaがOracleやAdobeにその鍵を渡すのは耐えられなかったんだ。すべてが政治的なもので、結果的にすべてが悪化して、より複雑で非効率的になってしまった。

ウェブは複雑なアプリケーションに合わせて成長してきたけど、プラットフォーム自体も無駄に膨れ上がってるよね。新しい機能（例えば、Canvas提案のHTMLみたいな）を、すでにバラバラなパズルに無理やり押し込まなきゃいけないから。後方互換性は、技術的な成果というより理想的な名誉のバッジになっちゃった。この記事は、ウェブの有機的な成長にもかかわらず、実際にはそれほど頑丈じゃない技術的な部分に触れていて、いい仕事してると思う。盆栽も時々剪定が必要だしね。正しい方法が一つだけってことはないけど、Flashの時代からインターフェースの設計方法はかなり収束してきたから、少なくとも「大体合意された方法」で会話を進められるようになった。

確かに、いくつかのアプリケーションは、シンプルな機能に対して大量のマークアップを持つ傾向がある（Slackの入力ボックスの例みたいに）。でも、代わりにブラウザベンダーが全てを組み込んじゃうと、すべてのアプリが彼らが正しいと思う意見に縛られちゃう。ある程度の混沌は健康的かもしれない。あるいは、すぐに使える機能を提供するコントロールのセットを用意して、便利なAPIを提供して、みんながそのコントロールを拡張したり、自分のものを作ったりできるようにすればいい。ウェブプラットフォームはどちらも提供してない。これを、太陽の下にある他のすべてのUIツールキットと比べてみて。90年代のTurbo Visionは、ウェブが提供するものよりもずっと優れたツールキットだったよ。

垂直センタリングについては、20年前にこれを試したときは本当に面倒だった。レイアウト全般が過去20年で大幅に簡素化されたことを考えると、当時はすべてがテーブルに詰め込まれていたことを思い出すよ。だから、「DOM、HTML、CSSがどんどん難しくなっている」と言われても、そのアマチュアで根拠のない意見は無視していいと思う…ハハ！

問題は、DOMがページレイアウトを記述するには全く不十分で、Webアプリケーションにはさらに不十分だってこと。DOMへの段階的な変更は、この目標により適したものにするために意図されていたけど、根本的に悪い基盤があったから、あまり助けにはならなかったと思う。ページレイアウトを記述するには、何らかの制約言語の方がずっと良かっただろうし、Webアプリケーションのようなものは存在すべきじゃない。これらは、データの移動にはインターネットを利用しながら、ネイティブUIツールキットを使うアプリケーションであるべきだ。ユーザーは、ブラウザが便利な機能を制限するため、Webアプリケーションに不満を持つことが多いし、プログラマーは簡単なことを達成するために回避策やブラウザの膨張に苦労している。

同意。最初からプリミティブがちゃんと考えられてれば、もっと良かったと思う。HTML5の入力やフォームのバリデーションは、今でも壊れた悪夢で、たくさんのJavaScriptを追加してもほとんど修正できないよ。

この複雑さの多くは、プリミティブがウェブアプリのユースケースにはあまりにも原始的すぎるからだと思う。ドキュメントには問題ないけど、ウェブアプリでは砂粒から建物を作ろうとしてるみたいなもんだよ。ルーブ・ゴールドバーグマシンは避けられないよね。ブラウザは、最小限のテーマで機能的なウィジェットを提供して、ほとんどJavaScriptを必要とせず、CSSで完全にスキンできるようにするべきだと思う。それだけで信じられないほどの複雑さがなくなるし、うまくやればウェブ開発の体験がずっと快適になるよ。

うん、個人的にはDOMは結構良いと思うよ。APIの表面的な部分に関する不満もあるけど…例えば、プロパティとメソッドの境界が曖昧で悪用されてるとかね。でも、これらは本当に表面的なポイントだと思う。DOMは宣言的なアプリケーションを作るためだけのものだとは考えられないし、命令的な機能もサポートする必要があるよね。個人的には、カスタムWebコンポーネントAPIが宣言的な問題をすごくうまく解決してると思う。Reactや他の宣言的なフレームワークよりもずっとスッキリしてるし。DOM APIがユーザーのニーズに合わせてゆっくり進化してきたのは素晴らしいことで、下から上に再設計すればもっと良くなるなんて考えるのは愚かだと思う。文句を言ってる人たちは、ユートピア的な考え方に囚われてるんじゃないかな。彼らは特定の視点を持っていて、自分たちに関連する限られたユースケースのレンズを通してDOMを見てる。彼らは「関数型プログラミング、サイドエフェクト、リアクティビティ」みたいな概念に対して固い信念を持ってるけど、これらの信念はそれぞれの概念に孤立してる。複数のアプローチの交差点が問題を変革し、方程式を根本的に変えることができるって事実を無視してるんだよね。例えば、Webコンポーネントのモジュール化や関連するライフサイクルメソッドは、コンポーネントの境界内での命令的プログラミングの危険を大幅に減らしてくれる。強酸と強アルカリ溶液がそれぞれ危険なのは知っておくべきだけど、混ぜることでその事実が完全に変わる可能性があることも認識すべきだよ。

30年前のVisual Basicは、もっとシンプルな開発環境だったよね。WASMで似たようなものが出てくると思ってたけど、まだ待ってるところ。

僕は埋め込みデバイスでUIレイアウトやアニメーションをCで手書きすることが多いんだ。HTMLやCSSもよく使うけど、時々は自分でレイアウトコードを書くシンプルさが好きだな。そうすると、基本的にX/Y座標、アンカーポイント、画面や要素のサイズだけあればいいから、あとは簡単な算数で済むんだよね。これの良いところは、CSSでやることの95%を、一貫した方法でできるってこと。初心者には座標系で考えることを教える必要があるけど、そのシンプルさは新鮮だよね。一方でCSSは、自然に成長した複雑な機能があって、時には簡単なはずのことが難しくなることもある。スタイルを当てるべき要素には、知らないうちに微妙な違いを持つデフォルト属性があるからね。display: inline、block、inline-block、contents、flex、grid、table、table-column-groupなどの違いを教えられる人は少数派だと思う。でも、要素にはデフォルトでそれが設定されてることもあるんだよね。CSSを後方互換性の理由で簡素化するのが難しいのはわかるけど、時々は誰かが上に追加するのではなく、エレガントで一貫性のある解決策を考えてくれたらいいのになって思う。

ウェブをプラットフォームとして「大成功」と言うのは控えめすぎるよ。あまりにも成功しすぎて、ウェブ開発をしている95%の人は、こういった議論に興味がなかったり、意見を持っていなかったりすると思う。「沈黙の」ユーザーの規模は、積極的な開発者と比べて最も驚くべき数字になるだろうね。「最初の原則からDOMを再考する」っていう人に対して、eコマースのHTMLテンプレートを編集したり、結果をテーブルやデータビジュアライゼーションにエクスポートしたり、内部システムのために小さなUIを作ったりしているランダムな人たちが1万以上いるんじゃないかな。

要素に任意のタグを作れるし、CSSで見た目を定義するまでスパンのように扱われるよ。特徴 { display: block; padding-left: 1.5em; list-style-type: disc; } 特徴 { display: list-item; } 技術的には、名前空間の問題を避けるためにカスタム要素にはダッシュを付けるべきなんだけど、もしそうなったら簡単に検索して置き換えられると思う。これ、XMLではすごく役立つよ。

プレゼンテーションとデータを混同するのは、古典的な悪手って感じだね。プレゼンテーションの変更がビジネスロジックを壊しちゃうから。

同意だね。状態をドキュメントから移すっていう考え方は、ちょっとイライラする。データの木構造の目的は、状態をデータとして保存することじゃなかったの？

みんな状態を文字列化してるの？

最初に取り組んだAjax/jqueryアプリは、DOMに状態を保存し始めたら、すごくシンプルになってバグも減ったよ。トグル操作で状態の変化を見逃すのが簡単すぎて、UIがAPIとは正反対の状態になっちゃうことがあるからね。

Flutterは、現代のハードウェアの動物園のような環境で、モダンなクロスプラットフォームアプリを作る問題への応答として素晴らしい。80年代のテキスト組版エンジンは、明らかにそれには適してないよね。過去20年間の開発者の大多数がHTML/JS/CSSスタックからキャリアをスタートさせたのは間違いないし、彼らがそれを好む理由も理解できる。でも、どんなに抽象化を重ねても、このスタックがアプリ作りに向いているわけじゃないよ。

また、キャンバスベースの入力があるからこそ、Google Docsが絵文字や非英語入力に苦労しているのもあるんだ。これは問題があるのはそれだけじゃないよ。地球の地図ビューを開いて数クリックしただけで、明らかに壊れたUIパターンを見つけたことがある：- 右クリックがどこでも機能しない（入力ボックスを除いて）、他のGoogleサイトで直接対応する要素（アカウントスイッチャーなど）があるにもかかわらず、- アカウントスイッチャーをクリックすると、それが開いている間はサイトの他の部分がマウスイベントを無視する。マップ画面をドラッグしようとしてもスイッチャーは閉じないし、ボタンにホバーしてもカーソルが変わらない。

Flutterは、初めからHTMLと同じくらいアクセスしやすいの？それともWin32やMacOSのAPIと比べてどう？

全く同意だよ。ネイティブアプリが優れていると感じる人たちの気持ちがわからない。私たちが持っているウェブ技術は、開発者の体験とUXの観点から見ても素晴らしい。みんなElectronアプリを嫌うけど、これは主にElectronの膨張のせいだと思う。Tauriがそのギャップを埋めてくれることを願ってる、今のところは最高だよ。

それが重要なの？Elementオブジェクトに対してfor..inループを回してるわけじゃないし。