すべての新米フロントエンドエンジニアに読んでほしい50の資料

この記事は最終更新日から1年以上が経過しています。

はじめに

さいきんのWebはSPA技術を中心としたフロントエンドが賑わっていますね💪

従来サーバーサイドを扱っていた人もフロントを触る機会が増えていたり、これからプログラミングを学んでいく人も、フロントエンド領域に興味を持っているのではと思います。
そこで、フロントエンドの経験が浅い方や初学者向けに、おすすめのドキュメントや勉強すべき領域をまとめました。

とりあえず動けば良い段階から一歩進んで、フロントエンドエンジニアとして、良いアプリケーションを作るために必要な知識を浅く広く紹介します。

※補足
新米と表記しましたが、実際には新卒や未経験でなく、新卒2~3年目の若手フロントエンドエンジニアやフロント分野に苦手意識のあるバックエンドエンジニアの方を対象としています。
数日で目を通せるような内容ではないため、マイルストーンやスキルセットの一つの参考にして頂けると幸いです。

フロントエンド入門

公式ドキュメントを知る

[1] https://jp.vuejs.org/v2/guide/
一例としてVueを貼りましたが、Vueに限らず信頼出来る情報に当たる癖付けがとても大切です。
特にVue.jsは一昔前のjQueryやRailsやPHPのように、技術に明るくない方が書いたページが多いと感じていて、ちゃんとVueを学ぶならまずは公式を見ましょう。

言語を知る

JSを知る

[2] https://jsprimer.net/basic/introduction/
今からJSを学ぶなら特別な事情がない限り、ES2015以降の文法で良いと思います。
js-primerはES2015以降のJSを知る上で素晴らしいドキュメントです。

昔のJSもちょっと知る

[3] https://developer.mozilla.org/ja/docs/Web/JavaScript/Closures
データの隠蔽やカプセル化を実現するために使われたテクニックです。
今のJSを書く場合に意識する機会は少ないと思いますが、知っておいて損ないです。

[4] https://www.yunabe.jp/docs/javascript_class_in_google.html
ES5以前の古いJSで記述しなきゃいけない仕事に遭遇した際、あらためて読み返したい素晴らしいドキュメントです。ベストプラクティスのひとつだと思います。

昔のJSもしっかり学びたい方は、「JavaScript: The Good Parts」や「開眼!JavaScript」といった書籍の購入も検討してください。
上記の書籍を読んで、DouglasやJohnResigやSubstackを知っていると、先輩のフロントエンドエンジニアから気に入られる確率が向上します(当社比)

非同期処理を知る

[5] http://azu.github.io/promises-book/
非同期処理は初学者にとって大きな壁の一つだと思いますが、しっかりとPromiseオブジェクトを理解することがJSでは必須です。
ES2017で追加されたAsync Functionは、Promiseを返す関数なのでPromiseが分かればすぐ理解できます。

Promiseを理解したら、Asyncjsのようなライブラリで複雑な非同期処理を実装したり、
RxJSのようなライブラリを用いてPromise以外の非同期を扱う方法を学んでみると良きです。

HTMLLivingStandard & ECMAScript を知る

[6] https://html.spec.whatwg.org/multipage/
[7] https://www.ecma-international.org/publications/standards/Ecma-262.htm
聖書。HTMLやJSといった言語の仕様が記載してあります。

ちなみに私のチームでは、実装周りの裁判が発生した際に、六法全書代わりとして活用しています。
※私はおそらく全体の3%ほどしか読んでませんが、ちゃんと読んだぞという空気を出して会話します💪

コーディング規約を知る

[8] https://qiita.com/mysticatea/items/f523dab04a25f617c87d
[9] https://qiita.com/soarflat/items/06377f3b96964964a65d
これからフロントエンドを学ぶ方すべてに、まずはLintとコードフォーマッターの導入をお勧めします。
Lintではeslintやstylelint、コードフォーマッターではprettierがデファクトです。
利用するルールは何でも良いと思いますが、とにかくルールを用意することが大切です。

UIを知る

モーショングラフィックやインタラクションを知る

[10] https://goodpatch.com/blog/ui-micro-interaction/
マイクロインタラクションはデザイナーの仕事という認識の方も多いと思いますが、
特殊な例外発生時にユーザーへ適切なフィードバックを返すべきといった気付きはエンジニアの方が強いと思うので、常にプログラム的な例外とUI的な例外(フィードバック)の両方を考える姿勢が大切だと感じます。

マテリアルデザインを知る

[11] https://material.io/design/
Google公式のデザインガイドです。英語のドキュメントですが、グラフィック中心なので分かりやすいです。

アトミックデザインを知る

[12] https://ygoto3.com/posts/atomic-design-on-actual-project/
ReactやVueを用いる際にコンポーネント分割の粒度としてアトミックデザインを活用するといったケースがあります。
アトミックデザインに固執する必要はないですが、コンポーネントをどう分割していくかをデザイナー交えて検討するのは大切だと考えていて、土台としてアトミックデザインは有用と思います。

アクセシビリティを知る

セマンティックを知る

[13] https://developer.mozilla.org/ja/docs/Learn/Accessibility/HTML
[14] https://developer.mozilla.org/ja/docs/Learn/Accessibility/CSS_and_JavaScript
セマンティックなコーディングを行うことでアクセシビリティだけでなく、SEOに対してもメリットがあると言われています。

ARIAを知る

[15] https://developer.mozilla.org/ja/docs/Learn/Accessibility/WAI-ARIA_basics
可能な限りネイティブなHTMLで解決すべきで、必要なときだけ使うことが推奨されています。
業務アプリなど利用ブラウザが制限できて、かつ複雑なUIでは活躍の機会があるかもしれません。

SEOを知る

お上の言うことを知る

[16] https://support.google.com/webmasters/answer/35769?hl=ja
まずはお上の言うことに従いましょう。
私は毎晩、「Googleは神」と三回復唱してから寝るようにしています。

構造化データを知る

[17] https://developers.google.com/search/docs/data-types/article?hl=ja
担当業務領域によっては、構造化データを設定することが必要かもしれません。

SEOと直接関係ありませんが、GAやdatalayerを正しく設定することもフロントでは大切です。

ブラウザを知る

ブラウザの仕組みを知る

[18] https://www.html5rocks.com/ja/tutorials/internals/howbrowserswork/
結構長いので、他国の文化を知るような気持ちで、ブラウザってこうなってんだって読むのをお勧めします。

デバイスおよびブラウザの特性を知る

[19] https://caniuse.com/
フロントエンドの辛いところとして、コードの実行環境(ブラウザ)が無数にあることが挙げられますが、JSやCSSがその環境で実行可能か確認できます。

JSに関しては、IE11などでもES2015以降の機能を使えるbabel-polyfillの導入も検討しましょう。

Threadを知る

[20] https://nhiroki.jp/2018/05/07/off-the-main-thread-api
JavaScriptにはメインスレッド(=UIスレッド)が一つしかないので、普通に書くと非同期処理であってもシングルスレッドの直列で実行されます。
重たい処理(UI的にカクついてしまうとか)をマルチスレッドで実行するために、Web Workerの利用を考えましょう。

JITを知る

[21] https://dev.mozilla.jp/2017/05/%E3%82%B8%E3%83%A3%E3%82%B9%E3%83%88%E3%83%BB%E3%82%A4%E3%83%B3%E3%83%BB%E3%82%BF%E3%82%A4%E3%83%A0-jit-%E3%82%B3%E3%83%B3%E3%83%91%E3%82%A4%E3%83%A9%E3%81%AE%E3%82%AF%E3%83%A9%E3%83%83%E3%82%B7/
(難しくてよく分かってませんが😭)モダンブラウザは実行時最適化と呼ばれるコンパイルを行っているそうです。

常に同じ型で呼び出される型を仮定するそうなので、私のような市井のプログラマには、型を意識した開発を心掛けることでJITの恩恵を享受できる可能性があります。
お気づきの方も多いと思いますが、それはTypeScriptと相性が良いです。

セキュリティを知る

DOM Based XSSを知る

[22] https://gihyo.jp/dev/serial/01/javascript-security/0006
モダンなフロントのフレームワークを使っている場合、もはや意識しないかもしれませんが、JS初学者は一度目を通しましょう。

CORSを知る

[23] https://developer.mozilla.org/ja/docs/Web/HTTP/CORS
CORSを理解しそのクライアントとサーバーを実装すると、HTTPに対する理解も深まるのでとてもお勧めです。

CSRF脆弱性とjwtを知る

[24] https://techblog.yahoo.co.jp/advent-calendar-2017/jwt/
jwt(json web token)は、OAuth2.0という認可の仕組みのアクセストークンとして採用されるなど広く使われています。

CSRFという、なりすましのような脆弱性が存在すること、その対策の一つとしてredirect_uriの制限が可能なjwtが存在することを理解出来るとOKです。
GoogleやFacebookのような代表的なOpenID Providerは、stateにredirect_uriを含めuriのホワイトリストと突合するのが必須になっていると思います。

テストを知る

ユニットテストを知る

[25] https://jestjs.io/docs/ja/getting-started
Reactはもちろん、Vueを使う際もJestがお勧めです。
ただフロントエンドのテストはベストプラクティスが無いと言われていて、下記のようにどういったテストをすべきかをまず検討しましょう。
[26] http://akito0107.hatenablog.com/entry/2018/08/27/190333

もしかしたらあなたに必要なのはユニットテストではなく、TypeScriptかもしれません。

E2Eテストを知る

[27] https://techblog.lclco.com/entry/2018/06/28/080000
フロントエンドが自主的に行うE2EとしてはPuppeteerがデファクトではないかと思います。
ユニットテストでも書きましたが、E2Eの運用も楽ではないので何をテストするのかちゃんと計画しましょう。

代表的なUIテストを知る

[28] https://qiita.com/masaakikunsan/items/dad8d84807918f3a43cb
storybookを採用することで、再利用性やテスト容易性が向上すると思います。
実装やメンテは大変なので、小規模なチームでの採用はコストに見合わない可能性があります。

データストアを知る

cookieを知る

[29] https://developer.mozilla.org/ja/docs/Web/HTTP/Cookies
仕様が複雑ですが、とても良く使うためちゃんと理解しましょう。ブラウザのユーザー固有情報においてサーバーとやり取りできる唯一のストレージです。

他にもブラウザだけで扱えるWeb Storageも存在します。サーバーとのやり取りが不要ならこちらを使いましょう。
[30] https://developer.mozilla.org/ja/docs/Web/API/Web_Storage_API#Web_Storage_concepts_and_usage
HTTPヘッダに乗ることもなくブラウザだけで完結するため扱いやすいですが、外部サービスのJSから取得可能な領域のため個人情報を置いたりするのは止めましょう😡

NoSQLを知る

[31] https://firebase.google.com/docs/database/ios/structure-data?hl=ja
リンク先はFirebaseのRealtime Databaseですが、MysqlのようなRDBとは設計思想がまるで異なることが分かると思います。
※Cloud Firestoreの設計は、上記のベストプラクティスと異なります。

Cloud FirestoreやDynamoDBといった新世代の優れたデータストアは、これまでバックエンドエンジニアが培ってきた設計が通用しないため運用が難しいと議論されています。
[32] https://qiita.com/funasaki/items/6cdc8f7f7b709e5e601f

一方、多くのネイティブアプリエンジニアが運用してきたように、UIに近い立場のフロントエンドにとっては比較的自然に扱えるデータストアだと感じるので、触れてみるのがお勧めです。

モダンフロントエンドへ

Fluxと仮想DOMを知る

[33] https://qiita.com/mizchi/items/4d25bc26def1719d52e6
Qiita史に燦然と輝く魂の名文。
なぜVueやReactがこれほど重要な位置を占めたか、そのすべてが書いてあります。

私的な余談ですが、右も左も分からない新卒エンジニアだった当時この文章を読んで、全然内容は分からなかったんですが、この筆者が一体何に興奮しているのか興味を持ち、Reactを学びたくなったという背景があります。

言語を知る

TSを知る

[34] https://www.typescriptlang.org/docs/home.html
折に触れてTypeScriptの名前を出してきましたが、今からJSのプロジェクトを始める場合、どんなケースにおいてもTSの採用をオススメします。そこに迷いはありません👊

React, Vueを知る

[35] https://ja.reactjs.org/docs/getting-started.html
とりあえずReactかVueのどちらかを学びましょう。

現時点ではTSとの相性がReactの方が高いです。Vue3.0がリリースされるとVueでもTSXがネイティブサポートされ解消される見込みですが。

個人的には、Vueの双方向と単方向データバインディングの合わせ技を便利と感じるか邪悪と感じるかで、VueとReactのどちらを採用するかが決まるかなと考えています。

CSS in JSを知る

[36] https://qiita.com/taneba/items/4547830b461d11a69a20
styled-componentsの採用が多いです。

CSS in JSを嫌っている人もいますが、コンポーネント単位でインターフェースやインタラクションを定義していきましょうという時代に適した手法と感じます。

アーキテクチャを知る

CDNを知る

[37] https://speakerdeck.com/sisidovski/nikkei-itpro-cdn
リリース当時、界隈で話題になった日経電子版のCDNを中心とした設計の話です。
とにかくCDNで出来ることが増えていて、なぜ使うのか、どういったことが可能なのか知ることが大切です。

JAMStackを知る

[38] https://qiita.com/ossan-engineer/items/4fe0e3e388f510bd5c68
CDNファーストを考えた際に、第一候補となる構成です。
この構成を目指す際に採用するGatsbyやVuePressのようなFWは、静的サイトジェネレータ(SSG)と呼ばれる事が多いです。

BFFを知る

[39] https://www.atmarkit.co.jp/ait/articles/1803/12/news012.html
特にこの記事で素晴らしいと思った点は、フロントエンドの担当領域を明確に定義している点です。

私的な余談ですが、なぜBFFという考え方が誕生しその領域をフロントエンドが担うべきなのか、おぼろげに理解できたとき私のなかで点だった技術や思想が線で繋がった感覚がありました。

BFFとSSRを知る

[40] https://speakerdeck.com/yosuke_furukawa/ssrfalsehua
SSRも一種のBFFと呼べますが、なぜSSRをすべきなのかが最もわかりやすいと思います。
さすが日本Node.jsユーザグループ会長、ウォーリーのアイコンも可愛いです。

アーキテクチャの補足ですが、既存の技術資産を活用するためRailsをAPIで残して、フロントエンドだけをモダンにするみたいなケースも見られます。
[41] https://speakerdeck.com/fukuiretu/notewonuxt-dot-jsdezai-gou-zhu-sitahua

レンダリングを知る

[42] https://developers.google.com/web/updates/2019/02/rendering-on-the-web
モダンなフロントエンドのアーキテクチャをレンダリングという観点からまとめたGoogle謹製ページ。
2019年に生きるすべてのフロントエンド必読です。

SSRやSSGを実現する方法を知る

[43] https://ja.nuxtjs.org/guide
NuxtやNextを良く聞くけどイマイチ分かってなかった方々、ここまでの話を読むと凄さが伝わるのではないかと思います。
サーバーサイドでReactやVueが実行可能になったことで、SSRが市井のエンジニアでも実現可能になりました。
NuxtやNextではSSGも可能です。

パフォーマンス改善を知る

Service Workerを知る

[44] https://developers.google.com/web/fundamentals/primers/service-workers/?hl=ja
Service Workerを用いたcacheを行うことで、2回目以降のFCPなどのタイムを大幅に削減可能です。

このAPIを用いると、従来Webから出来なかったプッシュ通知などの体験を提供できることから、Service Workerを活用したWebアプリはPWAとも呼ばれてます。

lighthouseを知る

[45] https://developers.google.com/web/tools/lighthouse/?hl=ja
lighthouseを用いることで、これまで紹介してきたアクセシビリティやパフォーマンスといった項目がサイト上でどの程度実現出来ているかの測定が可能です。

Performance Budgetを知る

[46] https://developers-jp.googleblog.com/2019/03/blog-post_15.html
ウェブサイトを高速に保つための手法として、Performance Budgetの導入が推奨されています。
上記で紹介したlighthouseなどと組み合わせてCIに導入すると良い感じだと思います。

Webpackを知る

[47] https://webpack.js.org/guides/asset-management/
本来パフォーマンスの項目で紹介するものではありませんが、Webpackをちゃんと使うことでBundleサイズの削減、ひいてはパフォーマンスの向上が期待できます。
出来ることはたくさんありますが、tree-shakingとcode-splittingをまず検討しましょう。

Webpackは汎用的な知識ではないし、vue-cliやNuxtのAPIでラッパーすれば触らなくても良いんですが、
現時点では未だフロントエンドが頑張るべき分野かなと思っています。

アセット最適化を知る

[48]https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/automating-image-optimization/?hl=ja
画像はCDNから配信するのがスタンダードだし、じゃぁCDN上で画像の最適化をするのがベストプラクティスという話です。
Googleが開発しているモダンな画像フォーマットである、webpも紹介されています。

ここまでの総括として、サーバーレスを知る

[49] https://qiita.com/jshimazu/items/e102cde5124609384d0c
[50] https://inside.dmm.com/entry/2018/11/06/nuxt2-pwa-gae-se
これまでに話してきたことを詰め込んだような内容で、かつインフラのメンテコストを減らす形でサーバーレスのNetlifyやGAEを用いた構成です。

SSGやSSRをサーバーレスで動かすのは現代のベストプラクティスの一つだと確信しています。
※弊社では専門のインフラチームがいるため実際にPaaSなどのサーバーレスを採用するケースは少ないですが、多くのチーム・個人にとって有用だと思います。

さいごに

GoogleやAWSのインフラエンジニアの力を借りることが可能な現代で、
フロントエンドエンジニアは自分たちの力で良いWebサービスを実現できる存在だと思います。

知るべきことも、やるべきことも、山ほどありますが、
みんなでWebを少しでも良い世界にしていきましょう👏

suzu-4
好きなYouTuberは川口春奈です。
ユーザー登録して、Qiitaをもっと便利に使ってみませんか。
  1. あなたにマッチした記事をお届けします
    ユーザーやタグをフォローすることで、あなたが興味を持つ技術分野の情報をまとめてキャッチアップできます
  2. 便利な情報をあとで効率的に読み返せます
    気に入った記事を「ストック」することで、あとからすぐに検索できます
コメント
この記事にコメントはありません。
あなたもコメントしてみませんか :)
すでにアカウントを持っている方は
ユーザーは見つかりませんでした