blog2017-10-02やはりHTML/DOMは再発明されるべきじゃないかと思う次第である。GUI設計の今JSはそのプラットフォーム特性上、あらゆる言語の使用者の、あらゆる不満が集まる場所で、ヘイトを集めやすい環境だと思う。いうプラットフォームの登場でエコシステムが生まれ、思いつく限りあらゆるメソッドが適用されてきた。貧弱な言語基盤だが、その中で生き残った方法論が、今一番GUIの課題を上手く扱えている、と自分は考えている。よって、Flux/MVVMという抽象パターンが枯れてきたように思う。みたいな話は無視する)。写像である、ということに尽きる。入力とし、それぞれの状態はシリアライズ可能で、あらゆる状態が入力値によって予測可能(参照透明)で、決定的である。要は、メタな設計というレイヤーでは、データの扱いを記述することが、アプリケーションを記述することと同義になりつつある。スナップショットを切り取るかの一つの方法論に過ぎない。ものは悪で、GUIの設計からは排除されるべきものになった。本質的にシングルトン(哲学的には、そこで発生する「体験」もシングルトン)だが、そこに対する副作用は厳密に管理されなければいけない。ここで「発見」されたのは関数型的な手続き、FRPである。まあFRPは詳しく掘り下げるとボロが出る長くなるので、今回は置いておく。状態遷移は、人間の手を離れた。時代のスクレイピング的手法から、自動的な木の構築が行われ、残されたのは、その破棄/生成のライフサイクルに対するフックになった。細かいインタラクションの最適化はまだ人間の手の余地が残されているが、管理すべき対象は大幅に減り、個人的にはウェブ開発の産業革命以前と以降のような劇的な変化だと思っている。仮想DOMという概念が俺達の魂を震えさせるのかを読んでほしい。「賢い」データバインディングも結局はVirtualDOMとやることが同じである。木の枝ごとに値の監視範囲を知っていて、必要なパラメータだけを書き換える。DOMを書き換えた結果、レンダラに負荷がかかる。パフォーマンスが良くなる。別の世界で定義された構造である、という本質的な部分だ。木に対してプリミティブな命令セットすぎるHTML/DOMを効率よくハックするために生まれたメタ概念であり、実際にはDOMのパラメータを変更した結果として描画命令が発行される。その為、逐次的なパラメータの更新は、ステップごとにその変更を通してサイズや位置が変更され、親は自身の大きさのバウンディングボックスの再計算を必要とし、それがルート要素まで連鎖し、まあ色々なんやかんやあって命令に対し影響範囲を予測することが難しい。属性が物事をややこしくしている。同期的に割り込まれたり、再計算範囲が事前にわからないそれらは、Webの黎明期に大きな役割を果たしたが、今や大いなる負債となって、最適化を妨げている。(と思っているが、本職のブラウザ開発者はまた別の意見がありそう。参入障壁が大きく民主的ではない問題の一つ。後方互換を配慮して積み重ねていた結果、実装が困難で、一部のパワーのあるベンダーしかブラウザを実装できない状態になっており、結果としてブラウザの開発は参入障壁が大きくあまり民主的ではない。体裁としてオープンソースだが、一部のベンダ内にノウハウが偏っているし、ビルドやユニットテストに掛かる時間も膨大で、分散ビルド環境を持たないと開発に参加しにくい。方向性と相容れなくなったため、アップデートごとにAPIが削除され、都度代替を探すということをしてるうちになんだか使いづらいものになってしまった。セマンティクスは既に滅んでいる問題の一つ。今のWebに、もはやHTML/CSSにセマンティクスなどはない。属性を通して何らかの意味を持っていて、外部から意図を読み取ることは困難だ。属性によってなんらかのセマンティクスを与えることが出来るも、今や付け焼き刃だ。クローラーは、おそらく最低限のセマンティクスを読み取った後は、各要素のバウンディングボックスの上からの出現順と全体を占める比重をみて、その中身のテキストの解析結果に重みを付けている、と予想できる。解決のアプローチたぶん、ブラウザ開発の中の人達はそんなこと当然わかってて、何度も試作し、仕様を煮詰め、そして実装的な課題や、あるいは政治的な部分で諦めてきただろう。その失敗は、時代的なものも大きかったと思う。追い詰められて標準化圧力が強い今、やってみるべきではないか。勝利ということで終わったが、モバイルの隆盛で、ブラウザというものが危機に瀕している。僕はブラウザとWebとその民主主義が好きなので死んでほしくはない、と思っている。ブラウザが生きのこるのに必要なのは、後方互換を切り捨てた高速なレンダラー基盤と、そのためのシンプルな仕様なのではないか、というのが自分の思うところ。下に新しいページコンテキストを生成する。自分でエレメント要素に名前を付けられるので、セマンティクスが今よりはマシだ。要はお行儀の良いiframeである。これによって全く別の最適化が施せる、余地がある。周辺でおそらく合意がとれない、といった課題が山積している。リッチなアプリケーション基盤としても、WebComponentsが生成した中身のSEOが、どうクロールされ、どう扱われるかの声明がGoogleから出ていないので、前述の問題を含めて、個人的に使う気にはなれない。AMP最初に言っておく。Googleの邪悪なHTMLサブセットだ。やりたいことは痛いほど分かる。要はレンダラーが予測可能な命令セットだけで、事前に最適化してしまいたいのだ。それにGoogle側のキャッシュプレロードが付いてくる。事前に確定することが要求される。使った体験に非常に近い。近いというか中身見る限りそのものだが。名が出るか、疑問に思う人も多いだろう。自分はこれが、Webを作り直す場合、この発展系が一番筋がいいのではないか、と思っている。