前編
2012〜2020年 ライブラリやツールが担った役割は今どこに
CodeGrid 700号記念座談会・前編。創刊の2012年から2020年ごろまでを振り返り、jQueryやSass、CSS設計とスタイルガイド、webpackからViteへの移り変わり、Jamstack、アクセシビリティの広がりを、今の開発とのつながりから語ります。
目次
シェア
700号を迎えたCodeGrid
2012年4月に創刊したCodeGridは、2026年10月29日の配信で700号を迎えました。媒体の運営は子育てにも似ていて、14年半が長いようでもあり、短いようでもあり。
そこでいい機会なので、14年半を4つの時期に分け、それぞれの時代の技術やWeb業界がどうであったのかを振り返り、どう現在につながっているかを考えてみました。我々はどこから来て、どこへ行くのか。激動の時代だからこそ、少し立ち止まって。
振り返りにあたって、3名のエンジニアと2名の編集者で座談会を行い、ピクセルグリッドの社内スタッフにもアンケートを取りました。この14年半で思い出深い技術について、それがどんな問題を解決しようとして、その後どのように変わっていったのかを聞いています。
エンジニアの参加者は次のとおりです。
中村 享介（モダンフロントエンド・エンジニア、ピクセルグリッド代表）
矢倉 眞隆（フロントエンド・エンジニア）
渡辺 由（フロントエンド・エンジニア）
ぜひ、読者のみなさんも、自分がその時期に何を考え、何に取り組んでいたのか、それがどう今につながっているのかを考えながら、ご覧いただければうれしいです。
2012〜2016年（1〜200号）
CodeGridが創刊した2012年から2016年ごろは、Webで求められる表現や機能が広がり、それを支える制作手法や道具が変わっていった時期でした。2012年にはiPhone 5が発売となり、スマートフォンが急速に普及していきます。それに伴い、スマートフォンへの対応が制作現場の大きな課題になっていました。レスポンシブWebデザインが広まり、画面の大きさが違っても使えるサイトをどう作るか、増えていくCSSをどう管理するか、どう設計していくのかという悩みもありました。
ブラウザに任せられることが増えた
当時の制作は、ブラウザの外にある道具に多くを頼っていました。その道具で何を補い、その役割がその後どうなったのかを振り返ります。
ページ作りの苦労を、jQueryやPolyfillで補っていた
制作の中心は、まだWebアプリではなく、Webページを作ることでした。悩みの種は、ブラウザごとの対応の差です。CSSの新しい機能などに対応していないブラウザがあれば、Polyfillなどのライブラリで補っていました。
渡辺：ブラウザがそれぞれ好き勝手にやっているし、IEもまだあるし、新しいものもどんどん出てくるし、いろいろなものが乱立していたと思いますね。Polyfillみたいなものも多くて、JavaScriptをいっぱい読み込んでいた気がします。
CodeGridでも、創刊した2012年に「どうする？ブラウザ機能格差の解消」を連載し、CSS3の機能を補うCSS3PIEの使い方や、Polyfillを使う際の注意点を取り上げています。
こうしたブラウザごとの差を吸収してくれたのがjQueryです。違いを意識せずに要素の操作やイベントを書けるようになり、ページに動きを加える作業は楽になりました。
アプリを作るには、jQueryだけではしんどくなった
その後、制作の現場では、ページを作るだけでなく、アプリケーション寄りの仕事が少しずつ増えていきます。
JavaScriptのコードが大きくなると、ページ作りを前提にした知識やjQuery、タスクを自動化するGruntやgulpだけでは、それを整理しきれなくなります。そこに登場したのが、Backboneをはじめとするフレームワークです。CodeGridにも「攻略！AngularJS 1.2」や「快適アプリ開発Backbone.Marionette」といった、フレームワークを扱うシリーズが並びます。
渡辺：私は入社前からCodeGridを購読していて、100号ぐらいから読んでいた形跡があったんです。Webアプリの作り方について、まとまった知識がある媒体はあまりなかった気がして、それもあってCodeGridを読んでいたと思いますね。
この時期より前は、ちょっとややこしいことをしようと思うと、Flashで作っていましたよね。それが、Webでアプリを作れるようになってきた時期です。Gruntとかgulpでスクリプトを組み立てて、Backboneとかも出てきて。JavaScriptが、Webサイトにちょっと色をつけるものから、アプリの屋台骨をやるものになってきた頃ですよね。
中村：アプリを作るにはjQueryだけではしんどくなって、いろいろなフレームワークが出てきた頃でもありますね。
矢倉：ES6が2015年にようやく出てきた頃なんで、ブラウザとしてはこれからという時代だったんだろうなと。特にまだIEがあった時代だったから、それもあってフレームワークが増えていったんじゃないかという気がしますね。
さゆさん（渡辺）がいっていたgulpやGruntっていうツールチェーンに関しては、フレームワークに付随するというよりも、ツールチェーンが先にあった感じだったのかな、という気がします。
ツールチェーンも、こうした変化に合わせて進化していきます。複数のJavaScriptファイルを依存関係に沿ってまとめるバンドラーの機能を備えるようになり、後で触れるwebpackのような、アプリケーション開発を前提にしたツールへとつながっていきました。
スタッフ事前アンケートから：混ざり合うスクリプトをMVCで分ける
Webアプリが複雑になると、HTML、入力処理、データ処理などが1つのスクリプトに混在するようになりました。そのままでは大規模な開発が難しいため、関心の分離としてMVCアーキテクチャを導入し、使い始めた記憶があります。（フロントエンド・エンジニア 松竹 誠）
ライブラリに当時求めていた機能は、やがて標準へ
jQueryや、CSSで広く使われたSassに求めていた機能の一部は、やがて標準でも使えるようになります。jQueryで短く書いていた通信や、Sassで補っていた変数やネストがその例です。
中村：この頃のjQueryとかCoffeeScriptとか、Sassとかを見ていると、それらのいい機能が現在は標準に取り込まれてきたのがおもしろいですね。
矢倉：jQueryにはDeferredがありましたけど、これや他の非同期処理のライブラリのアイデアが今のPromiseにつながっていますね。通信も$.ajax()などの影響を受け、標準にfetch()が登場して、だいぶやりやすくなっています。
中村：Sassも、変数やネストを標準でできるようになりましたよね。
矢倉：そこからさらに進んで、Chromeでは@functionやif()も入っています。あとはMixinもやろうとしていますね。Sassを書いていた人が好きになりそうな機能が、CSSにも入ろうとしています。
渡辺：今はAIに書いてもらうことが多いので、もう手で書かないかなあ。でも、チェックするのに読むことはあるから、AIにも使ってもらったほうがよさそうですね。
人が書きやすくするために求めてきた機能が実現する頃に、AIによって人が直接書く機会も変わってきた。そんな時間差も感じられるやり取りでした。
スタッフ事前アンケートから：Sassに任せていた役割は標準へ
変数を使いたい、値をまとめたい、ネストして書きたい、というのがCSSだけではできなくて、それを補うためにSassを通していました。今はCSS変数やCSS Nestingで足りることが増えて、Sassに任せていた役割が標準の側へ移っていきました。（モダンフロントエンド・エンジニア 中野 祐人）
同じ変化は、画面上の部品にも見られます。かつてLightbox系のプラグインなどで作っていた、ページの上に内容を重ねて表示するUIも、現在はdialog要素などで基本的な部分を組み立てられます。開閉やフォーカスの扱いを毎回一から実装しなくても済み、見た目はCSSで調整できます。
CodeGridでも、「dialog要素でつくるモーダルダイアログ」や「ポップオーバーAPIを攻略する」で、この変化を扱っています。國仲は、Lightboxが全盛だった頃をこう振り返ります。
スタッフ事前アンケートから：なんでもかんでもLightboxだった時代
なんでもかんでもLightboxみたいな時代がありました。今は基本機能自体は標準機能、dialog要素とかで実現可能になったため、通常の場合はそちらで足りることが多いです。でも今でも意外と使われている気がします。クッキー同意や全画面広告、妙にリッチなものとか。（フロントエンド・エンジニア 國仲 義則）
増えていくCSSを、どう設計するか
ライブラリやフレームワークで機能を補う一方で、作ったものをどう整理し、複数人で使い続けるかという課題もありました。座談会では、当時のCSS設計を振り返りました。
新しいHTMLやCSSで表現できることが増えても、制作現場ではIEへの対応も必要でした。スマートフォンやさまざまな画面幅に対応する必要もあります。そうした環境で、画面幅に応じたスタイルをどう書き、管理するか。
中村：この頃、やっぱりCSSの設計というか、その辺が話題になっていた気がしますね。
矢倉：Sassが出てきて、とか。
中村：あとBEMとかもそうですよね。スマホとレスポンシブは今だと当たり前になっていますけど、当時は、そのときのCSSでどうやるかをいろいろ考えていた気がします。
Sassで記述を整理したり、BEMのような命名・設計の方法を取り入れたりと、スタイルの競合を防ぎ、変更しやすくするための工夫が重ねられていました。CodeGridでも、「SassとCSS設計」や「BEMによるフロントエンドの設計」などで扱っています。
今ではCSS設計という言葉を聞くことも少なくなりましたが、そこで培われた感覚は残っているという声もあります。
スタッフ事前アンケートから：CSS設計で身についた部品の粒度
昔は今よりもCSSが圧倒的に貧弱だったので、スタイルが競合しないように、CSS設計をみんないろいろがんばっていました。今はコンポーネント指向やTailwind CSS、スコープ化された仕組みによって、そこに気を遣わなくてもよくなった部分があります。ただ、この時期から突っ込んで取り組んできた人たちは、画面設計上のUIの粒度などの勘どころが、そこから身についているのではないかと思います。（テクニカルディレクター 髙津戸 壮）
今はCSS設計そのものを使うことは減りましたが、経験しているとCSS的なコンポーネントの切り方が身についた気がします。それは今も生きているんじゃないかなと思います。（フロントエンド・エンジニア 國仲 義則）
スタイルガイドから、コンポーネントの共有へ
増えていくスタイルを共有するための仕組みとして、スタイルガイドも盛んに作られていました。
CodeGridでもKSS、StyleDocco、hologram、aigisなど、スタイルガイドを作るための道具を紹介してきました。
ただ、ガイドを作ることと、更新しながら使い続けることは別の課題でした。座談会では、運用の難しさから、部品を管理・共有する仕組みの変化へと話が進みます。
渡辺：スタイルガイドでプロジェクトのスタイルを一覧できるようにして、重複や似た部品ができないようにしていたんです。でも、しばらくしてサイトを直すことになったときに、誰かがスタイルガイドを無視して作り始めたら、スタイルガイドの中身が古くなってしまう。そうならないためには、人が忘れず更新するしかないんです。スタイルガイドの更新は「人が、がんばるものだった」んですよね。
このあと、JavaScript側もコンポーネント指向になって、CSSもコンポーネントの中に取り込まれて、JavaScriptと合わせたまとまりで扱うようになっていきます。そうすると、スタイルガイドで部品を一覧していた役割の一部は、Storybookみたいなコンポーネントガイドに移ったのかなと思います。部品の単位で考えて作るという発想は、その後も残っていますよね。
中村：その後コンポーネントガイドも収束していって、このあとの時代のデザインシステムになっていったんじゃないかなと思っています。
渡辺：そうですね。色や余白みたいなプリミティブなものは、デザイントークンという形でも引き継がれていますよね。そこから、今のAIでのDESIGN.mdにたどり着いたんですかね。
中村：うん。デザインシステムから、今度はAIが読むためのテキストみたいになっているのが現在ですね。
部品として作り、共有するという考え方は、その後の開発にも引き継がれていきます。続く2016〜2020年には、フレームワークや開発環境を前提とした制作が、さらに広がっていきました。
2016〜2020年（201〜400号）
2016〜2020年ごろは、開発の道具や仕組みが整うとともに、作るものに合った構成や、使う人にとっての品質を見直す動きが広がった時期でした。フレームワークを前提にコンポーネント単位で作ることが当たり前になり、webpackやTypeScript、テストなど、大きなコードを安定して育てるための道具もそろっていきます。
一方で、アプリ向けの技術をWebサイトにも持ち込むと重くなるという課題からJamstackのような構成が注目されました。また、アクセシビリティにも、より多くの人が取り組むようになり、それは現在にも続きます。
フレームワークの定着と、コンポーネント指向
2010年代前半に登場したReactやVue.js、AngularJSなどを、CodeGridでも「攻略！AngularJS 1.5」、「これから始めるVue.js 2.0」などで詳しく扱うようになります。
ただ、新しいフレームワークが登場しても、すぐに現場で採用できるとは限りません。この時期は、複数の選択肢を見比べながら、どの作り方を取り入れるか探っていた時期でもありました。
その中で広がっていったのが、画面をコンポーネントに分けて作る考え方です。画面の部品を、表示するデータや振る舞いとひとまとめにして扱います。では、フレームワークを選び、コンポーネントに分けて作るというやり方は、どのように定着していったのでしょうか。
渡辺：2015年ぐらいに、ライブラリを選ぶのにReactやFluxでいいか悩んだ記憶があります。コンポーネント指向みたいなものも、その頃からですよね。
矢倉：Reactといっても、最初にJSXがあって、その後Hooksがあってと、考え方もちょいちょい変わっていますからね。初期のVue.jsなどは、1つのボタンに1つのコンポーネントという感じではなかった気がします。
渡辺：その頃のコンポーネントの単位は、もうちょっと大きいですよね。再利用する単位ぐらいの感じだった気がします。
矢倉：そうですね。フレームワークごとの違いはありつつも、フレームワークを前提に何かを作ることが、当たり前になっていったのが、この辺りなのかなと思います。
フレームワークが担う範囲にも違いがありました。たとえばAngularJSと、その後に作り直されたAngularは区別して考える必要があります。Angularはルーターなど、アプリケーションに必要な機能をまとめて備え、バージョンアップを支援する仕組みも用意しています。座談会では、「Angularはこうした全体を扱う作りが、現在でも大規模な開発での使いやすさにつながっている」という話も出ました。
スタッフ事前アンケートから：大規模アプリのためのAngular
AngularJS/Angularは、大規模アプリの構築に使い、書籍も書きました。Angularは継続して開発されていますが、自分は大規模アプリを作る機会が減り、軽量かつシンプルな構成を好むようになったので、今は使っていません。（フロントエンド・エンジニア 宇野 陽太）
品質を支える仕組みと、ビルドツールの変遷
さらに、フレームワークの周りにも、開発を支えるツールがそろってきます。コードの規模が大きくなっても変更を続けられるように、品質を確かめる仕組みを制作工程に組み込むようになりました。
CodeGridにも、「TypeScriptことはじめ」、「Jestで始める！ ユニットテスト」、「ESLintを使ったコードの品質管理」などが並びます。
矢倉：フレームワークがwebpackなどのツールチェーンの上で作られていました。大規模な開発ではテストも必要ですし、開発の安定性や、手戻りを避けるために、TypeScriptのような型を入れる言語も使う、という感じですね。
こうした開発環境の共通の基盤として、多くの現場で使われたのがwebpackでした。webpackはJavaScriptのモジュールをまとめるだけでなく、CSSや画像なども扱い、各種の変換処理を組み合わせる役割を担いました。
CodeGridでも、「これから始めるwebpack」に続き、「キャッチアップwebpack」など、継続的にwebpackを扱っています。
その後、webpackの位置づけも変わっていきます。バンドラーのParcelなど、ほかの選択肢も現れ、Next.jsではTurbopackが使われるようになりました。では、参加者の実感はどうだったのでしょうか。
中村：webpackは、当時のいろいろなフレームワークでだいたい推奨されていたから、それを使うという立ち位置でしたよね。今はそこがViteに置き換わっているのかな。
渡辺：Turbopackもがんばっていますけど、Viteが強い感じはしますね。速さや、開発サーバー周りの使いやすさもあるんでしょうね。
中村：webpackの時代は、1行直してもビルドを待たないと確認できない、ということがありました。大規模なプロジェクトだと、その待ち時間が長くなる。Viteでは開発時に全体のビルドを待たずに確認できるので、開発体験がよくなったと思います。
矢倉：ViteはES Modulesを前提に作られていて、HMRがうまく効く設計だったんですよね。
渡辺：ブラウザやNode.jsなどの環境が進んだからこそ、できるようになったこともありますよね。できるようになることを見据えて、そこを解決しようと一から設計されている。それはすごく大事だったという話ですよね。
ViteはブラウザのES Modulesを活用し、開発時にアプリ全体をまとめ直すことを前提としない構成を採りました。コードの変換などは行いつつ、変更したモジュールを差し替えるHMR（Hot Module Replacement）と合わせて、確認と修正を繰り返しやすくしています。
ブラウザや実行環境の進化は、サイトで使える機能だけでなく、サイトを作る道具の設計にも影響してきました。
一方、webpackがViteに置き換わっていったといっても、webpackが担っていた仕事は、後のツールにも引き継がれています。
スタッフ事前アンケートから：webpackの機能は、後続ツールの前提へ
webpackは、自分に限らず当時はデファクトスタンダード的なポジションで、ほかに選択肢がないと感じていました。今もwebpack自体は消えていませんが、モジュール解決、コード分割、ローダーによる資産変換、HMRといった問題は、もはやwebpack固有のものではなく、Rspack、Turbopack、Viteそれぞれの前提として吸収されたと思います。（フロントエンド・エンジニア 藤田 智朗）
JamstackというWebアーキテクチャ
アプリケーション向けの技術をWebサイトにも取り入れるなかで、開発しやすさと、配信するサイトの軽さをどう両立するかが課題になりました。そこでピクセルグリッドが注目したのが、ビルド時のHTML生成などを活用するJamstackです。
CodeGridの「一から学ぶJAMstack」は2019年3月に始まりましたが、社内では、その1年以上前から取り組んでいました。
中村：JavaScriptでアプリケーションを作る流れで、Webサイトにもその技術を取り込むと、どんどん重くなっていたんですよね。ビルドという工程をWebサイトでも使って、最終的な成果物のJavaScriptを減らせれば、軽くできるんじゃないかと。
何でもSPAにすると、ブラウザがもっている機能を使わずに、全部再実装するようなことにもなる。みんなでブラウザの機能を作っていてもしょうがない、と思ったんです。ただ、SPAで慣れたよいところは持ってきたかった。その点で、Jamstackがちょうどよかったんですね。
ここで少し時期を進めて、その後の変化も見ておきましょう。ピクセルグリッドでは、あらかじめHTMLを生成しておくプリレンダリングを使い続けながら、必要なところではリクエストに応じてサーバー側でHTMLを生成するSSRも取り入れるようになりました。データの取得も、すべてをブラウザから呼ぶAPIに分けるのではなく、サーバー側で行うなど、用途に合わせて処理の場所を選ぶようになったといいます。
こうした変化は、2023年の記事「Jamstackとはなんだったのか？ | Jamstackを考える」でも振り返っています。中村は、当時と今のJamstackとの距離をこう話します。
中村：この頃は、Jamstackの会社を名乗るほど使っていました。今もその技術自体は使っていますが、Jamstackという言葉を使わなくなりました。Jamstackの考え方を使いつつ、発展させていっている、という感覚です。
アクセシビリティが、より多くの人の仕事になった
この時期のCodeGridには、「WAI-ARIAを活用したフロントエンド実装」や「伊原さんと話すアクセシビリティ」など、アクセシビリティを扱う記事も登場します。
では、アクセシビリティという考え方は、この時期に広まり始めたのでしょうか。
中村：自分が「アクセシビリティ」という言葉に触れた時期を、流行り始めた時期だと感じてしまうところがありますよね。WCAGや国内のJIS規格はもっと前から制定されていたわけですから。
矢倉：そうですよね。その意味では、この時期にアクセシビリティという言葉がよく聞かれるようになったことはあります。
この頃、受託の制作会社でアクセシビリティに取り組んでも、難しさがあったという話を聞きましたね。アクセシビリティでお金を取れるわけではない、ということも聞きました。そういうこともあって、自社サービスを展開する会社の中で取り組む動きが出てきたと思います。日本だとサイバーエージェントやfreeeなどですね。
今、アクセシビリティのミートアップに行くと、昔から取り組んでいた人だけでなく、新しい人も多くて、アクセシビリティの広まりを感じます。Webアプリケーションでも、アクセシビリティに配慮したフレームワークやデザインシステムだとうたうものが、かなり当たり前になっていますね。
国内の規格では、WCAG 2.0と一致させたJIS X 8341-3:2016が長く参照されてきました。現在は、WAICの改正原案作成委員会で、WCAG 2.2に対応する国際規格ISO/IEC 40500:2025に合わせた改正の検討が進んでいます。規格の位置づけは、「JIS X 8341-3とは何なのか？」にまとまっています。
2012〜2016年には、Webで表現できることや作れるものが増えました。2016〜2020年には、複雑なものを安定して作る環境や、利用する人にとっての使いやすさが、より広く制作の課題になっていきました。
ツールが変わっても、解決したかった問題や、そこで得た作り方が引き継がれることがあります。後編では2020年以降を振り返り、標準機能の充実や新しい開発基盤、AIの登場によって、その役割がどう変わっていくのかをたどります。
（後編へ続く）
