The Lightweight Interactive View Representation

(pronounced as 'liver'!?)

Fast to show, in every platform.

Use cases

Browser Rendering daemon which produces Livr from html
HTTP Response Livr instead of html for faster rendering
UI Common UI representation for every platform
Interactive Image Use like 'Interactive GIF'
Office Suite United standard of rich document format
And more, and more!

Features

Standalone Just show it. done. All resources are in it.
Fastness Fast to create, fast to view.

Specification

store as msgpack.

meta:
 title: Hello
 <thumbnail等>
body: |
svg or something...
placeholder:
  identifier:
    where: <Place spec>
    default: <body>
dynamic: <js code, ID=identifier replaced>

課題

DOM操作の置換 v8組み込み変数をW3Cに従ってGUI的に書き換えてグリグリすればいいんだろうけど、、、どうなんだ？実際それでは「速い」とはいえないかも。
動的部分、静的部分静的解析が必要になる。固定DOMはほんとにガチガチにして圧縮。もうSVGでいいよ。
CORS
目標は？

HTML -> Livr -> ViewがHTML -> Viewと同品質になる。Webアプリが動く。(それはデータ量が少なく、なるべく早い)

レンダラ

https://github.com/lexborisov/Modest か？ WebKit/Blink/Servo使いたいけどなぁ... https://github.com/wkhtmltopdf/wkhtmltopdf この実装参考にする。 DOM操作列挙し、操作外をSVG化、操作内をplaceholder化する

過度に一般化し過ぎでは問題

やりたかったこと→chromium撲滅→手段としてのrenderd+IR

State → Input(loaded) → Rendered Livr(depends on state) とかは。画面サイズ変更とかでもstate変更でok.

結局クライアントが処理しすぎだな。それが一極集中しただけだしもしかしたらSPAの部分レンダリングのがはやいやもしれぬしそもそも多重レンダリング大杉

問題

chromeのタブごとのプロセスは何やってんだ!?!?お前見えてないぞそもそも

レンダラが常駐しなきゃいけない理由はなにか -> JSによる動的更新が起こりうる

Webページは"止まらないもの"かつ"相互作用的(ユーザーに限らず、プッシュ通知など)" →次の表示は予測不可能

共通化はできっこない

問題

なんでもクライアントサイドでやろうって風潮あるけど、頭大丈夫か？>SPA 普通に考えて鯖が楽しちゃだめでしょ

だが、鯖にやってほしい"仕事内容"はユーザーの操作に依存する。

X転送かよ

勝手にやってろ

coord-e/livr.md