saino.me (kaishuu0123)

都内でひっそりと生きる IT エンジニアの個人ブログです

無理に SPA にしなくてもいいんじゃない?(最近のフロントエンドについて)

最近色々気づきがあったので memo

書いている人の前提

  • Ruby on Rails エンジニア (webpacker 利用経験あり)
  • webpack もわかる
  • react, Angular, Vue.js 触ったことある
  • css 周り(scss がメイン)

思ったこと

上記の通りなんだけど、結論から書くと「新規で作るプロジェクトを無理して SPA にしなくてもいいんじゃないか。」という意見。

HTML への binding をしやすいという意味で jQuery は流行ったわけだし、react, Vue.js は jQuery の次のステップという意味でわかりやすい

Angular は SPA に特化しているイメージがあって、DI、Service 層など独自の概念が構築されていて、初期学習コストは高いかもしれないけど、恐らく SPA でエイヤと作るにはとても作りやすい (react とかで API 叩く層を作るとなると、redux-saga とかライブラリ選定から始まってしまう)

と考えると、採用技術は用途によって異なるわけだけど、恐らくまだまだ MPA(Multi Page Application: SPA の逆で従来の MVC フレームワーク(Rails とか)で実現している)が活躍しそうだと思っている。

せっかく Model を定義して、テンプレートエンジンに食わせて、 HTML を吐き出せるようにしているのに、わざわざ API を生やして、フロントエンド用にまたモデルを定義する意義、というのは有ることは理解できる、が、恐らく小さく始めるプロジェクトだと仰々しすぎる節がある。

じゃぁ、フロントエンド、バックエンドを分けるメリットを考えてみると、圧倒的にスケーラビリティという点で軍配が上がるし、責任分界点という意味でもチーム開発しやすい、という点もある。

逆にフロントエンドを SPA にするデメリットもあると思っていて、SSR 対応するときにめっちゃ辛い。Google さんから正しくレンダリングしてもらうためには、結局地道にページビューを確認していく作業が漏れなくついてくる(SSR 対応やった身からすると)

逆にフロント/バックエンドを分けないメリットを言えば、手元に一つの環境(MVC フレームワークが動作する環境)があれば、手軽に試すことができるという点。SSR を考えなくてもいい(かもしれない)という点。

分けないデメリットは、JS コードがスパゲッティになりがちになる。従来の jQuery を使った方法を取ると、あっという間に「どの JS がどの DOM をいじっているかわからん(´・ω・`)」となり得る。

けど、そういう場合って SPA でも同様のことが起きる可能性があると思っていて、結局は SPA/MPA での土俵で語ることではないと考えている

個人的にはプロジェクトは軽いところから、段々とスケールさせる方向に持っていく方が好みなんだけど、「最初からフロント、バックエンドが分離されていてよかったー!」という成功例も見てみたい。