ざっくりしたまとめ

webpackにbabel-loaderとsass-loaderとcss-loaderとstyle-loaderと……

babel pluginでtypescriptやjsxを処理させるか、もしくはそのあたりはts-loaderにやらせるか……

のだが、人類がミニマルなwebpackのconfigに疲れた結果Next.jsとかViteのように少ない設定でだいたいのユースケースがカバーできる新興ツール・フレームワークが生まれてわりと業務利用可能なあたりに来ている

Viteにはdev-serverもcss modulesもbabelもtsもついてるのでreact用のプラグインを入れればすぐにtsxでアプリが書ける。Next.jsはReact特化なのでもっと早い。

create-viteやcreate-next-appのようなcreate-系もあるが、これはwebpackとかをラップしたフレームワーク(なのか？もうずっと触ってないから覚えてない)だったcreate-react-appとは別の路線で、GitHub上にあるテンプレートを持ってくるだけのscaffoldingツールになっている。マニュアルでも十分すぐセットアップできるしいらないといえばいらないが……

さらにJS実装をネイティブバイナリで置き換えるブームが来ているが、これらは新興ツールやフレームワークのチーム (バックに何らかの企業がいることもしばしば、vercel-next-turbo-swcが代表例) から出ていることが多く、そのへんのフレームワークとかに乗っておけば将来的な移行もわりとスムーズにいくんじゃないか

内部の実装が変わって早くなった、ぐらいの見方で済む

Next.jsなんかは開発元のVercelに自社のホスティングサービスに乗せてほしい〜という魂胆があるのでいろいろ言われがちだが、Next.jsに甚大な破壊的変更かまして信頼を失ったら困るので将来バージョンへのマイグレーションで断崖絶壁にぶち当たることはおそらくないだろう、みたいな見方もできる

まあほかプラットフォームへのデプロイ容易性が微妙らしいですが……

フロント詳しくない人から見るとTurbopackやRspackやSWCやesbuildやrolldownやRomeやら新しいツールがドンドン登場するので「webpackやViteはもうオワコンになってしまったのか。フロントエンドは流れが早くてついていけない。」と思うかもしれないが、これらのツールにはレイヤーがありフレームワークに近い上位レイヤーを触るようにしておけば気にしなくて良いしここ最近行われているのはパフォーマンスチューニングなので最新にこだわる必要はそこまでないからやはりフレームワークに乗れ。本質を見ろ本質を

雑記

Next.jsみたいなメタフレームワーク/フルスタックフレームワークを選ぶと楽

長年のあれによるベストプラクティスが集積しだいたいのユースケースをカバーできるいい感じのconfigが提供されていてシュッと入れるだけでいい感じに動くので

Webフロントエンドの各種ツールはTS標準対応が当然になった

DefinitelyTypedプロジェクトがマジですこくてかなりのライブラリに型定義があるし、デファクトスタンダード化しているので新しめのライブラリはそもそもTSで書かれていて型定義が当然ある

JetBrains以外のJS/TS補完はtypescriptパッケージ付属のtsserverが提供している。ソースがjsでも恩恵にあずかっている。感謝

型システム的には不健全性の塊で嘘をつき放題な上に見たことない型がいっぱい出てくるが、ライブラリ作者でない限りconditional typesとかを自分で書く必要はそうそうないので大丈夫

ただしliteral、union、intersectionは必須教養

危険な操作、つまりほぼasとanyを回避すればいいわけだがオーバーロードで嘘つく可能性あるのはまあ……

そもそもNode.js vs Deno vs Bun

Node.jsには既存の巨大なエコシステムがあるのでまだ全然死なないが、特にDenoは使おうと思えば全然使えそう。DenoやBunの動きがNode.jsや界隈に影響を与えている面はある。

Node.js作者のライアン・ダールがNode.jsの設計上の失敗を直すという感じで始めた

独自APIのNode、標準APIのDeno

DenoはWHATWGのfetchやStreamなどのWeb標準APIを実装していてNodeも追従したりしなかったり

エコシステムの強さは標準がどうとかより重いことがわりとあることに注意。標準なのでエコシステムが将来的に広がっていくだろう、という見込みはできる

現在PaaSで企業化しているのでNode.jsないし周辺エコシステムへのdisとかもそこそこ見かけるけどホ〜ンぐらいで聞くのがよい

DenoはRust、BunはZigでの実装を含む

しかしそれらは魂を動かしやる気を出すには十分だけど真面目な技術的利点として捉えるのはそこまでよくない

じゃあ実際Node.jsはC++だった気がするが使ってて気まぐれにメモリエラーで死んだりするか？という話などがある

DenoがNode.jsとエコシステムをギャリギャリに切り離しに行ったのと対照的にBunははじめからNode.jsとの協働みたいな方向

Denoは豊富なビルトインツールがあるのでlintだけ使うとかformatterだけ使うとかもあり

パッケージマネージャ

npm vs yarn vs pnpm

npmも十分早いしNode.jsについてるのでnpmを選んどけばだいたい間違いない

文化的にこれが多いという傾向があったりなかったり

yarnはもともとFacebook発なのでReactなどそのへんで使われていることがある

facebook/react、yarn v1で草

現在のYarnはMetaと関係がないっぽい

lockfileVersionが1, 2, 3とある

yarn v1では独自フォーマットだがyarn v2ではyaml

歴史的にはnpmよりyarnのほうが先にlockfileを導入したので古い記事ではyarnの利点としてlockfileの存在が挙がることがあるが、その記事は古すぎる

バイナリフォーマット

パース処理などが効率的だがgitでdiffがとりづらい

が、デバッグとかで各種のOSSプロジェクトを触るとどっちみちyarnとかpnpm (bunはまだ見たことないがそのうち見ることになると思う) が必要になるので全部使うことになる

antfu/ni

わかるよ

azu/ni.zsh

Denoはそもそもnode_modulesがよくないという考えからURLベースのパッケージ管理に移行した

フォーマッタ

Node.jsではおそらくPrettier1強

Denoにはdeno fmtがある

フォーマッタでは設定項目の少なさは美徳

Prettierはバージョンアップで細かいフォーマット結果が変わりそのへんの調整ができないのでそこが気に入らない人はいるが、そのへんも含めてsimplicity

linter

このごろのESLintはformat関連のルールをrecommendedに含めていなかったが、最近のリリースでついに本体から切り離されたので本体を普通に使っているだけではPrettierとの競合は起きない。別に設定する必要はある

denoにはdeno lintがある

この2つはRomeと後継のBiomeがライバルになりえたが現状はどうだろう。Denoをそこだけ使うというのもありえる

バンドルの必要性

ブラウザで大量のファイルをダウンロードすると重くなる

Viteでモジュールが多いプロジェクトを開発してると (localhostはHTTP/1.1なので) 露骨に遅い

HTTP/2でもpreload入れても重い

って誰かが言ってたので後でソース探す　デモとかもあったらいいね

Webpack

古参バンドラ

設定が大変で筋肉が必要と言われる

思想がminimalとかsimpleに寄っているためかんたんに使える感じではない。具体的にはwebpackがやることはバンドルだけで、loaderというプラグイン的なやつ (webpack pluginも別にあるのでこういう説明をするとややこしくなるのだが) を入れないとトランスパイルとかはやってくれない

zero-configでも使えるということが言われているが、ViteやParcelのようなCSSとかの処理までzero-configというわけではない

simpleがよく美徳といわれるが適切なツールやloaderを選定して設定するのもそれなりに難しいし人によっては非本質的な面倒事に映る

dev serverすら標準搭載ではない

頭小文字のwebpackが正式だったらしいけど今はどっちでもいいらしい

Webpackの設定が書けない人たちを救済するために現れた

zero-configの流れを作ったかもしれないな

dev serverのアーキテクチャはViteよりwebpackに近い

Vue作者のEvan Youが始めたやつ

Parcelみたいな設定の少なさ

開発時にはnative esm対応のモダンブラウザ使うんだしdev serverはnative esmそのまま配布してよくね？という思想

爆速なdev server + hot reloadingを実現したが、モジュール数が増えてくるとたとえlocalhostだろうと往復回数が増えまくって特に初回の読み込みが重くなる

PureScript Halogen + Viteでかんたんに再現できる。そういうのもあってかPureScriptではParcelを使うのが主流っぽい

ツールチェインの脱JS化

Babel、webpackなどのツールは今までJSで書かれNode.jsで動いていたがGoやZig、そしてRustのようなネイティブバイナリが出る言語で書き直す流れがわりとある

どれもフルスクラッチから開発中で既存ツールなどの機能やプラグインがまだまだ不足しているところがあるので宣伝文句をそのまま受け取って既存ツールはオワコンとか安易に言わないように

欠点としてあるのが

実行ファイルがプラットフォーム依存になる

x86_64のwin/mac/linux、aarch64のmacはだいたいあるので困らないといえば困らないかもしれない。逆にこれらも揃っていないツールは初期すぎるのでまだ使える感じではない

NixOSやBSDのような異常環境で動かない確率が高まる

パフォーマンスを犠牲にしたWasmビルドでなんとかという説もある

ネイティブバイナリはブラウザで動かない

JS実装だろうともともとNode.jsのAPIに依存してたら動かねえという話はある

わざわざブラウザでツールチェイン動かすユースケースはだいたいそんなパフォーマンス求められないしWasmで動かせばいいじゃんという説もある

ネイティブバイナリはCDN edge workerで動かない (ことが多い)

サイズ制限などが存在するとWasmで乗せるのも厳しいことがある

プラグインがJSで書けないことがある

JSで書けても言語またぎになるのでパフォーマンスが落ちる、かも (調べてはない)

ソースコードがJSではない

バグ調査や修正などの際には別の言語を学習する必要がある

まあ多数のプログラミング言語に触れることでJS含めて総合的ななんか力が養われるのでやればいいと思うがそんな暇ではないこともある

wasmについて

たとえばesbuildはマルチスレッドでの実装がGoのWasmコンパイルがシングルスレッドなのと噛み合ってないしNode.jsのWasm実装は遅いのでネイティブバイナリが動く環境でわざわざWasm実装を使うのは非推奨と言っている

より上位レイヤーのツールがそっちをデフォルトにするころぐらいが使いどきだと思う

LightningCSS (Rust)

PostCSS代替。Parcelだったかから出てViteのexperimentalにもいる。

SWC (Rust)

Speedy Web Compiler。SWR (State While Revalidate) とは関係ない

レイヤーとしてはBabel代替

Next.jsでデフォルト化、babel configがあればbabelを使う

swcpackというバンドラを作ろうとしていたがサ作者がVercelでTurbopack作ってるからおそらくそっちに移った

Turbopack (Rust)

Vercel、Next.js

今のところNext.jsのdev serverでしか使えない

Viteみたいなアーキテクチャじゃなくても高速になるらしい

Rspack

esbuild (Go)

トランスパイラ+バンドラ。バンドラはViteのような準フレームワークではなく、総合的にはBabelとwebpackが合わさってる感じ

transformだけで使うことも可能で、Viteではそういう感じ

esbuild-loaderもwebpackのバンドルには介入しない。babel-loaderやswc-loaderと同じ

Bun build (Zig)

誰かがesbuildのzig portって言ってた気がする

Biome (Rust)

Romeという大統一ツールがあって会社化とかRustで書き直しとかを経たが資金繰りがショートして事実上終了、商標とかが会社に掴まれているのでメインメンテナがofficial forkという形で分離した