Open16

WEB DEVELOPER Roadmap 2021 の Frontend Developer を見ての振り返り

こんにちは.株式会社ゆめみ でチャレンジ取締役をしております 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 のロードマップ を見ていきたいと思います.

Developer Frontend roadmap 2021

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

※4つの優先度については,このスクラップでは以下のように訳します(=゚ω゚)ノ

  • Personal Recommendation / Opinion
    → 推奨

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

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

  • I wouldn’t recommend
    → 非推奨

Internet

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

推奨

  • 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

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

JavaScript に関するおすすめの書籍は以下2冊です.前者の「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

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

Web Security Knowledge

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

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

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

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

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

Package Managers

推奨

  • npm
  • yarn

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

yarnnpm が使えればなくても良いですが,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-componentsemotion などのライブラリに代表される 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 も知っておいて損はないかなと.実際はほぼ使うことはないですが,レガシーな環境で実装することを求められている現場で,せめて TypeScriptSass だけは入れたいとか,画像圧縮だけはしたいとか,少しでも開発環境を良くしたいのであれば gulp + gulp-xxx(導入したいツール用サードパーティ製ライブラリ) という選択肢は悪くないと思います.

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

Build Tools(Module Bundlers)

推奨

  • Webpack

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

  • Rollup
  • Parcel

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

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

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

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

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

Webpackparcel の比較記事も色々書かれていますが,こちらの記事が比較的新しくかつ詳しく書かれているのでわかりやすいです.

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 スターも2万を超えている老舗ライブラリで,高い人気と導入実績がありそうなことも伺えます(実際に導入実績を見ると,nodejs, npm, github など錚々たる名前が並んでいますし).現場では細かく設定したいときもあるので,その場合は個別にライブラリの設定をするほうがよく,柔軟性という点でもあまり使うケースは少ないかなと.細かな事考えずに,とりあえずなにかのルール上に乗っかって開発したい人にはマッチすると思いました.

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

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

Pick a Framework

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

▼メインフレームワーク

推奨

  • React.js(以下,React

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

  • Angular
  • Vue.js(以下,Vue

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

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

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

個人的な意見というか好み(あくまで私見です)では 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 に寄せて独自フックを実装している RecoilJotai(こちらの方が個人的にはオススメ) を推します.

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

手前味噌ですが 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 のグローバルスコープが解決すると言うだけでも入れる価値はあります.ちょっとオーバーですが,この効果だけでも推奨で良いかなと.

ただし,webpackcss-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.jscss-modules を押している空気が強く,実際に動かしてみると以下のように簡単に導入できる(ついでに Sass の導入も簡単)ように対応されていることもあり,css-modules は全然選択肢としてありだと言えますね.

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

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

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

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

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

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

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

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

Web Components

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

  • HTML Template
  • Custom Elements
  • Shadow DOM

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

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

今回も大きく2つに分けられていますね.とりあえず JS basedCSS 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 の文脈が強い選定に感じました(笑)4つ中3つが React 用のフレームワークですので(笑)

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

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

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

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

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

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

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

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


CSS Frameworks(CSS first)

推奨

  • Bootstrap

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

  • Materialize CSS
  • Bulma

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

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

https://www.npmtrends.com/bootstrap-vs-bulma-vs-foundation-sites-vs-materialize-css-vs-semantic-ui-vs-material-design-lite
ログインするとコメントできます