parcelの時代が中々はじまらないので使いみちを見出してみた

ソフトウェア開発

2019/12/4 03:00

ゼロコンフィグなモジュールバンドラとして有名なparcelですが、私の周りで「実務で導入しているよ！」という声はあまり聞きません。今回はそんなparcelの強みを生かし、実務で導入して世界が平和になった話をしてみようと思います。

2年前のちょうど今頃、webpack時代の終わりとparcel時代のはじまりという記事がWebフロントエンド界隈で小バズリしていました。当時新規Webサービスの立ち上げをしていた僕は、webpackのドキュメントと戦いながら苦労してフロントエンドの環境構築したばかりだったので、「なんなのフロントエンド界隈、頭おかしいの？」と悲しい気持ちになったのを覚えています。

それから2年の月日が経ちましたが、相変わらずwebpackはデファクトのままで、一向にparcelの時代が訪れる気配はありません。正直なところ、開発環境の構築・設定にやたらと時間がとられるのは、Webの歴史的背景があったとしても面倒くさいとしか言いようが無いので、ぜひともparcelの時代を始めてもらいたいところです。

なぜparcelの時代がはじまらないか

parcelは非常に優秀なデフォルトの設定を持ち、モダンフロントエンド開発に必要な大抵の事を実現してくれます。2年前と比べても、コードスプリッティングやHMR、対応するアセットの数やプラグインも増え、多くのユースケースに耐えるようになったと思います。それでも僕も含めて本番でparcelを使ってプロダクトを運用している人は周りであまり聞きません。

仮に自分が新規サービスを作る際にparcelの採用を考えると、以下の懸念が残ります。

• 少し凝ったことをしようとするとほぼ積む
  • それでも頑張ってプラグインを組み合わせていると、ゼロコンフィグってなんだっけとなる
  • ゆっても最小構成のwebpackの設定は意外とシンプルで導入コストも低い
  • じゃぁwebpackで良くない？となる
• 運用時の問題解決は知識なしでは難しい
  • 結局内部で何をしているのかを知らないといけない
  • じゃぁwebpackで良くない？となる

要するに環境構築のコストは低いが、長期運用をするにあたってのメンテ・学習コストは本質的にwebpackとあまり変わらない。それどころか問題への対応オプションが少ないという点で大きな欠点となる。

結果として、webpackをある程度知ってる人にとってはメリットが薄く、あんまりよく知らない人にとっても運用時の問題解決にリスクがあるので、**真面目に運用することを想定したプロダクトにおいてはparcelの時代が中々はじまらないのでは？**と考えています。

事実、npmtrendsを見ると今の所parcelの時代が始まる気配はほとんど無いように思えます。

https://www.npmtrends.com/parcel-vs-webpack

使いみちを見出してみた

一方で、parcelは開発環境のことを何も考えずに、コードを書くことに集中できるという、昨今の複雑化したWebフロントエンド界隈において非常に大きな強みを持っています。

メインプロジェクトでは中々日の目を浴びないが、逆に言えばサイドプロジェクトこそその本領を発揮するのではないか？そうだ、webpackと比較するからダメなんだ。もっとカジュアルに試せる場所でこそparcelが活きるはず！

ということで、今回たまたまInstapageというLP制作ツールのjs拡張のコードを書く機会があったので、その事例を通じてparcelの実務での使いみちはサイドプロジェクトにありということを伝えようと思います。

Instapageってなに

InstapageはLP制作に特化したCMSで、ドラッグアンドドロップでUIパーツを配置し、レスポンシブ対応のLPを作成できるツールです。他にも、A/Bテストやヒートマップなどのページ内の分析ツール、各種MAツールとの連携をビルトインで備えており、Instapageを使うことでマーケタがLP制作から運用・改善までを一気通貫できるようになります。

これまで自社で広告用のLPを制作するケースは何度もありましたが、なけなしの開発リソースを注いでページを作ったものの、その後ページの改善はほとんどされなかったり、最悪の場合作ったけど運用してないこともも有りました。

この問題は、LPの制作スキルを持っている人間が広告成果について責任を持っていないため発生していると考え、マーケタ自身がLPの制作・運用・改善をある程度自立的に実現できるようにするべく、Instapageを導入することにしました。

困ったこと

Instapageは、ほとんどのページ制作をそのWYSIWYGエディタ上で完結することがでますが、例えばフォームのバリデーション、別サービスへのAPIリクエストやエラーハンドリング、細かい入力状態のロギングなど、ある程度凝ったことをしようと思うとどうしてもデフォルトの機能では実現出来ません。

そのためInstapegeでは、ユーザー定義のカスタムHTML, CSS, Javascriptの拡張機能を持っており、上記のデフォルト機能の範囲外のLPを作ろうと思った場合は自前でコードを書くことで対応できます。

そして、今回どうしてもデフォルトの機能で実現出来ない要求に遭遇してしまい、その部分だけエンジニアがコードを書いて解決することになりました。

日頃TypescriptやReactなど近代のjsパワーの恩恵を受け、モジュール単位のスコープで開発することになれた現代のフロントエンドエンジニアにとって、今更vanilla jsで、グローバルスコープを気にして、レガシーブラウザ(IE)のためのコードがどうのこうの・・・などという辛い環境でコードを書きたくありませんでした。

でも、ちょっとした拡張のためのjsコードを書くだけなのにwebpack使って環境構築するのもどう考えてもバカらしすぎる。

「俺はただTypescriptで書きたいんだ。UIをReactで書きたいだけなんだ。非同期処理にasync await構文を使いたいだけなんだ。」

そう考えている内に、自然とparcelをinstallしていました。

parcelの環境構築

yarn init -y

yarn add -D parcel@next

終わり。その他、TypescriptとかReactとかやりたいことに応じてインストールします。

Typescriptなんかは、tsconfig.jsonをルート直下に配置し、拡張子をts, tsx にしておけばビルド時に勝手にコンパイルしてくれます。最高。

開発中

↓で 開発サーバーが起動します。--httpsオプションをつけるとローカルの証明書が生成され、ビルドしたアセットをhttpsで配信することができます。

parcel --https entryPoint.ts

ここで配信されるアセットのurlをInsapageの編集画面で読み込めば、エディタで書いたコードがそのままInstapageで作成中のLPに反映されます。普段と全く変わりなく、実際のLPの画面を見ながら自前のエディタで開発を進められるDXは本当に最高です。

デプロイ

↓でプロダクション用のアセットファイルがビルドされます。

parcel build entryPoint.ts

仮にNetlifyなどのホスティングサービスを使い、githubのmasterブランチが進んだら自動でデプロイされるようにしておけば、デプロイフローもボタンポチポチしておわります。誠に幸せ。

あっという間でした。環境構築とデプロイなどめんどくさい事を完璧にスルーして、終始コーディングに集中できたことが本当に素晴らしい体験でした。

将来的には、マーケタにフロントエンドの開発スキルを習得してもらい、そのままエンジニアの手から離せるビジョンがこの時点で見えました。parcel最高！

その他の使いみち

Instapageだけじゃなく、他の多くのCMSやjs拡張が可能な外部サービスで同様の使いみちがあり得ると思います。現在社内でkintoneのプラグイン開発の用途でwebpackを使っていますが、webpackのバージョン更新についていくのがだるいのでparcelに切り替えようかなとも思っています。実際、kintone jsカスタマイズ開発における webpack時代の終わりとparcel時代のはじまりという記事をみるに、kintoneのプラグイン開発界隈においてはすでにparcelが始まっている模様です。

また、仮説検証用のプロトタイプの作成や、社内向けの実験的なプロダクトなどの用途など、スピードと手数が重要なシーンにおいても非常に魅力的な選択肢になるのではないかと思います。実際に本格的に運用開発するとなれば、webpackに単に乗り換えればよいだけなので、時間対効果が非常に高い選択肢だと思います。

もしかするとWeb制作の現場であればもうすでにparcelで環境構築するのは実務レベルでもありなのかもしれないとも思いました。

ちなみに、parcelはnode.jsをターゲットにして使えるので、AWS LambdaとかでTypescript使いたいときとかも有効かもしれないです。思ったより応用範囲が広い。

終わりに

試しに実務で使ってみたら、最終的に思ったよりも使いみちあるじゃんという結論になりました。それによって自分の中で勝手にparcelの時代がはじまりました。何事もやってみて、良し悪し確かめるって重要ですね。

次回は@kamesenninさんの「職種横断でgithub/zenhubでプロダクト開発をして幸せになった話と見えた課題と今後」です！お楽しみに！