Webフロントエンド開発(2021)の見取り図をつくりたい
本業はiOS開発なのですが、6月頃から個人開発でWebフロントを触っています。
Webフロントに入門するときに、開発の前提知識・専門用語が多すぎて、脳が処理しきれない状態になりました。
これでも数年前のより混沌としてた時期よりは安定してきているように思うんですが、それでもやはりカオス感は否めませんでした。
Webフロントエンド開発の見取り図があればいいのにと思ったので、自分でちょっとつくってみようと思いました。
個別の技術要素の情報は豊富にある（ありすぎると言ってもいいかもしれません）んですが、全体像がよくわからないので、
たとえば「TypeScriptで開発した方がいいのか？」とか、「Babelとかwebpackってインストールしなきゃいけないの？」とか、
そういう素朴な疑問が学習進めて行っても、なかなか解消できなかったので、いい感じのざっくり感でまとめられたらと思います。
この記事で全体像をつかんで、もっと詳しい情報に進んでいくような使い方を想定しております。
Webフロントエンドの基礎
Webフロントエンドの基本的な構成要素は、90年代と実のところ変わっていません。
HTML、CSS、JavaScriptのお馴染みの三兄弟ですね。
三者の役割分担
本当の最初の最初にWeb技術を触ったとき、この三者の役割分担がよくわからなかったのですが、
HTML: マークアップ言語
CSS: スタイルシート言語
JavaScript: プログラミング言語
というのがわかりやすい説明かと思います。
HTMLはマークアップ言語で、単なる言語の集まりではなく、その見た目についての情報も表しています。
HTMLが示すビジュアル情報というのは最低限なので、それを力強くサポートするのがCSSです。
JavaScriptの役割が大きくなった
90年代のWebサイトは、ブラウザで重たい処理を動かすことが性能的にできなかった側面もあって、スクリプトで行うことは最小限でした。
基本的にはサーバーサイドで重たい処理を行う構成が基本でした
しかし2021年現在、スマートフォンすらメモリ6GB積んでるような時代で、フロントエンドの処理で色々なものが完結するようになっています。
というわけで、モダンWebフロントエンドを学ぶ＝JavaScriptを学ぶ、と言っても過言ではありません。
JSのエコシステム概観
で、大抵の解説だとこの後からフロントエンド用語ビームの連射がはじまるわけですが、それを避けたいので、JavaScript開発のエコシステムについて概観したいと思います。
JavaScriptは1995年に誕生しました。
JSがいい言語か？ というのは議論がありますが、Web業界の中で一番使われてる言語であることは間違いないでしょう。
言語仕様には現代から見れば改善した方がいい点は多々あります。
しかしJSのいいところ（でもあり、悪いところでもあるの）が、とにかく柔軟であることです。
その柔軟さによって、JSの仕様に不満があるプログラマーは自分たちで何らかの改善方法を見つけることができました。
Webというオープンな環境もあいまって、JSを包むエコシステムはこの26年で急速に成長したのです。
以下では個別の論点について書いていきます。
JSのモダン化
JSは元々言語仕様がガバくできていたので、どう考えてもヤバい仕様がいくつかありました。
（var, thisなど）
ECMAScriptというJavaScriptの標準化団体があったのですが、2000年代は改善案をまとめることができませんでした。
しかし2015年にようやくECMAScript 2015（ES2015）を発表します。
これがモダンフロントエンドの大転機となります。
2015年以前にJSを学習して、アップデートしてない方は一度その知識を捨てた方がいいと思います。
僕はオライリーの「JavaScript 第6版」で昔JSの学習をしてしまったので、大アップデートが必要でした。
ES2015以降のJSにキャッチアップしたい方は↓をオススメします。
AltJSという方向性
JavaScriptの言語仕様のヤバさはどうしようもないので、別の言語をつくろう、という流れがありました。
ただブラウザで最終的に動くのはJavaScriptなので、AltJSと言っても、コーディング時点ではAltJSで、コンパイルするとJavaScriptを生成することになります。
AltJSの有名例には、TypeScriptやCoffeeScriptがあります。
TypeScriptが覇権をとった感があります。
サーバーサイドJS
JavaScriptはブラウザで動かす言語でしたが、サーバーサイドも同じ言語で書けたらいいよねーということで、Node.jsというOSSが開発されました。
2009年誕生なので、モダンの仲間に入れるのはちょっと古いものなのですが、今日でも重要な存在です。
現在のWebフロントエンド開発では何らかのフレームワーク入れて開発進めると思いますが、その際に裏でNode.jsが動いている、というのはよくあると思います。
（自分でコマンド打ったり、インストールしたりはそんなにないかもですが）
パッケージマネージャー
この辺からが個人的に困惑したところです。
開発したソフトウェアを、他者に共有したい場面があると思います。
あるいは他者がつくったパッケージを入れたいときがあると思います。
そしてこの手のパッケージを入れるとバージョン管理問題も出ます。
そういうのをシュッと解消してくれるのが、パッケージマネージャーです。
Web開発に限らず、この手のツールは存在します。
iOS開発だとCocoaPods, SPMなどがあります。
Web開発だと、Node.jsのパッケージマネージャーのnpm、Yarnを使うことになります。
（2021/10/16追記）
なぜNode.js？ という話ですが、かつてのJavaScriptは↓このようにファイル単位でHTMLに直指定するものであり、
モジュールの分割だのパッケージ化だのという思想がなかったみたいです。
<script src="https://ajax.googleapis.com/ajax/libs/jquery/x.y.z/jquery.min.js"></script>
それがNode.jsではさすがに不便なので、パッケージマネージャーが誕生。
そしてそれがクライアントサイドのJavaScriptでも使われるようになった、という流れみたいです。
詳しくはこちら↓
npmがNode.js公式で、Yarnは非公式（Facebookの人の作らしい）です。
かつてはYarnの方がパフォーマンスが大幅に良かったそうなのですが、今はnpmがYarnの機能をパクってそんなに差がなくなったようです。
僕はこういう開発ツールはなるべく公式が出してるものがあればそっちを使いたい派ですが、↑の経緯から敢えてYarnを使いたい、という人がいてもおかしくないかなとは思います。
チーム開発なら周りが使ってる方に合わせればいいかと思います。
モジュールバンドラ
パッケージマネージャーの解説で、「Webフロントエンド開発なのにNode.jsのパッケージマネージャー入れんの？」と思わなかったでしょうか？
僕も書きながら思いました。
フロントエンドで動かすことを想定して、モジュールを適切な依存関係になるように1つに結合させることが必要みたいで、これをやってくれるのがモジュールバンドラです。
うまく説明できないので、引用します。
モジュールバンドラーとは、JavaScriptのモジュール依存関係を解決し、複数のモジュールを1つのJavaScriptファイルに結合するツールのことです。 モジュールバンドラーは起点となるモジュールが依存するモジュールを次々にたどり、適切な順序になるように結合（バンドル）します。
NPMによって多くのJavaScriptライブラリがNode.js向けに配布されていますが、これらはほぼすべてCommonJSモジュールです。 CommonJSモジュールはNode.jsでの実行を想定したものであったため、そのままではウェブブラウザ上で動作しません。 そのため、CommonJSモジュールをブラウザでも実行できるようにモジュールの依存関係を解決したりファイルを結合する目的でモジュールバンドラーと呼ばれるツールが登場しました。
具体的な名前を出すと、webpackのことです。
僕はNext.jsを使ってサイト作成したので、自分でwebpackを入れることはなかったんですが、たぶんフレームワークの中でwebpackを使って、よしなにやってくれているんだと想像しています。
Next.js使ってるとあまり意識しないで、npmだけで入れると、なんとなく動いてくれるので、モジュールバンドラーの仕事の理解があやふやです。
トランスパイラ
ES2015以降、JSの文法がほぼ別言語と言ってもいいくらいに激変しました。
ECMAScriptは一応後方互換性に配慮して仕様を決めているそうですが、最新の文法を使うと、そのままだと動かないブラウザというのが存在しました。
そういうブラウザのために、古い文法で書き直して、動くようにしてあげる変換作業をやってくれるのがトランスパイラくんです。
具体的な名前を出すと、Babelです。
またあまり意識していませんでしたが、TypeScriptにもトランスパイラとしての側面があるそうです。
なんかここもフレームワークが上手いことやってくれている部分で、あまり意識しませんでした。
Next.js入れるならBabelを自分で入れて……という作業は不要です。
ここからフレームワークとエディタとLinterの話
さて。ここまでで既に長くなってしまったので、中まとめです。
- JavaScriptはES2015でモダンな文法を採用して、ほぼ別言語となりました
- 故に、トランスパイラなんていうものが必要になりました
- また、パッケージマネージャーはNode.js環境を想定していたのでモジュールバンドラなんてものが必要になりました
ここまではES2015という革命と、そのしがらみ部分を書いてきました。
モジュールをどう扱うかとか、どう変換するかとかそんな話でした。
次からはもっとコーディングに近い話題に触れていきます。
まずはフレームワークについて書いていきます。
React
Web技術何も知らない人でも、もはや名前ぐらいは知ってるんじゃないかと思います。
Facebook製のOSSのライブラリです。
ライブラリと言われたりフレームワークと言われたり、そもそもライブラリとフレームワークって何が違うのとかあるんですが、一応React公式が自分のことをライブラリと言っているのでそれに倣います。
2013年に登場し、それ以降も↑のリポジトリで開発が続けられています。
Reactの他にもJavaScriptのフレームワークはたくさんあったんですが、完全に覇権をとった感があります。
（AngularJS, Vue.js, jQuery）
宣言的UI、コンポーネント指向、仮想DOM、コミュニティがFacebookを中心に固かったなど、良さは色々あげられるかと思いますが、
僕がチュートリアルやってみて感じたのは、「少量の記述で大きな効果が得られる開発者体験の良さ」というところが覇権をとった要因かと思いました。
Reactの代表的な記法はこんな感じです。
class xxx extends React.Component {
render() {
return (
// do something
);
}
}
あらかじめrender()という関数をつくることが決められていて、開発者は何をコンポーネントとして返すかを記述することになります。
そしてコンポーネントは画面更新のたびに再描画（不要な場合はスキップ）されます。
なのでコンポーネントは「状態」を原則持ちません。
最初見たときはホントにとっつきづらいなと思いましたが、一度習得すると、フロントエンド開発を宣言的UI以外でやることが考えられなくなります。
Next.js
2016年に登場したReactのフレームワークです。
Vercelという企業によって開発されたOSSです。
フレームワークのフレームワークみたいで最初ややこしかったですが、Reactはかなり汎用的なライブラリなので、
Next.jsは「普通にWebサイトつくるならこういう機能欲しいよね」というのを色々やってくれているフレームワークです。
よくQiitaやZennに「Next.jsで個人ブログつくってみた👶」みたいな記事上がってますが、ブログくらいなら爆速でつくれます。
また、Vercelという会社はホスティングサービスをやっていまして、Next.jsとVercelの連携がめちゃくちゃいいです。
特に細かいことを気にしないのであれば、爆速で開発してものを爆速でデプロイできます。
ちなみにNuxt.jsという名前が一文字違うのフレームワークもありますが、別モノです。
Vue.jsのフレームワークとして、Next.jsみたいなことやってるのがNuxt.jsです。
どっちかがどっちかをパクったんだと思ってましたが、どちらも2016/10の公開で、名前がカブった真相は定かではありません。
たまたまだったら面白いですね。
（2021/10/18追記）
コメント欄で教えてもらいましたが、Nuxt.jsがNext.jsにインスパイアされたそうです
エディタ
別にメモ帳でもvimでも開発できますが、エディタ入れた方が開発効率は格段にいいと思われます。
VSCodeが完全に覇権握った感があります。
数年前はAtomが主流だったような気がするんですが、気のせいですかね。
校正ツール
エディタは文法エラーやワーニングやコンパイルエラーを表示してくれますが、「間違ってないけども汚い書き方」「前書いた書き方と統一性のない書き方」みたいなのは指摘してくれません。
iOS開発だとSwiftLintというものがあるんですが、それに相当するのがESLintとPrittierです。
ESLintだけじゃダメなのか？ とふと思いましたが、
Prittierの方がコード整形の能力が高いが、ESLintの構文チェック機能がないので、併用することが多い、ということみたいです。
僕は個人開発するにあたって両方入れたんですが、メリデメあって、入れた方がいいとは思いますが、デメリットもあります。
何よりチェックルールを適切に保つのがそこそこしんどいと感じました。
まとめ
他に書きたかったこともあるんですが、見取り図としてはこのぐらいにおさめないと厳しいと思うので、ここで切ります。
モダンなWebフロントエンド開発に入門するときの、どちらかというとコードを書く以前の環境にまつわる、主要なトピックは網羅できたかなと思います。
個人的にはパッケージマネージャー、モジュールバンドラー、トランスパイラの三兄弟が入門のときに理解できなくて、
実際理解できなくてもなんとなく上手くいったモノだったんですが、
改めて振り返ると、ReactなりNext.jsなりのフレームワークの中で上手いことやってくれていたんだなと思いました。
Discussion
Next.js と Nuxt.js ですが、Next.js の影響で Nuxt.js が開発されたようですね。
https://www.npmjs.com/package/nuxt/v/0.0.1 に
と書いてあります。
ありがとうございます！
追記しときます。
影響受けるのはいいですが、名前だけは区別つけやすいようにして欲しかったですね……
良記事ありがとうございます。
自分も3年前に似たような経験をして似たような記事を書いたので懐かしくなりながら読みました。
見取り図という意味ではこれのFrontendとかよく纏まってるかと思います
サイト上で切り替える方法を見つけられなかったのですがgithub上には日本語版もあります
私はフロントエンド周り全く知らないのでこの図だけ見てもなんとなくしかわからなかったのですがこの記事を読んでから見直すと前よりはわかりやすくなったので良かったです