idkqh7の研究日誌

基本は翻訳。{セキュリティ|プログラミング|バイオインフォマティクス|数学}について。

最近のWeb技術動向についてまとめる

はじめに

世はWeb戦国時代！ ……分からなすぎてツライ。

結論

目的にあったフレームワークを使うべし。 SPAのフレームワークとして、Railsはオススメしない。

【5月31日追記】

ただ、ActiveRecord使いたい人はRails使ったほうが良い（WebAPIサーバとして）

キーワード

Web戦国時代におけるそもそも論

【開発言語による派閥】

老害とマイノリティには辛い世界だぜﾋｬｯﾊｰ

今回は、Node衆とLL衆（特にRails）を対象にする。

Q.そもそもJavaScriptでモダンな開発とか無理じゃない？
A.ECMAScript 6で、classとimportがとうとう追加。ﾜﾝﾁｬﾝｱﾙｯｼｮ

【JavaScript Webフレームワークについて】

「できること増えたしNode.jsあるし、もうJavaScriptだけでいいよね」　→　AngularJS

PhantomJSなどでサーバサイトから静的なページを返せない限りSEO的にはツライ。 ただ、開発言語をフロントエンドで統一できるようになった。

【Webページのはやり】

SPA(Single Page Application)

1ページで完結したWebアプリケーション。

「ああ、でっかいFlashが1個乗ってるだけのサイトあったなぁ……」

↑見た目はまさしくこれ。JavaScriptで同じ歴史を繰り返している。 なお、「SEO的にどうよ？」っていうだいぶ昔に見た議論が繰り返されている模様。

【SPAを実現するために】

jQueryでDOM書き換えまくりとか死ぬ

「VirtualDOM（差分更新）でなんとかしよう！！！」　→　React.js

救世主登場。SPA時代突入。当然、SPAは静的ページではないのでSEO的にツライ。 更に「最初のアクセスはサーバサイドレンダリング、そのあとのページ遷移はSPA」みたいなものまで現れている。

俗にいう、Isomorphicみたいな感じのヤツですねホント。

「なんか見たことあるぞ」という人、そうですMeteorですね。時代がやっと2012年に戻った。ファッ！？！？！？！？！

※引用の引用でMetor（Isomorphicな開発環境）が求められる背景を抜粋

  • 普通のWebでは状態が画面遷移でリセットされてしまうことが辛い
  • バリデーションをフロントエンド・バックエンドの両方で実装しなければならない
  • フロントエンドだけのスキルでは不十分。バックエンドの実装が特に面倒くさい。
  • フロントエンド・バックエンドを別々に勉強するのではなく、同時に作っていくイメージで開発したい

ぶいてく: IsomorphicとAPIファーストについて #apijp

【開発手法について】

どんなに頑張っても、サーバサイドから分離できないビジネスロジックがある。そんなものを無理にIsomorphicにすべきじゃないよね。

「じゃあ、サーバでよく使う機能をAPI化すればフロントエンドの変更にも対応できるし、バックエンド資源も再利用できて嬉しいよね！！！」

フロントエンドとバックエンドを分けて開発しよう！！

何年戻る気だ。

フロントエンドとバックエンド

というわけで話は現代へ。

最近よく見るSPAの構成で

  • フロントエンド : AngularJS
  • バックエンド : Ruby on Rails

という構成がある。「そこまでしてRails使いたいか」と思ったのは俺だけではなかった。

www.reddit.com

結論から言えば「イケてる機能使わないとか損でしょ」という感じだが、SPAの構成として勧めるべきかといわれると悩む。MVCフレームワークとは何だったのか。

「なんでもできるフレームワーク」は「何していいか分かんない」

正直、バックエンド用途として使う分には重厚長大すぎる感じがする。喩えるならば、豚も鳥も魚もブチ込んだラーメンのスープ。

つまり、Go言語の時代が来たということだ。

最近のWeb技術動向まとめ

基本的には、テストのしやすさが一番大事。「フレームワークinフレームワーク」の構成は個人的に微妙。

【SPAを作りたい！】

【SPAでLLなフレームワーク使いたい！】

  • フレームワークである以上、想定されてない用途には不向き
  • AngularJSと混合した状態でのテストは難しそう？
  • bowerもgruntも使えるがメリットはあるのか。使ったほうが管理しやすいか。
  • turbolink(ajax)はSPAに必要ない（DOMを書き換えるので）
  • asset pipelineも代用品はある。
  • SPAじゃない方がSEO的に良いと開き直る
  • javaScriptを無効にしても開けるページが正義だと信じる

Javascriptが嫌い？　それならDart（なぜか途切れている）

コメントへの補足と回答【5月31日追記】

本記事でいう、「フレームワークinフレームワーク」とは、コメントにあるRailsのビューとAngularのテンプレートが一体になっているヤツです。 正直、これは非常に管理コストが高いと思います。茨の道へGo！

「RailsはWebAPIを実装するフレームワークとして有用」

「バックエンドにRailsを使うべきか？」という件ですが、個人的にもActiveRecordはかなり有用だと思っていて、無理やり他のものを使うくらいなら、RailsでさっさとWebAPIの実装をすべきです。

他にも開発実績、慣れやノウハウがあるという点も多くの個人や会社にとって事実ですし、経験者であればJSONを返すものくらいちゃちゃっと作れます。 しかし、「これRails使う必要ないでしょ」と思う実装もかなり散見します。（具体的にいうとヤバそうですが……）

ほとんどコメントされた方と同意見なので、わざわざ繰り返すことでもないんですが「なんでもできるから、とりあえず使っておけ」という風潮を非常に危惧しています。 例として上げた「SPAじゃない方がSEO的に良いと開き直る」というのは本質的な問題で、フレームワークとしてのRailsについて考えたとき、

「SPAじゃないけど、Railsで完結」　vs 「SPAなので、Railsで完結しない」

となると、前者の方が圧倒的に作りやすいです。後者においてもRailsを使う利点は当然残りますが、前者に比べると「ぐぬぬ」感を味わうことが多いです。

「そもそもバックエンドでRails使うなら、SPA以外の選択肢も検討すべし」

というのが、Railsというフレームワークにおける最適解なのではないのかと個人的に思っています。

追記のまとめ

  • 「バックエンドにRailsは有用だと思うか？」→有用だと思う
  • 「バックエンドにRailsはオススメできるか？」→使っても良いが、ActiveRecord使わないならオススメしない。まずはSPAを辞めることを検討。

他がうんこ Railsの完成度が非常に高いので、このような回答になってしまいましたが……「エンジニアの仕事も超できる部下に営業ばかりをやらせる上司」みたいなやり方は「確かにそれもありっちゃありだけどさー」みたいな感じです。

フレームワークを選ぶときは「やりたいこと」「できること」「実現する方法」「適切な分担」についてしっかり考えましょうという話でした。おしり。