React を 4 年間使ってきた所感

2020-08-04

恒例のシリーズとなってきました、定期的に書きたくなるんですよね。

過去のやつも一応リンクをば。

React に対する感じ方は「React を 3 年間使ってきた所感」から特に変わっていないので、今回は切り口を少し変えてみようと思います。


roadmap 通りに勉強をすれば誰でもフロントエンドプログラマになれる

過去何度か書いてきましたが、Frontend Developer roadmap が良すぎます。

これからフロントエンドプログラマを目指される方は、この roadmap に沿って勉強することを強く推奨します。

パッと見覚えることが多そうに見えるのですが、推奨されている項目だけ勉強すれば大体大丈夫です。

おそらく最初から最後までずーっと大変だと思いますが、最短距離を突っ走れると思います。

roadmap 通りに勉強をすれば誰でも React を使いこなせれる

これも最近書きましたが、React Developer roadmap も最高です。

『React の勉強を始めるぞ!まずは Next.js からやろう!』みたいなバカげたことを言っている人がまだまだ少なくないですが、まずは深呼吸をして落ち着きましょう。

上記同様、roadmap に沿って勉強していくことがめっちゃ大切です。

特に Create React App の公式ドキュメントはおしゃれでシンプルでとてもわかりやすく書かれているので、なーんも迷うことがありません。

Next.js という選択肢の怖さ

ここ最近の日本ではやたら Next.js Next.js と耳にしますが、Next.js の優位性はやはりそこまで高くありません。

『Create React App って勉強用の環境であって、仕事では Next.js 一択でしょ』みたいな雰囲気をたまーに感じますが、全然そんなことないです。

と、これだけしつこく Next.js の優位性に対して文句を言うと勘違いされそうですが、自分自身 Next.js は結構好きです。

Create React App 以上に好き、というわけではないですが、バージョン 9.4 からガラッと良くなりましたよね。

SSR を含めた BFF の考え方もめちゃめちゃ面白いですし、全てのプロジェクトに導入したくなる気持ちはよーくわかります。

が、何度も書いてきましたが、SSR ってやっぱり難しいです、使いこなすのはやっぱり容易じゃないです。

SSG 周りも意外と引っかかることがありますし、Next.js 独自の仕様を把握するのも決して楽ではありません。

自分が Next.js をあまり推奨しない理由としては、とにかく日本の現場のフロントエンドの技術レベルに対してマッチしてないよね、というのが全てです。

Next.js をきちんと理解している人ほど「Next.js なんて簡単だよー」とおっしゃられている印象がありますが。

それはその人がきちんとフロントエンドの勉強を行ってきたからであって、きちんとフロントエンドの勉強をしていない人に対して、果たして本当に Next.js という選択肢を与えることが良いことなのか?

例えば「ルーティング周りが楽だから Next.js を選びました」みたいな話を聞くと、『え、Create React App でも別にルーティング楽だよ…?』と思っちゃうわけで。

Next.js が SSG にデフォルトで対応しているからルーティング周りが楽なわけですが、じゃあそれがどういう原理で実現されているのか、そこまで把握しておくことが重要なわけで。

『よくわからんけど動いた』という状態は裏を返せば、気づいていないうちに間違っていることをしているかもしれない、ということです。

プログラミング歴 0 の新卒社員が突然フロントエンドのプロジェクトに放り込まれるような状況が当たり前のように行われているこの国で。

Next.js とは、選択する必要がある場合に選択すべき選択肢であると、やはり思います。

もちろんこれは Next.js に限った話ではありません、Redux もそうですし、CSS Framework もそうです、なんでもそうです。

会社の方向性や現場の技術レベルに合わせた選択肢を取るということが、まずは何より大切だよなーと。

SSR を導入する前に、コンポーネント志向、スタイリング、Linter や Formatter、テストなどの理解はきちんと持ち合わせているのか?

ちゃんとしているところならなーんも問題ないと思います、ちゃんとしているか、そこが問題だよなーと常々感じています。

ちなみに

Create React App ではここ 2 年くらい?で設定周りが隠されるようになってきましたね。

eject しないと webpack や babel の設定周りが見えない仕様なのですが、そもそも eject が推奨されなくなりました。(だいぶ前からですが)

これはつまりどういうことかというと、プログラマに設定周りを触ってほしくないということに他ならないと思っていて。

webpack や babel のことまで完璧に把握しているプログラマって、そこまでいないと思うんですよね、正直自分もあまり強い分野ではないのですが。

以前のように、設定周りが大々的に公開されている状態だと、プログラマが安易に設定を書き換えてしまう恐れがあります。

事実、自分が過去に携わったプロジェクトでは、webpack の設定周りがカオスなことになっていました。

で、eject を行うと、Create React App に付随している(正しくは react-scripts) パッケージの更新がえぐいくらい辛くなります。

その結果、パッケージの更新についていけず、更新を諦めてしまい、プロジェクトが陳腐化する恐れがあります。

そういった状態を作らないようにするためにも、eject を推奨せず、react-scripts 一本で管理している状態なわけで。

プログラマ側からすれば、これってめっちゃありがたいですよね。

無駄にパッケージの更新を行う必要がなく、開発に集中できますし、時間も浮くわけで。

自分みたいに知識が中途半端なプログラマには本当にありがてーです。

CSR SSR SSG と React の付き合い方がほぼ理解できた、と思う

グローバルスタンダードな環境に限って分別してみると。

CSR

  • Create React App
  • Gatsby.js

SSR

  • Next.js

SSG

といった感じですかね。

たまーに誤解している人がいますが、Create React App も react-snap を導入すれば SSG が可能です。

Gatsby.js も好きではあるんですが、公式サイトがちょっと読みづらいのが難点だよなーと。

余談

React には関係ない部分もありますが…。

この 1 年である程度習得した技術

  • react hook form
  • craco
  • SSR
  • SSG
  • Next.js
  • GraphQL
  • Electron
  • PWA
  • GitHub Actions
  • Firebase(functions, Serve dynamic content)

このサイトのリニューアルとレシグルをリリースしたのが結構大きかったです。

どちらも仕事でないのが悲しい…。

これから勉強すること

  • Framer Motion
  • Electron
  • PWA
  • Cypress
  • Firebase
  • Figma
  • Stoplight

Firebase をもう少し使いこなしたいのと、もう少し PC アプリを作ってみたいです。

あと、世界的にそこまで GraphQL に移行している印象を受けないので、もう少し open api に強くなる必要があるなーと。

Framer Motion については今一番勉強している技術です、詳細は後日ブログに書く予定です。

シンプルイズベスト

フロント開発において、シンプルイズベストが本当に重要だなと、痛感しています。

知識が足りず、無意識のうちに余計なことをしてしまうことがフロント開発では多発します。

良かれと思ってやったことが最悪の結果を生んでいるなんてことが日常茶飯事、ザラに起きています。

しかもたちが悪いことに、知識を得ない限りその問題を解決することもできず、気づいたら手の施しようがない。

なのにそんな状態で賃金をもらうのって、果たしてどうなの?という。

なので、最近の開発ではとにかく余計なことをしないように注意深く開発をするようになりました。

シンプルイズベスト、良い言葉です。


そんな感じです。

色々と苦しんでいるここ 1 年ですが、これからも苦しむのか、それとも光明が見えてくるのか、自分にもまだまだわかりません。

ひとまず、何があろうとも少なくともプライベートでは勉強し続けていこうとは思っていますが、果たしてー。

© 2018 kk-web