余白

https://blog.lacolaco.net/ に移転しました

IntersectionObserverに対する葛藤のメモ

ポエム

※これは酔った状態のメモであり3日後には意見を翻している可能性があるのでその辺留意して読んで欲しい。

IntersectionObserverというものがある。ググってもらえばわかるが、IntersectionObserverとは、ざっくりいえばDOM上である要素が画面の描画領域に入って実際に描画されたことをイベントとして検知できる仕組みである（実際はもっと複雑なのでちゃんと調べて欲しい）。しかしこれはまだ仕様策定段階であり、広くクロスブラウザで使えるようになるのはおそらく東京オリンピックよりも先の話になるだろうと思う。

今日残しておきたいのは、この仕様、APIに対する期待と、その期待に対する葛藤だ。

IntersectionObserverはつまるところ、Webの「領域」に価値を与えられる仕組みである。たとえばニュースサイトを考えたときに、本文の末尾まで読まれる記事と、見出しだけで離脱される記事とでは、そのページ内の領域の価値がまるで違う。記事本文の横に広告のバナーが出ているとして、8割の人が完読する記事と4割の人が完読する記事では、その記事に対して広告を出すインセンティブが雑に2倍変わってくる。 今まではそれはDOMにマーカーを仕込むとか、いろいろ工夫を重ねて、「広告が本当に目に届いているか」を数値化しようとしてきた。それを、Web標準の技術として、それも広告の要素側で自分自身が表示されたかどうかを独立して検知できるとなれば、世界は大きく変わる。「このサイトに広告を出していたけどほとんど目に届いてないことがわかった」とか、「このジャンルの記事は完読される確率が高いから広告枠が高く売れる」とか、そういった収益モデルが容易に立てられるようになる。

一応但しておくと、僕の持論として、Webは金を稼げるべきであると思っている。本来は広告などに頼らず、Web自体が収益をもたらし、それを動力にWebは進化すべきだと思っている。ただし現実として、現在のWebに金を稼げる力は弱い。ごく限られた優れたWebアプリケーションやサービスはサブスクリプションモデルで収益を挙げられているが、いろいろな資料で言われているようにWebは利益につながっていない。リーチする力はあってもそこから金を払わせるに至っていない。それでもWebを商売としてやっていくとすれば、それはユーザーから金を取らず、広告で儲けるしか無い。

IntersectionObserverはもちろん広告のためだけにある仕組みではないし、パフォーマンス改善や計測など用途は幅広いけども、しかし金になりそうなのは確かで、Webにおける広告モデルを支援できるはずの技術だ。見られていない広告は下ろし、よく見られている広告に金を出す。市場として当たり前の価値付けができるようになる。

ただしそれが本当に正しいのかどうかも悩んでいる。広告に頼らないと収益が出ない状態はWebとしてよくない気がしている。Android Payとか、Apple Payとか、Webでも支払いが可能になる基盤がだんだん出来つつある。Webのコンテンツが広告なしに、それだけで自立できる収益モデルが確立しないとダメなんじゃないかと思ってる。

IntersectionObserverは欲しい、とても欲しいんだけど、それを欲しがっている自分の状況が間違っているんじゃないのかという葛藤もあり、悩ましいなという今日このごろ。一刻も早く、AndroidやiOSのアプリのように、Webでも当たり前に収益を上げられる時代が来ることを祈る。

今日のレシピ

ごはん


f:id:laco0416:20170114200111j:image

 

  1. 白菜と水菜と鶏もも肉を鍋に入れる
  2. 水600mlと本だしの袋半分突っ込んで20分グツグツ
  3. おしまい

 

結果

  • うまい　ポン酢最高

 

反省点

  • 切った順に入れちゃったので鶏肉が上にきた　鶏肉を最初に入れたかった

source-mapの正当性についての検討

プログラミング

あるsource-mapが、本当にソースコードの各行に対応したマッピングを行えているかどうかを評価したい。

背景

github.com

light-ts-loaderというwebpackのloaderを作っていて、このloaderを使ったときに吐き出されるsource-mapが自分のloaderのせいで壊れていないかを保証したかった

問題

何を以って "正しいsource-mapである" とするかの判定が難しい。 たいていsource-mapが壊れているとわかるのは、Webブラウザの開発者ツールで開いて、ブレークポイントを打って、リロードしても見当違いの部分でデバッガが動いたときだ。 この時、 "見当違いの部分で" というのは完全に人間の判断によるものなので、機械的に評価するためにはなんらかの基準を与える必要がある。

計画

今回のloaderはTypeScriptからJavaScriptへの変換なので、TypeScriptのバージョンさえ固定されていれば入力に対して出力は冪等であることが利用できる。 変換のパスは TypeScript(module.ts) -> JavaScript(module.js) -> JavaScript(bundle.js) の2段階なので、source-mapを利用して最初のTypeScriptのあるポジションに対応するbundle.jsのポジションを取得し、そのポジションのコードが最初のTypeScriptコードのトランスパイル後コードと一致すればいい。

つまり、次の module.ts の return { str }; と bundle.js の return {str: str}; を結ぶsource-mapであれば "正しい" と言えそうだ。

module.ts

export function wrap(str: string) {
    return { str };
}

bundle.js

// ....
function wrap(str) {
    return { str: str };
}
exports.wrap = wrap;
// ....

実施

愚直に書いてうまくいった。理論上はコード断片のハードコードなしにTypeScriptのAPIを使ってトランスパイル前後のコードを照合できる気がするが、そこまでする気力はなかった。

https://github.com/laco0416/light-ts-loader/blob/master/test/test-source-map.ts

反省

もっと汎用的に書きたい。暇があったら頑張る。