Webフロントの複雑さ
人: サーバサイド人
「webフロントエンドが複雑」と言われる原因は、大きく分けて
ツールチェインの複雑さ
JavaScriptという言語を強い力を持ってコントロールできるプレイヤーが存在しないことにより、ツールチェイン、果ては中間言語としてのASTも乖離していて、それによって生じる複雑さがある
強い奴らがスタンドプレーした結果
例
BabelのAST
acorn拡張
ESLintのAST
acorn拡張
webpackの使用しているacornのAST
@babel/parserのフォーク元ではあるが最新仕様への対応などで差がある
Proposalレベルの構文やTypeScriptへの対応は一切していないなど
TypeScriptのAST
完全に独自
babel(当時は6to5)が登場する前、もしくは今ほど力を持っていなかったからか？
独自ではあるが TS Compiler API によく型が付いているため意外と扱いやすい
解析とエディタでの変更に強い仕様で、update系のファクトリを使うことで可能な限りインデントを保ったままASTを変更できたりする
これによって起きたこと
@babel/plugin-transform-typescript
Babel ASTの上でTypeScriptを変換する
他のBabel Pluginを通すこともできる
TSのES Versionごとの大ざっぱな変換ではなく@babel/preset-envを使う
複雑な変換(CSS in JS、GraphQLクエリの抜き出し、etc…)を適用する
このような利点もあるが、TypeScriptに新たな構文が追加されたとき、後述する@typescript-eslint/parserにおける議論が進まないと@babel/parserに構文を追加することができないという問題がある
新しい構文を使ってヒャッハーできない
@typescript-eslint/parser
typescriptパッケージを用いてTypeScriptをパースして、Babel ASTに変換する
議論が進まないと新たな構文に対応できない
typescript使ってるんだからいけるような気がするんだけど、これを利用してるprettierは新しい構文をパースできなくて死んだりする。なぜ?教えてほしい
webpackでbabel-parserを使っているとき、webpackの使っているacornが対応しているJSを吐いてやらないと解釈できなくて落ちる
最新のChrome/FirefoxはOptional Chaining/Nullish Coalescingに対応しているはずだが、このせいでdev環境において余計な Babel Plugin を噛ませてやる必要が出てくる
そもそもパースが二度手間で無駄
ParcelはBabel ASTをずっと使っているはずだが、webpackより遅い。なぜ？
Rome
ASTを統一してBabelとESLintとwebpackとPrettierとJest、その他もろもろを置き換えるツール
野心的にも程があるが…
こういうツールが希望を持って語られるのが今の状況を象徴している
この部分の内容は大体大統一 Node ツールチェイン Rome の野望 現状の実装 - mizdevの受け売りだったりします
人「そもそもLintやTestのコンフィグが多すぎ」
わかる…
Lintはとりあえずeslint/recommendedと@typescript-eslint/recommendedを入れとけばいいよという話をした
React使ってるならreact-hooksもうれしいかも、exhaustive-depsが邪魔なときもそれなりに多いが
Testもだるいはわかる
でも言語固有のものはあんまり多くなくて、どちらかと言うとライブラリに関するもの
フロントエンドが求められる状況の複雑さ
(従来のアプリのように)リソースを1つにまとめてデリバリーするということが難しい
ページ(やさらに細かい機能)ごとにリソースを分割して、ユーザーができるだけ早くやりたいことをできるようにする
もちろんページごとにバンドルを分けるだけでは足りなくて、各バンドルごとに共通のモジュールを参照しているならそれをまとめたい
その結果としてwebpackのSplitChunksPlugin(optimization.splitChunks)は複雑になる
やりたいことが複雑なんだから仕方ない
これはWebbundleが使えるようになっても変わることはないだろう
バンドルのコストは圧倒的に下がるのでサーバーサイドで能動的にバンドルして返すみたいなソリューションが出現する可能性はある
追記: Webbundleの雲行きが怪しくなってきた…
余談: 逆に既存のアプリもこのような体験を提供するべきではないか？
ユーザーが興味を持ったとき、「じゃあまずアプリストアに行ってインストールしてください」はハードルが高い
オタクは感覚が麻痺しています
リンクをクリックしたら即最小限の機能を持ったアプリが起動して、その裏で他の機能をインストールするとかだと体験がよさそう
FYI: Android Instant Apps に対応するには？
iOSもApp Clipsで可能ではあるらしい by /rinsuki/rinsuki.icon
#ifで縮小したバンドルを作って、App Groupsでいい感じに？
アプリみたいにエントリポイントが1つだと、「機能を制限した小さなAppとフル機能の大きなApp」みたいな構造でいけるみたい
ゲームとかもプロローグをやっている間にインストールをやるとかやってほしい
PS4のゲームとかだとそういうのあったりするらしい
これを考えていたら、XenobladeXの「ロード高速化パック」地獄を思い出した
HDD上に読み込み高速化のために圧縮されたモデルデータと展開されたやつを配置するための領域を確保する
全く使わないとムービー中にロードが入ったりして最悪な体験になるので、最小でも4.5GB、最大14.7GBにもなるパックを入れる必要がある
最悪
いやメモリが1GBしかないシステムでオープンワールドをやろうとしたらそりゃそうなりますが…
ゼルダBotWは仮想メモリ3GBで乗り切っていてえらかった
死ぬほど頑張って先読みしていたらしい…
#フロントエンド #poem