2021年12月12日追記

本記事は YUMEMI Advent Calendar Advent Calendar 2021（なんで名前重複しているんだ…w） に昇格させます！決して「何を書こう…ネタがない…あ，ずっと途中で止まっていたやつがあるので，これを機に書ききっちゃお！そしてこれをアドカレの記事にしちゃおう☆」とか言う悪い気持ちではないです((((；ﾟДﾟ))))ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ

それでは本編をどうぞ💁

こんにちは．株式会社ゆめみ でチャレンジ取締役をしております Keeth こと桑原です．今回は WEB DEVELOPER Roadmap 2021 の中の フロントエンドに関するロードマップ を見て思ったこと，日本の Web 業界での必要性などを振り返りました．

そもそもの WEB DEVELOPER Roadmap 2021 とは，以下の記述の通り，

Step by step guides and paths to learn different tools or technologies

異なるツールや技術をステップバイステップで学ぶためのガイドやツールです．言葉では書いていませんが，Web Developer のためのドキュメントになりますね．

余談ですが，公式リポジトリ名は developer-roadmap，公式サイトのドメインは roadmap.sh となっておりますが，リポジトリの README トップ画像が

となっておりますので，この記事のタイトルも WEB DEVELOPER　Roadmap としております．

それでは Frontend のロードマップ を見ていきたいと思います．

かなり多いですが，これを真ん中の線に沿って一つ一つピックアップしつつ，書き連ねます．

※４つの優先度については，このスクラップでは以下のように訳します(=ﾟωﾟ)ﾉ

• Personal Recommendation / Opinion
  →　推奨

• Alternative Option - Pick this or purple
  →　やれるならやったほうが良い

• Order in roadmap not strict(Learn anytime)
  →　厳密には今じゃなくても良い

• I wouldn’t recommend
  →　非推奨

Internet

こちらの６要素は全て学習が推奨されていますが，概ね同意です．

推奨

• How does the Internet worki?
• What is HTTP?
• Browsers and how they work?
• DNS and how it works?
• What is Domain Name?
• What is hosting?

どれも Web を支える根幹の記述ばかりですので，ここは理解しておくべきでしょう．少なくとも理解はしておき忘れても，調べたら思い出せるくらいにはしておくのが望ましいです．

仕組みを理解するように記載されていますが，プログラマブルに中の設計まで理解する必用はなく，そもそもそれはなんぞや？と言う点と，大きな流れとして何が動いていて，どの要素がどう働きあっているのかが分かれば良いかなと．この辺を学ぶものとして以下の書籍を推薦します．

https://amzn.to/2Qqb3X3

また一点だけ，フロントエンドエンジニアとしてブラウザの仕組みは一歩踏み込んで理解しておくと，パフォーマンスの観点が身に着きますし，改善する場合の着眼点も変わってきます．ということで，パフォーマンスの書籍をオススメします．

https://amzn.to/3d1Vlci

HTML

推奨

• Learn the basics
• Forms and Validations
• Conventions and Best Practices

こちらも概ね同意で．基礎や慣習，ベストプラクティスは是非学ぶべきですね．フォームやバリデーションは推奨というか必須と言っても良いいですが，フロントエンドのアプリケーション開発やってればほぼ確実に触れるものなので，必然的に学ぶことになると思います．

厳密には今じゃなくても良い

• Writing Semantic HTML
• Accessibility
• SEO Basics

セマンティックHTMLが書けることは，個人的には推奨に含めても良いかなーと思いますが，まぁ今じゃなくても良いです．アクセシビリティについては海外（特にアメリカ）のクライアントさんのアプリケーションであれば推奨〜必須となることもあると思いますが，日本ではやっと意識されてきたかな，というのが肌感です．ただ，聞かれたら答えられるようにはしておきたいところ．

また SEO の基礎については個人的には推奨に含めたいかなと思います．ここを意識できるエンジニアはビジネスサイドの人にとっても評価に値すると思いますので👍

CSS

推奨

• Learn the basics
• Making Layouts
• Responsive design and Media Queries

こちらも概ね同意です．多少乱暴な発言をすると，Making Layouts については，困ったら Flex Box 使えばなんとかなると思っています()←

また CSS Grid については IE11 がほとんどサポートしていない ため，事実上日本のクライアントさんの Web アプリケーションを作る場合は使えないことも多いです…（IE はよ滅べ）

CSS を学ぶなら昔は以下の書籍「Web制作者のためのCSS設計の教科書」をオススメしていましたが，

https://amzn.to/31CtmuN

今ならこちらの書籍「CSS設計完全ガイド」をオススメしますー．

https://amzn.to/31pJxeQ

JavaScript

推奨

• Syntax and Basic Constructs
• Learn DOM Manipulation
• Learn Fetch API / Ajax (XHR)
• ES6+ and modular JavaScript
• Understand the concepts
  • Hosting
  • Event Bubbling
  • Scope
  • Prototype
  • Shadow DOM
  • strict

ほぼほぼ異論なし．強いて言えば，Prototype と ShadowDOM は知っていても良いけど，実際の開発ではほとんど意識しないと思う．JavaScript のライブラリやフレームワークを作るのであれば別ですがw

JavaScript に関するおすすめの書籍は以下２冊です．前者の「JavaScript Primer」の方が最近出版されており，こちらの方が現代の仕様に近いですのでおすすめです．後者は通称「ニンジャ本」とも言われており，かの jQuery の開発者 John Resig 氏が執筆された書籍になりまして，いろんな tips なども含まれておりますので実践的な学びもあるという点で挙げております．

https://amzn.to/3fojaOh
https://amzn.to/3m3G7I3

Version Control Systems

推奨

• Basic Usage of Git

Git については推奨どころか，必須だと言っても過言ではないと思います．Subversion などの別のものもありますが，Git 一択で良いかなと．

Repo hosting services

推奨

• GitHub

やれるならやったほうが良い/非推奨

• GitLab
• BitBucket

GitHub は Git と同様に必須と言っても良いかなと思います．残り２つに着いては GitHub が使えれば後は UI や多少の機能の違いがあるのみで，ほとんど同じようなサービスですので，必用になったときに学んでいただければ全く問題ないです．

Web Security Knowledge

厳密には今じゃなくても良い

• HTTPS
• CORS
• Content Security Policy
• OWASP Secutiry Risks

セキュリティにつきましては正直私も専門ではないので肌感での意見となりますが，HTTPS，CORS はフロントエンドエンジニアでも必須かなと思っています．自分で手を動かして設定できなくても良く（できたら素晴らしいです），それがなんぞや，どういう役割があるのか，どういうメリット/デメリットがあるのか，を把握するだけでも良いので，是非学んでいただければと思います．

実際に開発業務をしていくと CORS 問題にはちょいちょいぶつかることになると思いますので，今やらなくても良いですが先に知っておいて損はないです．

残り２つについては余裕があればやってもよいかな，くらいのものと感じています．これらを知らなくてもフロントエンドエンジニアとして仕事をしていくことは可能です．実際の現場ではセキュリティ専門のエンジニアの方や，セキュリティチェックソフトウェア・サービスを使ってチェックすることの方が多いかと思いますので，知っておいて損はないですが，他の技術やツールと比較すると後回しでも良いかなと思います．（あくまで Knowledge ですし🍣）

Package Managers

推奨

• npm
• yarn

現代のフロントエンドエンジニアにとって npm を学ぶことは必須です．セットで，多少の linux コマンドも使えるようになることが望ましいですね．

yarn は npm が使えればなくても良いですが，yarn だとコマンドが一つ少なくできたり，モジュールのインストール速度が速かったりと，メリットもありますのでおすすめですが，最近の npm も（パフォーマンス面も含めて）改善されてきていますので，yarn は必須ではないですが推奨で同意です．

※ただし，yarn のバージョンアップ（現在では 1 → 2）については，破壊的変更も含めて大きく変わったようですので，ご注意ください．
参考：https://dev.to/arcanis/introducing-yarn-2-4eh1

CSS Architecture

厳密には今じゃなくても良い

• BEM

非推奨

• OOCSS
• SMACS

CSS アーキテクチャについては，正直どれも今じゃなくても良いと思いますが，非推奨とも言えないなと思ってもいます．というのも，CSS の設計はいろんな考え方や手法があり，一概にこれがベストプラクティスだ！と言えるものはなかなかないんじゃないかなと言うのが，その理由となります．

プロジェクトごとにどういう命名規則にするかは異なりますし，自分達流に設計して運用するのが良いかなと．その上で，いろんな考え方を学んでおくことはためになると思いますので，推奨とは言いませんが，非推奨にするほど効果がないとも思わないので，余裕があれば学ぶくらいで良いかなーと思います！学ぶなら CSS の項目で書いた推薦書籍にも CSS アーキテクチャについても言及されているので見てみてくださいー(=ﾟωﾟ)ﾉ

https://zenn.dev/kkeeth/scraps/dd30ae9d48f092#comment-ca2b651d96c6b4

また，画像にも記載がありますが，styled-components や emotion などのライブラリに代表される CSS in JS という手法が現代では主流となっており，こちらを学ぶほうが優先度は高いと思いますー(=ﾟωﾟ)ﾉ

CSS Preprocessor

厳密には今じゃなくても良い

• Sass
• PostCSS

非推奨

• Less

こちらも，まぁ異論はない．Stylus とかも非推奨で良いかなーと思います．CSS Architecture の項と重複してしまいますが，現代は CSS in JS が主流かと思いますので，こちらの方を優先して良いかなーと．ただ知っているとそれはそれでメリットもあるので，余力あれば学ぶことをオススメします(=ﾟωﾟ)ﾉ

Build Tools(Task Runners)

推奨

• npm scripts

非推奨

• Gulp

ほぼほぼ同意で，npm scripts については必須どころか must だと思います．また gulp も知っておいて損はないかなと．実際はほぼ使うことはないですが，レガシーな環境で実装することを求められている現場で，せめて TypeScript や Sass だけは入れたいとか，画像圧縮だけはしたいとか，少しでも開発環境を良くしたいのであれば gulp + gulp-xxx（導入したいツール用サードパーティ製ライブラリ） という選択肢は悪くないと思います．

後述しますが，webpack では設定ファイル webpack.config.js が破壊的変更が多く，かつ複雑でわかりにくい！という人にもありかなと．

Build Tools(Module Bundlers)

推奨

• Webpack

やれるならやったほうが良い

• Rollup
• Parcel

Webpack は推奨〜必須と言っても良いかもです．後述する理由で webpack はほぼデファクトスタンダードと言ってもよく，直接設定ファイル（webpack.config.js）を書かないにしても，知っておいたほうが良いと思います．

Rollup はアプリケーション開発というよりも，ライブラリや便利ツールを作るときのバンドラの選択肢としては有力です．バンドル後の出力コード量が webpack よりも軽量なのも魅力ですね．

余談ですが，webpack と rollup の比較記事もいくつか書かれており，こちらの記事がわかりやすいかと思います．少々古いため，現在ではどちらのツールも改良されていると思いますが，お互いの得意なこと苦手なことが書かれているのでおすすめです．

https://postd.cc/webpack-and-rollup-the-same-but-different/

さらに Parcel ですが，こちらは上記２つのツールと大きく違う点は__設定ファイルが不要__なことです．が，まだまだ本番導入には厳しいかなと感じており，無難に webpack を使うことをオススメします．小さなアプリケーションとか，プラグインをそれほど多く使わずなるべく parcel 本体の機能で頑張るのであれば悪くないとは思いますが，凝った環境を作ると融通が利かなかったりします💦

Webpack と parcel の比較記事も色々書かれていますが，こちらの記事が比較的新しくかつ詳しく書かれているのでわかりやすいです．

https://qiita.com/soarflat/items/3e43368b2d767c730781#webpackと比べてみてparcelはどうなのかwebpackの代わりになるのか

Build Tools(Linters and Formatters)

厳密には今じゃなくても良い

• Prettier
• ESLint

非推奨

• StandardJS

先に非推奨の StandardJS ですが，こちらは名前は知っていたものの私は使ったことがないため何とも言いにくいですが，名前をほとんど聞かなく，使っている人も周りにはいなさそうでしたので，学ばなくても良いかなと．

公式サイトを見ると

JavaScript style guide, linter, and formatter

とあり，何でも詰まっている便利ツールなのはわかりました．さらに GitHub スターも２万を超えている老舗ライブラリで，高い人気と導入実績がありそうなことも伺えます（実際に導入実績を見ると，nodejs, npm, github など錚々たる名前が並んでいますし）．現場では細かく設定したいときもあるので，その場合は個別にライブラリの設定をするほうがよく，柔軟性という点でもあまり使うケースは少ないかなと．細かな事考えずに，とりあえずなにかのルール上に乗っかって開発したい人にはマッチすると思いました．

ESLint, Prettier については個人的には推奨と言いたいところ．やはり静的コード解析は，人がリソースを割くべきじゃないことですので自動化したい．ただ，ESLint が解析・チェック及び修正まで行ってくれるので Prettier は不要で ESLint だけで良いよね，という人もいますしそれも理解します．

が，私は Prettier もある方が良いかなと思います．ESLint との設定のバッティングでハマる人もいますが，この落とし穴の知見は結構記事に書いてくださっており，ググれば解決すると思います．また，エディタで VSCode を使っている人は，専用のプラグインを入れれば保存するたびにその場でコードの修正が行われますので，開発体験がとても高くなります．

Pick a Framework

こちらはメインとなるフレームワークと，それに付随する State management 用 Store ライブラリの２つに分けたいと思います．そして，フロントエンドの開発のメインテーマはやはりここ，感があるので，今回はちょっと長めです．

▼メインフレームワーク

推奨

• React.js（以下，React）

やれるならやったほうが良い

• Angular
• Vue.js（以下，Vue）

こちらもほぼ同意で，React とそのラッパーである Next.js（以下，Next） を推奨します．「現代のモダンなフロントエンドのフレームワークは何？」と聞かれたら真っ先に Next と答えるくらいには，Next は素晴らしいと私は感じているフレームワークとなります．ついで，Vue とそのラッパーである Nuxt.js（以下，Nuxt）かなと．しかし React Hooks しかり，TypeScript やテストの書きやすさしかりで，自分は今の所 Next 推しです．

これら以外でもう一人推したいのが，日本ではまだあまり流行ってはいなさそうな Svelte 君ですね😆後発ライブラリということもあり，React と Vue の美味しいとこ取りな彼，公式サイトにも記載がありますが魅力的なところは．

• コードの記述量が少ない
• Virtual DOM を使わない
• リアクティブ

の３点です．詳しくは公式サイトに説明がありますので，読んでいただいたり実際にチュートリアルを一通り手を動かしてみるとよいかと思います．百聞は一見にしかずとはまさにこのこと👍

個人的な意見というか好み（あくまで私見です）では Angular をやらなくても良いかなーと思ったりしますが，別に Angular が嫌いというわけではありません．

なんなら，Angular Japan User Group の slack にも入っておりますし，公式のチュートリアル も一通り手を動かしました．更には ng-japan という日本の Angular に関する一番大きなカンファレンスのスタッフもやったことあるくらいには，Angular に触れてきた身でもあります．その上で，

• 書きやすさ
• シンタックス
• エコシステムやサードパーティ製ライブラリとの相性
• 可読性，見通し
• Store ライブラリ
• Angular 人口

などを加味すると，個人的には React(Next.js) に軍配が上がっており，React でできないことが Angular には殆どないのと，後述しますが RxJS という別ハードルが上がるため，敷居が高く感じる のが選ばない理由となります．

ただ，コミュニティ観点で言えば他フレームワークと比較した時，Angular Japan User Group は頭一つ抜けていると思っていて，運営メンバーの方々もかなりエンジニアとしてのスキルも高いため，サポートの面ではとても手厚いと感じています．この観点では Angular は完全になしとも言えず，Google 社謹製ということもあり，そもそもよく出来ているフレームワークということも加味すると，有りだとも思いますので，最後は「好み」かなと（笑）

▼ Store ライブラリ

React の場合

推奨

• Redux

やれるならやったほうが良い

• Mobx

どちらも今後はやらなくてもよいのではないか？とも思ったりしているのが最近の私で，軽量であり React Hooks に寄せて独自フックを実装している Recoil や Jotai（こちらの方が個人的にはオススメ） を推します．

もちろん Redux にはデメリットを理解しても余りあるメリットで選択するのもありです．何だかんだ React の Store ライブラリとして未だに一番の人気を誇りますし，それだけ使い勝手も良いのも事実です．その上で，私は前述の２つをおすすめします．

手前味噌ですが Jotai について一本記事を書いておりますので，参考までに貼っておきます．
https://zenn.dev/kkeeth/articles/studying-jotai-library

Angular の場合

やれるならやったほうが良い

• RxJS
• NgRx

自分が RxJS しか触ったことがないため，NgRx についてはすみませんが全く評価できません🙇 またRxJS についてですが，こちらも私自身はそれほどしっかり学んだり書いたことがなく，軽く触っただけの感想にはなってしまいますが書きますと，Rx- リアクティブプログラミングはそれ自体がしっかり学ぶべき一大テーマとなっており，正直に敷居はそれほど低くないと思っています．その中でよくでてくるストリームという仕組みが，命令的に書きたい自分としては正直に合わない💦

もしご興味ある方はこちらの記事がとても素晴らしいと評判ですので転載します．自分は全部読めていなく，途中で心が折れて数年が経ちましたw

https://ninjinkun.hatenablog.com/entry/introrxja

Vue の場合

やれるならやったほうが良い

• Vuex

もし Vue を選択するならば，Vuex がほぼデファクトと言って良いでしょう．というか，私はこの子以外の Vue 用 Store ライブラリの存在を知りません．それくらいによく出来ており，脳死でこの子を導入しても良いレベルです．以上です．

Modern CSS

現代のモダン CSS のキーワードは CSS in JS でしょう．今回名前が上がっているライブラリも CSS in JS 用のものばかりです．さらに言うと，React で使われることをベースに開発されているようなものもあったりと，個人的には CSS in JS の話をすると React 文脈になる印象が強いです．

推奨

• Emotion
• CSS Modules

やれるならやったほうが良い

• Styled JSX
• Styled Components

非推奨

• Radium
• Glamorous

styled-components は個人的にいちばん有名な CSS in JS のライブラリだと思っており，推奨と言いたいところですが，実際のプロジェクトで使うかと言われると少々悩みます🤔 というのも，プロジェクトの規模感が大きく，コンポーネント数も増えるとビルド時間がかかるしパフォーマンスが下がることが色んな所で言われてもいます（ちなみに私も実際に経験しました）．ので，学習までは推奨，導入は別を検討 のスタンスです．個人的には emotion が好きですね．

CSS in JS 以外の思想として少し歴史がある CSS Modules というものがあります．こちらは既存の CSS のクラスにランダムな文字列を付与し，コンポーネント単位で閉じることで堅牢性を上げることを目的とした思想で，ライブラリとしても css-modules 一強かなと思っています．

ただ，css-modules はすみません．自分が使ってコードを書いたことがなく，サンプルコードなどを読んだだけなので感想でしかないですが，コンセプトとしては良さそうで，普通に CSS を書いているのにローカルスコープを持てるので，CSS のグローバルスコープが解決すると言うだけでも入れる価値はあります．ちょっとオーバーですが，この効果だけでも推奨で良いかなと．

ただし，webpack の css-loader がメンテナンスモードになるようです（既になったのかな？）．

Sorry, it is out of scope CSS modules spec, In the near future we want to deprecate CSS modules
CSS modules is maintenance stage (only fixes), it is really old technology and very controversial.

参考：https://github.com/webpack-contrib/css-loader/issues/1050?#issuecomment-592541379

ただ，現在では Next.js が css-modules を押している空気が強く，実際に動かしてみると以下のように簡単に導入できる（ついでに Sass の導入も簡単）ように対応されていることもあり，css-modules は全然選択肢としてありだと言えますね．

import styles from './Hoge.module.scss'

export function Hoge() {
  return (
    <button className={styles.error}>
      Click me
    </button>
  )
}

styled-jsx は Next.js などを提供している Vercel 社による CSS in JS のライブラリの１つで，名前の通り，JSX の CSS 実装をサポートするコンポーネントフレンドリーなやつです．あまり深くは触ったことがないですが，だいたい styled-components でできることは被ってる印象ですので，特に理由がなければ styled-components で良いと思ったりしています．

emotion も CSS in JS のライブラリの１つですが，公式サイトにも記載があるように，いくつかのライブラリにインスパイアされて作られたもので，今回名前が挙がっているものとしては，Styeld Components, Glamorous がありますね．後継のライブラリということもあり，殆どの CSS in JS ライブラリでできることはもちろん Emotion でもできます．特筆すべきはバンドルサイズで，例として styled-components と比較（minifyed + gzipped）してみますと，

• Styled Components：12.6kB
• Emotion：216B

と，文字通り桁違いの差があります．書き方の差もあり好みが分かれるとは思いますが，Emotion は個人的には「推奨」にしても良いかな？と思っています．

ちなみに，DL数について興味深いことが分かったのでツイートしてみました💁

https://twitter.com/kuwahara_jsri/status/1400063423304527874?s=20

最後に非推奨の２つは自分も初めて目にしたライブラリでした💦 が，まぁ非推奨ならばやらなくて良いと思います．特に Glamorous はメンテナンスもストップしてしまっているようですね．

Web Components

厳密には今じゃなくても良い

• HTML Template
• Custom Elements
• Shadow DOM

そもそも各項目が Web Components を構成する要素・API 群なので，これらはワンセットになります．重要度も完全に同意で，今じゃなくても良いかなーという感覚です．Web Components が もっと熟成してきて，既存の生態系から乗り換えるメリットが生まれたときに初めて検討するのでも遅くはないと思っています．

また，各ブラウザの対応状況を Can I Use などのサイトで確認すると，対応していない機能が多かったりするので，そもそも導入できない可能性が高いですね．

今回も大きく２つに分けられていますね．とりあえず JS based と CSS first とします．

JS bases and better to use with your framework based JavaScript Applications.

CSS first frameworks which don't come with JavaScript components by default.

CSS Frameworks(JS based)

推奨

• Reactstrap
• Material UI

やれるならやったほうが良い

• Tailwind CSS
• Chakra UI

こちらも React の文脈が強い選定に感じました（笑）４つ中３つが React 用のフレームワークですので（笑）

Reactstrap は Bootstrap の React に特化したフレームワークですね．公式サイトにも「簡単に React で Bootstrap 4 のコンポーネントを使えるようにしたもの」と記載がありますので，ほぼ Bootstrap と言っても良いでしょう．

個人的には Bootstrap は開発の現場で強く勧められるものではありません（逆に非推奨とも思っていません）が，学習という意味ではイチオシのフレームワークです．Bootstrap のコードはとても素晴らしく，とにかく CSS の勉強がしたいのであれば，一度は Bootstrap のソースコードを読んでみることをオススメします．

CSS フレームワークとしては Bootstrap 以外にも素晴らしいものが現代にはいくつかありますので，それらと比較した上で選ぶのが良いかなーと．まぁ，これは Bootstrap に限った話ではなく，他の CSS フレームワークにも当てはまりますが😅

Material UI は，おそらく React 勢なら一度は目にしたことがあるフレームワークではないでしょうか．Google 社が提唱した Material Design の React に特化させたコンポーネントライブラリですので，Material UI というより Material Design の評価をした方が公平ですね（この人本当に React 好きだな）．

で，推奨かどうかという話ですが，Bootstrap 同様，推奨とも否とも言えないですね．好みもあるとは思いますし，実装するアプリケーションや動作するプラットフォームを加味した上で選択するとよいかと思います．まずは色んな CSS フレームワークを比較されることをオススメします．

Tailwind CSS は弊社でも評価され始めており，個人的にも「推奨」にしても良いかなと思っている CSS フレームワークです．近年一番感動した CSS フレームワークで，割と推したい子でもあります😁

特徴としては，一言でいうとユーティリティクラスの集合体となりますが，これが意外とメリットがあります．１つは「拡張性」，１つは「スタイルの把握がしやすい」，そして「CSS の学習」となります．あまり CSS に慣れていない人でも，Tailwind CSS を書いていくと自然と CSS の理解が深まっていくでしょう．一度検討及び導入してみてください❗

Chakra UI はすみません，私は今回初めて知ったので何もコメントできず🙇

CSS Frameworks(CSS first)

推奨

• Bootstrap

やれるならやったほうが良い

• Materialize CSS
• Bulma

こちらも概ね同意で，先程述べてきたこととほとんど同じなので割愛します．強いて言えば，上記に加えて Semantic UI や Foundation とかも入れたいかな，というのが私自身の気持ち（というか好み）です．

一応参考までに，それぞれのダウンロード数比較を載せておきます．（それにしても，Bootstrap は任期だなぁ）

https://www.npmtrends.com/bootstrap-vs-bulma-vs-foundation-sites-vs-materialize-css-vs-semantic-ui-vs-material-design-lite

Testing your Apps

推奨

• Jest (for unit test)
• react-testing-library (for unitiIntegration test)
• Enzyme (for unitiIntegration test)
• Cypress (for E2E)

非推奨

• Mocha
• Chai
• Ava
• Jasmine

先に非推奨ライブラリについては言及しますと，正直に同意なのですが，結構使ってきたので寂しいですね…しかしモダンなライブラリ（Jest など）であれば，後発ということもあり非推奨のライブラリ達の機能はカバーしており，かつ非常に使いやすくもなっておりますので，技術の進歩ということでこれは仕方がないと思います．むしろ進歩を喜びましょう．

そして推奨ライブラリも完全同意です．今はこれらのライブラリを使えばだいたいフロントエンドのテストはカバーできると言って差し支えないと思います．私自身すべてのライブラリを一度は触っておりますが，Jest と Cypress が多めで，残り二つは軽く触ったかあるいは途中でジョインしたプロジェクトですでに使われており，そのテストコードを眺めた程度のため，ググった知識しかないです（自身の不勉強さが現れるなぁ…🙇）．

個人的にはとりあえずフロントエンドのユニットテストを初めて書く方には Jest から入門することをおすすめします．モダンなテスティングライブラリとして豊富な機能を備えており，かつドキュメント・サンプルコードも充実しているため，この子でもとりあえずは十分にアプリケーションの自動ユニットテストの環境は整えられると思います．欲しい機能としては

・高速に実行
・モッキング
・カバレッジ
・アサーション
・スナップショット
・スパイ

だいたいこのあたりで，Jest はすべて備わっております．また対応しているライブラリも React, Vue, Angular, Node.js と幅広く，突っ込んだ使い方をしない限りはとても使いやすい子ですね．

Enzyme, react-testing-libary は公式サイトにも for React とあるように，メインの UI ライブラリが React の場合にはとても有効です．もちろん Jest でも良いですが，この二つはちょっと使い方が違って DOM に寄せたもののようですので，コンポーネントそのものに関するテストを書くならばこれらを使うと良さそうですね．

Enzyme vs React Testing Library結局どっちがいいのか問題に対する個人的な回答

などの記事があるように，この二つは比較されることが多いようですが，

Business Logicやコードの実装のテストをしたい場合はEnzymeが向いているし、実際のユーザーのアプリの使い方に基づいたテストをしたい場合はReact Testing Libraryが向いています。

のようにライブラリ毎に強みや特性があります．したがってどちらを使うのが良いか？に関して述べると，すべてのテスティングライブラリの選定でも同じことが言えるのですが， そのアプリでどういうテストを書きたいのか を考えて選ぶにつきますね💁（当たり前のことしか言えなかった…）

こちらでも一応それぞれのダウンロード数と github の数字を載せておきます．

https://www.npmtrends.com/@testing-library/react-vs-cypress-vs-enzyme-vs-jest

Type Chekcers

推奨

• TypeScript

非推奨

• Flow

前提として，型チェックそのものについて「厳密には今じゃなくて良い」という評価だそうですが，個人的にはそのチームや組織のステージ，チームの熟成度，開発の規模，メンバーのスキルレベルなど，色んな外部要因を加味した上で判断スべきだと思っていますので，一概に今じゃなくて良いとも言えないかなと． 規模が大きい開発であればそれに耐えうる開発環境や体制 を考えますので，積極的に型チェックツールは入れたいと考えるでしょう．逆に軽量でとにかく早くプロダクトを出したいとか， テストでしっかりプロダクトの品質の担保をするという要求であれば入れないほうが早いかもしれません．（保守性やコードの品質は下がる確率は上がりますが）

その上で推奨に挙がっている TypeScript ですが，Microsoft 社が生み出した最高傑作の一つと言っても良い，皆さんご存知のオープンソースのプログラミング言語です．個人的にはそこまで好きではないですがフロントエンドの開発において十分に恩恵を受けていますし，世界的にも今や フロントエンドの型チェックのデファクトスタンダード と言っても過言ではないでしょう．今後も TypeScript は進化していくでしょうしこの流れは当分続くと思っています．したがって，今型チェックのツールを入れるのであれば TypeScript で間違いないかなと．

Flow（Flow Type と言うことのほうが多いかも） は Facebook 社謹製の型チェックツールで，npm でインストールする方法もありますが，ソースビルドをしてマシンそのものにインストールして使う方法が README に記載されていますので，そちらが本来の使い方（？）のようですね．ただ，よっぽど理由がなければ現代では TypeScript を私はお勧めします．理由としましては，

• 現代のフロントエンドの開発におけるエディタも VSCode が主流になってきている
• VSCode も Microsoft 社が開発しており，TypeScript との相性がかなり良い
• TypeScript の方が利用実績も多い（はず）
• ググラビリティが高い（ググったときの雑音が Flow は多い）

以上，TypeScript で幸せなフロントエンド開発を！

Progressive Web Apps(PWA)

PWA はスマホユーザーが Web アプリの体験を良くするために，Google が提唱した開発者がネイティブアプリの品質を、信頼性が高く、高速で、魅力的なWebアプリケーションで提供するための仕組みや手法です．

参考：https://developers.google.com/web/ilt/pwa

ですが，ごめんなさい！PWA を実践の開発の場で使う機会があまりにも少なく， 完全に理解した 程度の知識しかないため，ほとんど言及ができません…

ただ，Service Worker を用いてのオフライン対応や A2HS(Add to Home Screen) などは対応する価値は十分にあると思っていますので，これらは Web アプリ開発の実装項目に含めるかの検討は良いと私は感じています💁

もし PWA を導入したいと考えているならば，Google 社のチェックリストが非常に参考になりますので，是非一読ください！
https://web.dev/pwa-checklist/

また，PWA を実装するのであればこれまた Google 社謹製の Workbox というライブラリが非常に優秀ですので，こちらを使うことをお勧めします．
https://developers.google.com/web/tools/workbox

さらに PWA Night というコミュニティが継続的に勉強会やカンファレンスを開催してくださっていますので，そちらにご参加いただいた方が知見やノウハウを得られると思いますー．

https://pwanight.connpass.com/

Server Side Rendering(SSR)

推奨

• React.js/Next.js

やれるならやったほうが良い

• Angular/Universal
• Vue/Nuxt.js

非推奨

• Alter.js

そもそも今は SSR やる？とか必要？という議論が起きているくらいですし，今後必要性は薄くなってくることは間違いないと思います．というのも Google bot が進化してきており，今後 SPA の Web アプリでもしっかり SEO が効くようになる未来が来るでしょう．もちろん動画投稿サービスや SNS サービスなど 更新頻度が高い Web アプリ であれば十分に検討に上がると思います．

この手の話は色んな所で議論が活発に行われておりますし，ググってみると（この後言及しますが）SPA / SSR / SSG / ISR の比較記事がたくさん書かれておりますので，そちらを見ていただくほうが良いと思います．

その上で個人的には推奨に挙がっている React.js/Next.js が最もおすすめのフレームワークですね．そもそも（二回目） 現代では Next.js に Pre-rendering という機能が組み込まれており，この概念の議論も生まれております．これは簡単に言うとページ毎に SSR/SSG を選択できるというものです．選択肢が増えるのはありがたいですねぇ👍詳しくは下記リンクより公式サイトをご一読ください．

https://nextjs.org/docs/basic-features/pages#pre-rendering

また，このロードマップは海外の人が作成されている背景からも React.js の方が主流なんだなと予測しますが，日本ではまだまだ Vue/Nuxt.js の方が人気の印象が強く，導入している声もよく耳にしますし，自分も一プロジェクト Vue/Nuxt.js で SSR の経験がありますが結構使いやすかったのでこちらでも全然良いと思います．

参考：https://nuxtjs.org/docs/concepts/server-side-rendering/

残りの Angular/Universal ですが，Angular の経験については Tour of Heroes に沿って手を動かしてみたのと，簡単な Web サイトを作ったのみで，Universal を使って PWA をやったことがないので何も言えないです🙇

GraphQL

推奨

• Apollo

やれるならやったほうが良い

• Relay Modern

今 GraphQL を導入するならまっさきに Apollo を考えるかな〜と思います．数プロジェクト（React がメインの UI ライブラリのプロジェクトでした）で使ってみたところクライアント側もサーバー側も導入や設定がしやすく，かなり使い勝手がよかったです．初めて本格的に触ったときは「GraphQL 使うなら当分は Apollo で良いわ」と思ったのを覚えていますね！

対応ライブラリも多く，クライアント側は Web のみでなく iOS/Android などネイティブの言語でもいけるし，サーバー側は Express, Hapi, fastify など大抵の Node.js のフレームワークと組み合わせて使うことができます．ありがたし．

ただ，Web フロントエンドのドキュメントとしてはまだ React のサポートのみが手厚く，それ以外についてはまだまだこれからのようですね．公式サイトを見てもメンテ中となっており，詳細はそれぞれのライブラリのリポジトリを参照するように書かれていますね💦

https://www.apollographql.com/docs/react/integrations/integrations/

Relay Modern は名前だけは聞いたことがありますが，実はノータッチでして…🙇ざっと公式サイトを眺めたところ，書き方としてはそんなには Apollo と大差はないような印象を受けます．またドキュメントが充実しており，サンプル・テスト・デバッグ・アップグレードまでしっかり書かれており，これは好印象ですね！

https://relay.dev/docs/

ただ，

Relay is a framework for data management with the primary supported binding for React applications, so we assume that you are already familiar with React.

とありますので，やはり React 用のフレームワークのようです😅一応 Vue.js 用の vue-relay なるものもあるようですので，この辺はエコシステムが充実することを待つばかりですね．

Static Site Generators(SSG)

推奨

• Next.js
• Gatsby.js

やれるならやったほうが良い

• Nuxt.js
• VuePress
• Jekyll
• Hugo

前提として，このロードマップでは SSG は「厳密には今じゃなくて良い」という判断らしいですが，個人的にはもう推奨と言っても良いんじゃないかなぁと思います．

名前の通り動的にデータを更新するようなものではなく，ホームページやブログなどの静的なサイトを生成するのに向いている技術です．CDN による高速な配信もできますので非常にユーザー体験としては高いものになるのは間違いないですね．

ですが，これだけであれば 単に自分でデータを直接 HTML に書いておくのとほとんど違いはなく，むしろ API 通信がない分手書きのほうが早い可能性が高いですが， データ量が多かったり，「いいね機能」などの一部動的にデータを取得することもあるので，その場合はビルド時にデータを取得する SSG の方が適しています ね．

さて，上記を踏まえて何が良いかというところですが，個人的にも納得なのが Next.js です．理由は既に出てきました Pre-rendering 機能の登場です．これによりすべて Static にビルドするのでなく一部動的にデータフェッチングをして変化させたいという需要はあると思っていて，これにより Web アプリでも SSG は威力を発揮できるようになり，より Web サイトの最適化ができますので，私は Next.js 推しです．

Gatsby.js もかなり良く，プラグインやテーマシステムが備わっておりますので，欲しい機能があればコードを書かなくとも npm から持ってこれますし，見た目もカスタマイズしやすくなっています．が，裏で GraphQL を使っており学習のコストや GraphQL の環境設定などが必要になりますので，ちょっとコストが高い印象です．ただ GraphQL そのものの恩恵を受けられるというメリットもあるので一概に Next.js の方が優れているとは言えなく，私個人の好みですw

ちなみに Gatsby.js から Next.js への以降のドキュメントも用意されておりますので，ご参考までに💁
https://nextjs.org/docs/migrating/from-gatsby

さらに参考としてわかりやすい比較記事がありましたので載せておきます．
https://gotohayato.com/content/511/

その他のツール達はもうぶっちゃけて好きなものを使っていただければ良いと思います！（サボったわけではなく，こうとしか言いようがないため😂）

Mobile Applications

推奨

• React Native

厳密には今じゃなくて良い

• NativeScript
• Flutter
• Ionic

こちらも前提として，このロードマップでは SSG は「厳密には今じゃなくて良い」という判断らしいですが， 私としては「やれるならやったほうが良い」レベル だなと思っています．単にエンジニアの生存戦略的な目線や幅を広げるという意味で，です．後は Web 技術でアプリケーションを作れるという魅力の大きく，ビジネス的にもこれができるならそれほど嬉しいことはありませんしね．

その上で，推奨に React Native が入っているのは意外でした．もちろんまだまだ現役のフレームワークだと言う点には異論はありませんが，今となっては Flutter の台頭が著しく，こちらに舵を切っても良いと思っているからです．コミュニティの規模も加速的に大きくなっており，導入事例も同様のため，やっといて損はないんじゃないかなと．

ただ新たに Dart という言語をやる価値についてはなかなか是非は言えないとも思っています．Flutter 以外で使うとは思えませんし🤔逆に React Native なら結局は React の延長線ですので，React の知見や経験を持っていけるのも大きいですしね．ということで，Flutter は限りなく推奨よりの「やれるならやったほうが良い」としますw

NativeScript は個人的にはこの一年ほとんどこの名前を耳にしたり目にすることがなかったので，限りなく非推奨に近い「厳密には今じゃなくて良い」としたいかなと．しかし全く触ったことなく評価するのはいかがなものかと🤔←

最後に Ionic ですが，私情を挟むとお勧めしたいです．今までに Ionic の日本ユーザー会に色々貢献してきた実績があり，日本で Ionic といえば 榊原氏 ですが，彼の書籍に執筆をお手伝いしたこともありますので．

この子の実態としてはあくまで UI を担当するフレームワークで，デフォルトで iOS/Android それぞれに特化したスタイリングにビルドしてくれるのはかなり魅力的です．また裏で動くメインの JS フレームワークは今では好きに選べるようになったのも大きいかなと．

Ionic の進化もとてもおもしろく，元々は Web アプリをモバイルにビルドする（多少語弊がありますが，わかりやすさのため）ものの印象が強く，また AngularJS / Angular と二人三脚で歩んできましたが，途中で Web Components に対応することで React.js でも Vue.js でも，その他どんな UI ライブラリでも導入できるようになりました．

さらに Ionic 社が Stencil という最適な Web Component を提供するためのコンパイラを開発しましたが， フレームワークや UI ライブラリ毎に作ったコンポーネント資源の相互作用ができなかった り，パフォーマンスやコードサイズの肥大化とネットワーク環境による低レイテンシー問題などがこのコンパイラによって解決するというソリューションが提供されました．

Stencil is a compiler that generates Web Components (more specifically, Custom Elements) and builds high performance web apps. Stencil combines the best concepts of the most popular frameworks into a simple build-time tool.

URL：https://stenciljs.com/docs/introduction

ちなみに Stencil は Ionic v4 からコンパイラの選択肢として実装されておりますので，Ionic では使えないということはありませんのでご安心ください😁

Desktop Applications

推奨

• Electron

非推奨

• Carlo
• Proton Native

デスクトップアプリケーションを JavaScript / Node.js で作るなら Electron 一択です．これ以外のツールを私が知らないだけかもしれませんが，この数年で Carlo も Proton Native のワードを一度も目にしたことがなく，かつ元も子もないことを言うと，デスクトップアプリケーションを JS で作る必要性もあまりないんじゃないかな，と私は考えております．

ということで JS で作るなら Electron ですが，前提としてデスクトップアプリケーションそのものが「厳密には今じゃなくて良い」となっている点も同意です．仕事で必要になったりどうしても欲しい物が生まれたときで良いんじゃないかなーと思います．

Web Assembly

ラストに Web Assembly はやれるならやったほうが良いよりの「厳密には今じゃなくて良い」です．この一年間でも Rust 言語の人気は加速しており，実際に導入した事例もちょこちょこ聞き始めたため，やっといて損はないかなと．というか，多分くる言語だと思っていますので，今のうちにキャッチアップしておきたい言語筆頭候補だと思います．

最後に

思ったより自分がフロントエンド技術について触っていないものばかりだったことを改めて認識しましたね．ついつい UI ライブラリやフレームワークばかり目が行きがちですが， フロントエンドの技術全体を見渡すと優先的にキャッチアップすべき技術は他に沢山あります ．

やはり技術者としては作ることもそうですが，

• 作ったものがしっかりエンドユーザの手に届くこと
• ビジネスを加速させるための技術的ソリューションの提供
• 当たり前にシステムやアプリが動作するサポートをすること

に注力することが肝要ですので，来年も技術のプロとしての自覚とともに何を学んで行くのかは吟味しつつ選んでいきたいと思います．

ではでは！