🐢

Frontend Study #1: 基調講演 - Frontend 領域を再定義する

2020/11/09に公開2件

JavaScript

Front-End Study #1「Cloud Native時代のフロントエンド」 - connpass の発表内容のテキスト版です。

発表に載せられなかった参考資料集

@mizchi / Plaid, inc
Frontend Engineer
React / Node / SPA
Web の最新技術で新しい体験を実証 - 提供するのが好き

今日話す内容

この10年の振り返りと最近のトレンド
next.js に見るベストプラクティス
フロントエンドの領域の変化
Cloudflare Workers が切り開く新領域

はじめに

自分は Frontend というより Node.js Engineer に近い
最先端〜近未来の話をするので、肌勘が合わない人はいるかも
本スライドは Rails に喧嘩を売りますが、Rails が歴史的に果たした役割を否定するものではありません

ふりかえり

IE First の時代の終わり
Frontend において Node.js が支配的なポジションに
「動くテンプレートエンジン」が当たり前に

IE First 時代のおわり

「IEで動かないから仕様をIEに合わせる」 =>「モダンブラウザ水準を満たさないIEは段階的に切り捨てる」
サポートしないわけではないが、足を引っ張る場合は切る
本音: IE対応をやりすぎると、モダンブラウザの経験値を稼げない…

Node.jsによるフロントエンド

Rails Sprockets などの言語/フレームワークごとのプリプロセッサが廃れた
Node.js によって Frontend Toolchain が提供されるようになった

動くテンプレートが当たり前に

仮想DOM技術による宣言的UIが普及
「テンプレートエンジン」の役割が、昔ながらの文字列の生成ではなく、木構造とその後のロジックも管理することに変化
現状はJS以外の選択肢がない

最近のフロントエンドの流行

パフォーマンス指向
「設計より規約」
Modern JavaScript ≒ TypeScript

‘JavaScript is CO2’ by Alex Russell (Google) 2018

JavaScriptはウェブのCO2です。私たちはそのうちのいくつかを必要としていますが、多すぎると生態系全体が危険にさらされることになります。最も多く排出している人(訳者注: 開発者)は、生態系が崩壊するまで、その結果に苦しむことから最も遠い存在です。JS の排出量をコントロールしない限り、ウェブはコンピューティングが向かう市場やフォームファクターで成功することはないでしょう。

近年のパフォーマンス指向

Lighthouse によるスコア化
WebVitals による SEO への影響
フロントエンド技術は SPA の為の技術ではなく、「Webのベストプラクティスを実現するもの」へ

Opinionated な「設計より規約」

Deno
Rome
Blitz

Deno

Node.js オリジナル作者の Ryan Dahl による新しい Rust + V8 の JS 処理系
npm エコシステムを否定し ESM の URL パスから依存解決
実行時に明示的に権限を付与するサンドボックスモデル
TypeScript First

Rome

Babel オリジナル作者 sebmck によるNode.js 大統一ツールチェイン
Babel, ESlint, Webpack, Prettier, Jest を置き換える
外部ライブラリ非依存で自前の Parser / AST で統一
TypeScript First

Blitz.js

Next.js + Prisma ORM = Fullstack
ベストプラクティスの詰め合わせ + Code Generator
- react-query / react-final-form / zod / etc…
isomorphic なリモート関数呼び出し(meteor 風)
TypeScript First

なぜ今まで Node の Fullstack Framework が流行らなかったか？

よい ORM がなかった
- Node.js 初期は Monolithic な Rails への反動があった
- Express は小さいミドルウェアの集合体
Node.js のエコシステムが安定せず、取捨選択できなかった

Prisma2

「Node.js に良いORM がない」という状況を覆せそうな ORM / Query Builder
宣言的 Migration: 専用のIDLの変更から自動でマイグレーションを生成
TypeScript Friendly: TSの柔軟な表現力でどんなクエリにも型が付く
SQL First: 自然な SQL と対応する API

Prisma2 の影響

Prisma を使うフレームワークの開発ラッシュ
Blitz.js: Next.js + Prisma2 + Code Generator
Redwood.js: React + Redwood Router + Prisma2
Frourio: MS製 TS First な API サーバー

Modern JavaScript = TypeScript

良いコード = 型があるコード
良い設計 = 型が付くAPI
良いライブラリ = 型定義(.d.ts)が提供されるライブラリ

まとめ

Frontend Toolchain は Node.js に集約された
Node.js周辺は枯れつつあるが、実績がある開発者の Opinionated なオーバーホールも同時進行中
新規に開発されるものは、TypeScript First

Next.jsから学ぶベストプラクティス

Next.js とは何か

socket.io の作者 Guillermo Rauch 率いる Vercel が開発
- Vercel: SSG + Serverless に最適化された PaaS
(元々は) React の SSR Server + Routing をセットで提供するフレームワーク
初回レスポンスは SSR で返却し、以降の遷移を CSR で引き継ぐ(よくあるSPAの構造)

Next.js Multi Paradigm Framework

複数の実行・出力モード
SSR
- Server
- Serverless
SSG
- SSG Export
- Incremental Static Regeneration

Next.js: Incremental Static Regeneration

SSG mode を動的に実行する形態
cache を返しつつ、expire したものを裏で入れ替える
Backend は更新頻度が低いCMS などを想定

Next.js が実現したこと

(Next.js 登場以前の) 非常に複雑な SSR/CSR を隠蔽
Node.js のフロントエンドツールチェインと、SPA/SSR のベストプラクティスを、一つのフレームワークに
Vue Nuxt, Svelte Sapper(SvelteKit) というフォロワー

議論: そもそも SSR は必要？

ほとんどのケースで必要ない
- GoogleBot の CSR コンテンツに対するインデックスが数時間遅れる問題
Nodeサーバーを持たないメリットとのトレードオフ
Next.js は SSR しないにしても有用

Next.js から学ぶベストプラクティス: まとめ

複雑な SPA/SSR を隠蔽し誰でも使えるように
Next.js+Vercel は SSG/Serverless でマネージレスな方向に進化

フロントエンドの領域の変化

Legacy Monolithic Framework (Rails, Django, etc…)
API Server + Single Page Application
シングルファイルな 2010s Monolithic SPA
ルーティングごとに chunk 分割された Modern SPA
Backend API + SSR
Blitz Fullstack Style

Blitz Fullstack Style

ORM + Next/Nuxt は、 Monolithic Rails へ先祖返りする
もはや Frontend Engineer ではなく、本来の Application Engineer
範囲が広すぎるので、おそらく再び分業が発生しそう
まだ流行ってない。これから

議論: 今の Frontend Engineer をなんと呼べばいいか問題

(New) Application Engineer?: Backend 中心のNode.js エンジニア
Frontend Ops Engineer?: ビルドツールチェインを管理
Design Engineer?: Markup + JavaScript
CDN Edge Engineer?: CDN 周辺を管理

想定反論: 「Node.js エンジニアのポジショントークでは？」

認めるが、現実的にフロントエンドはJS以外厳しい状況
自分はJS(ES5) が嫌で AltJS マニアだったが、 ES201x + TypeScript で満足。V8 は速度的にも十分。
WebAssembly に期待
- Rust: yew, dodrio, percy
- C#: Blazor WebAssembly

他の言語のための、 Node.js Frontend の倒し方

宣言的UI+Next.js を WebAssembly で実装する
- 現状は Rust + wasm_bindgen が現実的だが、Rust がアプリケーション層を書くのに向いてるかというと…
- GC付き言語は、 WASM GC が仕様化されるまで、出力サイズが厳しい
エコシステム成立には、Wasm Binary の多言語間 Linker 仕様が必要かも

「他の言語によるJSツールの再実装は新しいトレンドか？」 by Dr.Axel

esbuild: JS/TS Compiler (Go)
swc: JS/TS Compiler (Rust)
volta: Rust nvm alternative (Rust)
fnm: npm alternative (Rust)

「言語によって向き不向きはあるので長所を活用すればいいけど、JSで書くことでドッグフーディングにもなるし、コミッターも集めやすいよ」 by Dr.Axel

まとめ

フロントエンドのベストプラクティスは SSR の是非に関わらず Server Application 層を侵食
Node.js は Prisma ORM で Fullstack Framework (主にRails) に再挑戦
他の言語が追従するには時間が掛かりそう
TypeScript + 部分的に Rust が、しばらくベストな選択肢

Cloudflare Workers が切り開く新領域

Cloudflare Workers

CDN Edge で動く(!!!) Node.js
結果整合の Workers KV、強整合の Durable Objects
CDN Edge による高い応答性と、 1 req あたり CPU Time 50ms, Memory 128MB という強い制約

他の CDN Edge Worker 実装

AWS Lambda@Edge: Lambda の Edge 版
Fastly Compute@Edge: WebAssembly を Edge にデプロイ
Akamai: Edge Workers

Cloudflare Workers が他社サービスより優れてる点

完成度の高いCLIツール(wrangler)
高速デプロイ
高いパフォーマンス / 応答性
Edge 特性に合わせた Cache API

なぜ Cloudflare Workers が Node.js なのか

コンテナではなく V8 Isolates (プロセス) を CDN Edge 上で並列化
リクエストごとにプロセス割当
最適化には WebAssembly を使う

CDN Edge Workers のできること

自由度の高いキャッシュコントロール
「今と同じNode.jsアプリが動く」わけではない
- CPU制約を満たすアーキテクチャを再考する必要
- パフォーマンス仕様を満たすために WebAssembly がここで必要

「フロントエンド領域を再定義する」まとめ

現状は TypeScript + Next.js(Nuxt.js) がWebのベストプラクティス
おそらく 2020年代は Fullstack Node.js or Jamstack+CMS が、「スタートアップ界のJava」こと Rails を置き換えるだろう
CDN Edge Worker 活用や、Next.js ISR で「静的サイト」が動き出す
WebAssembly はまだまだ枯れてない

課題

学習資料の不足
- 動きが速い界隈のため、資料にまとまる時間がない
Node.js 界における「Rails Guide」がない

Discussion

Frourio: MS製 TS First な API サーバー

FrourioがMS製というのはどこに書かれていますでしょうか？
日本人の個人の方が開発しているように見受けられたので気になっています。
（MSというのはマイクロソフトという意味ですか？）

Yasumasa Ashida

frourio の公式サイトやgithubリポジトリetcを見てみましたけど、どこにもMS(マイクロソフト？)
との直接的な繋がりを示す記述はありませんでした。

下のリンクのポドキャストの最後のほうで、frourioの作者の方がGitHub(M＄買収)やTypeScriptに
乗っかってるのでM＄様様です発言をしてるのが、繋がりと言えば繋がり？(M＄=マイクロソフト)

指摘があったら、普通は、訂正するか、情報源を示して自分の発している情報の正しさを示すか、
するものなんですけど。。。