@pikaツールチェーンの一部である@pika/webは、複雑になりがちなバンドリングプロセスを選択操作に転換することで、Webアプリケーション開発者のエクスペリエンスの向上を目指すものだ。@pika/webを使用すれば、最新のnpmパッケージを、ブラウザ内でダイレクトに実行できるようになる。Browserify、Webpack、import mapsといったバンドラは、もはや必要ない。
この数年間で、Webアプリケーションの記述、開発、テスト、デプロイに必要な一連の技術は大幅に向上した。 npmでは、先日公開した2019年の展望の中で、この点について概説している。
"2018年のJavaScriptは、多くのツーリングを必要とすることによって、いささかの悪名を馳せることになりました。2014年の状況とは正反対です ... 私たちが実施したすべての調査において、作業着手時のツーリングやコンフィギュレーションを少なくしたい、という要求が見られます。"_
実際にJavaScriptのバンドル作業は、運用時のみ実施する最適化作業から、ほとんどのWebアプリケーションに必要なビルドステップへと進化した。既存のバンドラを使用するには、バンドルの仕組み、さまざまなモジュール形式とパターン、まとまりなく長い構成オプションを理解し、絶えずリリースされる新しいバージョンで最新の状態に保つ必要がある。上級者にとっても、難しいタスクだ。
JavaScriptエコシステムの中には、CommonJS(CJS)、Asynchronous Module Definition(AMD)、Universal Module Definition(UMD)、ES module(ESM)のいずれかの規則に従ったパッケージが共存する。@pika/webは、最新のESモジュールのみに注目することにより、モジュール形式の相互運用性とアプリケーションバンドリングに関わる複雑さを取り除くことを、開発者に対して約束している。
アプリケーションへの組み込みをESモジュールに限定する、という点を開発者が認めれば、@pika/webは一切の設定なしで、すべての依存関係を最適な方法でインストールし、バンドルしてくれる。リリースノートでは、次のように説明している。
@pika/webは、最新の
npm依存関係を、それら自身の依存関係も含めて、ブラウザでネイティブに実行可能なようにインストールします。それだけのことです。
ビルドツールではありませんし、(従来の考え方で言う)バンドラでもありません。@pika/webは依存関係のインストール時に使用するツールであり、他のツールの必要性を大幅に減らし、WebpackやParcelを完全に省略することを可能にします。
@pika/webはnpmパッケージを、新たに作成する"web_modules/"ディレクトリ内の単一の.jsファイルとしてブラウザにロードし、ネイティブにインストールする。@pika/webを使用するには、パッケージをインストールした上で、インストールされたパッケージのパスを反映するようにimportを変更する必要がある。
# 1. Run @pika/web in your project:
$ npx @pika/web
# 2. Replace all NPM package imports in your web app with web-native URLs:
- import { createElement, Component } from "preact";
- import htm from "htm";
+ import { createElement, Component } from "/web_modules/preact.js";
+ import htm from "/web_modules/htm.js";
# 3. Run that file directly in the browser and see the magic!
~(￣￣~)(~￣￣)~
# (Optional) If you already use Babel to build your application, skip "Step 2" and let our plugin rewrite your imports automatically:
echo '{"plugins": [["@pika/web/assets/babel-plugin.js"]]}' > .babelrc
# (Optional) Add a package.json "prepare" script to run @pika/web on every npm install:
{"scripts": {"prepare": "pika-web"}}
@pika/webのようなパッケージをモジュール単位でバンドルする方法には、パフォーマンス面でのメリットもある。ビルドされたWebアプリケーションには、高速な動作と、適切なキャッシュ利用が期待できる。ひとつの依存関係の更新が、アプリケーション全体の再ダウンロードを強制しないためだ。一般的な問題である、バンドル全体でのコードの重複や未使用ないし無関係なコードによる初期ページのロードの遅延、アップグレードに関わるさまざまな問題やバグなども、回避できる可能性がある。
一部の開発者が注目し、強い支持を表明している。
@pikapkgには本当に驚きました！現在のワークフローを維持しながら、バンドラなしでVueJS、VueRouterなどを（.Vueファイルを使って）利用できるのは、素晴らしいギフトです)。
素晴らしい！2019年はWebにとって最高の年です。シンプルに、高速になりました。
マイナス面として挙げられるのは、Webpackなどのバンドラで生成した大きなJavaScriptファイルの方が、一般的に複数の小さなファイルよりも圧縮率が高く、構文解析も早いことだ。さらに、2019年2月28日の時点において、ESモジュールをベースとするnpmパッケージは6パーセント(50,000)に過ぎない。また、ESMはすべての最新のブラウザでサポートされるが、IE11やAndroid用のUC Browserではサポートされていない。Pikaチームは、独自に費用対効果を評価し、結果をTwitterに投稿した。
ある程度のサイズがあれば、アプリケーションソースをバンドルすることで、実稼働用にサイトを最適化したいと思うことでしょう。しかし、私たちが今回確認したのは、中小規模のサイトにおいても、キャッシングの向上と複雑さの軽減が、バンドルの不足を補う以上のものである、ということです。
(…)2019年は、要求ではなく、必然としてバンドルを使用しなければならないのです。
@Pika/webはまだ、かなり新しいツールだ。初期段階(v0.4)にあるため、2019年中の最初のメジャーリリースは期待できそうもない。
ゼロコンフィグレーション開発者エクスペリエンスを提唱する他のパッケージには、Parcel bundlerやZero Serverプロジェクトなどがある。InfoQでは、後者について先日レポートしている。
@Pika/webは、MITオープンソースライセンスで使用可能である。コントリビューションはGitHubプロジェクトを通じて募集されているが、@pikaパッケージのコントリビューションガイドラインと行動規範(code of conduct)に従う必要がある。