MD-Blog_Web Creative

今年、フロントエンド界隈、というか個人的に驚いたニュースがありました。jQuery 4.0のリリースです。
3.0以来、約10年ぶりのメジャーアップデートだそうです。まだ開発が続いていたことに驚きつつ、ここでようやくIE10以前のサポートが切られたと聞いて、懐かしい気持ちになりました。

『脱jQuery!?、はじめました。』を書いたのが2017年、入社してちょうど1年の頃なので、もう9年も前になります。
その間にフロントエンドの開発環境はだいぶ様変わりしました。
今回はjQuery 4.0のニュースにかこつけて、この9年の開発環境の移り変わりと、新しい技術をどうキャッチアップして案件に取り入れてきたかを振り返ってみたいと思います。

2017年 脱jQueryとTypeScript

2016年1月にIE10以前のサポートが終了し、2017年頃には案件の対応ブラウザもIE11〜というものが多くなっていました。
もともとjQueryは、ブラウザごとの差異が大きかったレガシーブラウザと戦うために入れていたものです。querySelector や classList がIE11で普通に使えるなら、少し重いjQueryを毎回読み込まなくても良いのでは？ということで、古い環境への対応が必要だったり、使いたいjQueryプラグインがあったりしない限りは、jQueryを抜いて開発するようにしました。

当時のタスクランナーはGulp。Sassのコンパイルや画像圧縮はGulpで自動化しつつ、JavaScriptはjQueryなしで書く、という形です。
要素の選択やイベントの付け外しが少し冗長になったり、スムーススクロールのようにjQueryなら数行で済むものを自前で用意したりと、多少の不便はありましたが、エディタの補完が効くこともあってそこまで困りませんでした。

同じ頃に使い始めたのがTypeScriptです。
IE11が対応しているのはES5までで、ES6の構文の多くは動きません。ただ、TypeScriptで書いてES5に変換してしまえばIE11でも問題なく動きますし、型があるのでエディタの補完もより効きます。jQueryを外した分をTypeScriptで補うような形でした。
このときにjQueryに頼らずJavaScript/TypeScriptを書く習慣がついたのは、その後フレームワークやツールが変わっていく中でも役に立ったかなと思います。

2022年 npm-scriptsとParcel

2022年には『柔軟に対応できるフロントエンド開発環境を構築する 2022』という記事を書いています。

タスクランナーはGrunt→Gulpと移り変わってきましたが、このタイミングでGulpをやめてnpm-scriptsに移行しました。
GruntがGulpに置き換わったように、特定のツールに依存し続けるといずれまた乗り換えが必要になります。それならNode.jsに付属するnpmだけで動く形に戻しておこう、という原点回帰です。ツールのメジャーアップデート対応が不要になり、Gulp時代に使っていたnode_modulesの知見もそのまま活かせました。

TypeScriptのコンパイルは、webpackからParcelに乗り換えました。
webpackは未圧縮時の出力コードが読みにくく、ts-loaderなどの追加モジュールも必要でしたが、Parcelは設定がシンプルで速い。フレームワークを使う開発でも大きな設定変更なしで対応できていて、かなり便利に使っていました。
パッケージマネージャーはこの頃すでにyarnを使っていて、npmよりインストールが速いというのが主な理由です。

2024年〜 Vite

2024年には『流行りのフロントエンド開発環境を使ってみる pnpm ✕ Vite ✕ Typescript』で、パッケージマネージャーにpnpm、ビルドツールにViteを使った環境を試しました。

当時の記事では、ページ数が多くCMSが入る企業サイトには不向きかも、LPやJSメインの案件向き、と書いていました。
ただ、複数HTML出力の自動化など気になっていた部分は設定で補えることが分かり、今ではベースの開発環境もVite + yarn v4になっています。2025年に書いた『フロントエンド開発における自動テストの導入』で紹介したVitestも、このVite環境の上で動かしています。

Parcelも十分速かったのですが、Viteの開発サーバーの起動やHMR（ファイルの変更をリロードなしで即座にブラウザへ反映する仕組み）の速さは、一度慣れると戻れないですね。

ReactとReact Router

UIのフレームワークについては、Vue.jsの書籍に携わったこともありますが、個人的には実務ではReact派です。
MONSTER DIVEの案件でも、APIから取得したデータの状態に応じてコンポーネントを出し分けるような要件が出てくることがあり、そういった状態管理とUIの同期が必要な場面ではReactの宣言的な書き方が見通しが良いと感じています。

画面遷移の作り方も変わりました。
以前は、画面遷移時のチラつきをなくすためにHTMLベースのサイトにPJAX（Barba.jsなど）を別途組み込むことがよくありました。当時は『脱jQuery!?、Barba.js使ってみた。』という記事も書いています。
今はReactを使う案件であれば、React Routerでルーティングしてサイト全体をSPAにしてしまうことが多いです。

BrowserRouterかHashRouterか

React RouterでSPAを作るときに毎回悩むのが、URLがきれいなBrowserRouterを使うか、URLに#が付くHashRouterを使うかです。

できればBrowserRouterを使いたいところですが、これはフロントエンド側だけでは決められません。
BrowserRouterを正しく動かすには、どのURLに直接アクセスされてもindex.htmlを返すよう、.htaccessやNginxでリライト設定をする必要があるからです。

実際の案件では、

• クライアント指定のサーバーで、.htaccessの設置権限がない
• AWSのS3に静的ファイルを置くだけで、CloudFrontなどの細かい設定はできない

といった制約があることも少なくありません。そういうときは、確実に動くHashRouterにするしかないです。
モダンな技術を使っていても、最後はサーバーやインフラの制約とのすり合わせが必要になるのが、フロントエンドの難しいところかなと思います。

外部の人との協業

こうしてベースの開発環境をアップデートしてきたことで、新しい案件の立ち上げは早くなり、品質も安定してきました。
一方で、フォーマット化しすぎると毎回同じような書き方になってしまう、という弊害もあります。「いつものベース環境を使えば動くから」で済ませていると、新しい技術や書き方に触れる機会がどんどん減っていきます。

そうならないために個人的に一番効いていると思うのが、外部の人と一緒に仕事をする案件です。
他社のチームや社外のエンジニアと協業すると、

• 今はこういうディレクトリ設計が主流になりつつあるのか
• このLintルールの設定、気が利いてるな
• 状態管理にReduxではなくZustandみたいな軽量ライブラリを組み合わせる方法もあるのか

など、自分たちのフォーマットにはなかったものに触れられます。

そういう案件に入るたびに他の人のコードを読んで、良いと思ったツールや書き方をストックしておき、案件が終わったらちゃっかりベース環境に取り込んでいます笑
2022年の記事で、他の人の環境の良い部分を自分の環境にフィードバックできるのが良い、と書きましたが、社外の人が相手だとそれがさらに大きいです。
本やチュートリアルで学ぶのも良いですが、実際に動いている他の人のコードに触れるのが一番身につくかなと思います。

まとめ

jQuery 4.0のニュースをきっかけに振り返ってみましたが、Gulp→npm-scripts + Parcel→Viteと、9年でずいぶん変わったなと改めて感じました。

これからも「速そうだから使ってみる」「他の案件で便利そうだったから真似してみる」くらいの気軽さで、新しいものを取り入れていければなと思います。