フロントエンドの必要性について

Question

フロントエンドの必要性がよく理解できません。

Python(flask)やRuby(Ruby on Rails)などでWebアプリを開発してきました。ですが、その間、一度もフロントエンド（javascript)の需要を感じませんでした。

一体、いつ、どのように必要に迫られるのでしょうか？

決して、フロントエンドをdisるわけではないです。

むしろ、Node.jsが登場して、フロントもバッグもjavascriptで書けると知って、すごく興味があります。

ただ、React.jsやAngularを使ってまで（勉強してまで）、フロンド側に何か処理をさせなければならないのでしょうか？アクションごとにページ遷移してはいけないのでしょうか？

React.js, Angular, Vue.js, jQueryとさまざまなフレームワーク？ライブラリ？がありますが、どう使い分けるのでしょうか？そもそも、それらに頼るときとは、どのようなときなのでしょうか？

追記
回答ありがとうございました。こんなにたくさんの回答が得られるとは思っていませんでした。
非同期通信の例をきいて、なるほどと思いました。
本当に、ありがとうございました。

Answer 1

一体、いつ、どのように必要に迫られるのでしょうか？

その感想も至極真っ当であり、必要か否かでいえば必ずしも必要ではないといった類のものです。
それを証拠にJSが出現した最初期のWebでは、ブラウザをチカチカ光らせるしか能のない害悪な存在という評価であり、パソコンの書籍で「まずJSの動作を拒否にする設定に変更しましょう」などと書かれてしまっていた程です。

JSが有用である事が証明されたのはGoogleマップ(2003年〜)やスプレッドシート等のアプリですね。
今では多くのサイトの裏で縁の下の力持ち的な活躍をしており、例えばTwitterの画面下までスクロールすると少しずつ読み込んでくれる機能みたいな箇所もJSのおかげで動いています。

Googleマップのドラッグで直感的に操作出来るUIや、GoogleスプレッドシートのようなUIは、
サーバーサイドの開発のみでは実現できません。
文字入力する度にリロードされてフォーカスが消し飛ぶスプレッドシートとか使ってられないですね。

このようにユーザーの利便性を考えた場合、
JSを利用したページ更新処理を挟む事なく、ダイナミックに画面が切り替わる機能として受け入れられています。

---

React.js, Angular, Vue.js, jQuery

jQuery(2006年〜)は当時のJSがあまりにへぼかったので作られたライブラリです
例えばJSは単独でHTMLのDOMツリーを変更することはできません。
各ブラウザが実装しているDOMのAPIのメソッドを叩いて変更を呼びかける必要があるのですが、実装されているメソッド名や使い方がブラウザ毎にまちまちで、当時のフロントエンドエンジニア達が発狂して死ぬという事がよく発生していました。

jQueryはどのブラウザでも同じように扱えるメソッド群を提供しました。
jQueryの内部がIEならこのメソッド、Chromeならこのメソッド…という風に頑張って仕分けてくれるので、
やりたい事の多くはjQueryが用意しているメソッドを叩くだけで実現できます。

しかもメソッドや書き方も簡潔で分かりやすく爆発的に普及しました。
今はJSのバージョンが進み、また各社のブラウザの機能も足並みが揃いましたので、
「あれば便利だけどなくても別にいいや」程度のライブラリとしての立ち位置です。

---

React.js、Angular、Vue.jsは全て作っているチームが違う別フレームワークですが、思想は一緒です。
その思想は、自分でDOMを更新したくないというものです。

JSフレームワークの使い方は、
JSフレームワークに「HTMLの元になるテンプレート」と「監視する変数」をセットで渡してやります。
そうすると、特定のDOMツリー配下であるように振る舞い、監視対象の変数の値が切り替わった瞬間にDOMが最新の状態に更新されます。

「オブザーバーパターン」とか、「データバインディング」と呼ばれる手法です。
これにより、jQueryで開発していた頃は手動で行ったDOM更新がテンプレートに従った自動更新により、
高度で複雑なWebアプリが簡単に開発出来るようになりました。

---

どう使い分けるのでしょうか？

jQueryはメソッドが身近になっただけで、手作業でDOM更新するものです。
そのjQueryの思想とは真っ向から衝突するのでJSフレームワークを入れる場合はjQueryでDOM操作はしてはいけません。

ではどう使い分けるのか？
これは規模的に自力でDOM更新のコードを書けるか否かで考えましょう。

JSフレームワークを選んだ場合、内部で色々とコンパイルしたりすることになるので実装が大掛かりになりがちです。
ちょっとした処理だからDOM更新するコードを自分で書くわってケースではjQueryを選択しても良いでしょう。

---

どのJSフレームワークを選べばいい？

好みやQiitaの記事数などなど…適当な理由で決めても構いません。
あえておすすめを挙げるなら、最も簡単に試せるVue.jsですかね？
まぁ思想は同じなんで、React.jsやAngularを使っているプロジェクトに後からジョインしてもそんなに苦しむことは無いと思います。

また、別々のJSフレームワーク同士を併用するメリットは特にありませんが、
入れ子にしない限り干渉する事もないので、
ヘッダー部分はAngularで作って、このページの表の中身はReactで作るといった使い分けも可能です。

大昔にAngularJSで作ったサイトをVue.jsでリプレイスする時とかに役に立つかと思います。

Comments

[yambejp]

>JSが有用である事が証明されたのはGoogleマップ(2003年〜)やスプレッドシート等のアプリ

いやそれは言いすぎでしょう。
ajaxの有用性という意味ではそうかもしれませんが。
jsの有用性はネットスケープに実装された当初から評価されています
とくに当初はalert、confirm、promptなどUIの部分と
cookieなどデータ保持については活躍していました

[len_souko]

Googleマップが来る前は正直JavaScriptはOFFにするのが常識って感じだったので、こいつのおかげでJavaScriptがまともに利用できる環境が整い始めたような雰囲気でしたよ
なんせそれまではマウスポインタの後をついてくる謎の鎖だとかポインタを十字にしまくってドコがリンクかわからなくなるとか、Aドライブを参照する別窓をひたすら開くとか、コピーしようとしたら右クリック禁止ってアラート出してくるとか、基本迷惑なものがほとんどだったので
便利な時代になったものです

[miyabi-sun]

https://qiita.com/a_rcsin/items/0a3c8c98c8d703c49a22
GoogleMAPの裏で通信する技術Ajaxが名付けられるまでは主流はどう見てもCGIとFlashです
挙げているalertやconfirmは、form作ってCGIで受けた方がよほど良いです。
RO等のネットゲーム計算機として細々とした活用はされていましたが、基本的にはOFFにして運用すべきものでしたね。
Cookieでゲームキャラのデータを保存するのが最も有効活用された例でしょうか…

またFirefox4が登場してJSエンジンが一新されて、他のブラウザに勝利宣言し始めたのが2010年です。
本気を出したChrome勢にあっという間に追いつかれますが…
ちなみにMSもIE9以降、登場時点ではこれらのブラウザに匹敵するエンジン積んでます。

またデベロッパーツールやconsole.logなどという軟弱な機能もなく、
全てalertで出してOKを連打しまくるという非効率極まりない開発が一般的でした。
とくに2000年より前は悲惨な状況で、流行る要素はありません。

> len_soukoさん
懐かしいです。
私が覚えているのはウィンドウのサイズを調整したり座標を指定出来るので、
小さい窓がマウスを避けたりsinやcosを併用して画面上を円状に飛び回るスクリプトが書けましたね。
海外のサイトはページを✕ボタンで抜けようとすると、同じページが10個立ち上がったりしましたね。

Answer 2

そもそもなんで ajax がもてはやされたか、というと、「画面遷移せずに画面を変更できる」ことが非常に有効だったからです。
情報提供系の画面の場合、なるべくリアルタイムの情報を提示する必要が出てきます。ということは、定期的に画面を更新してやらねばなりません。
※teratail も質問一覧を表示してると、上部のタブ部分には定期的に更新かかりますね

ですがアクション毎にページ遷移をすると言うことは、「書き換える必要のないところまで再度描画する」ことになってしまい、レスポンスが低下しますし、見栄えも悪くなります（一度真っ白になりますから）。そこに　ajax を使うことで、「非同期に、必要なところだけを書き換える」ことができるようになり、大いにもてはやされるようになりました。
結果的にフロントエンド側に「情報更新の処理」が多く入るようになってきたわけです。

Answer 3

JavaScriptない縛り

自前でGoogle Mapを作らなきゃならなくなった時困ると思います。

フレームワークを使うこと自体

必要に迫られる可能性は結構あります。大きいの作り始めると「DOMとデータをうまく扱いたい！」「いちいちgetElementById()とかやってたらわけわかんなくなってバグる！」となるからです。
ただ挙げられた中でjQueryは、0からやるなら最近では頼らずともよいでしょう。でも頼らざるを得なかった時代（ブラウザがみんなそっぽ向き合ってた時代）から受け継がれる人材・システムと会話するためにまだまだ必要かもしれません。

各フレームワークの使い分け

これは難しい。普通の人はもはや出会い運でしかないと、私は思ってます。
すべて試して特徴を把握して選ぶのが大事だけど、その作業は本当に好きじゃないと難しい。上司に言われて自己啓発でやるという形では、間違いなく精神を病みますね。

私の感想

私はフロントエンドに入ってまだ数年ですが、本当に狂詩曲という感じです。なんというか、古めの偉い人には「画面に出すだけでしょ」と軽んじられながら、若めの偉い人には「VueのSFCでTSでBabelでwebpackがGulpで」とマウントされ、実際に作るとじゃあ結局環境構築はどうすりゃいいの！？この情報のnpmバージョン古い！このコンフィグファイルはどの奴のあれやねん！とかなってもう毎日がエブリデイです。

でも「あー、これだから便利っつー話しなのか」ってこともままあって、それはそれでなるほどな、という感じですね。

ただやっぱりフレームワークとかはあくまで「道具」なので、道具に振り回されるのは避けたいですね。そういう意味では、使う必要も意味も感じなければ、手を出さないので正解だと思います。転職したい場合は、本末を転倒させる必要はあると思いますが。

Answer 4

長く語るのは好みでないのでざっくり答えます．

どのように必要に迫られるのでしょうか？

必須ではないですが，ユーザの使いやすさ・気持ちよさが向上するからです．

更に， そもそも今後は必須 な場面が増えるはずです．
なぜなら，FirebaseなどのmBaaSを採用するような，バックエンドの開発がない場合が増えるからです．

フレームワーク？ライブラリ？

React.js　→　カッチリしてる，理想を求めすぎ
Angular　→　何でも屋，大きすぎ
Vue.js　→　実用派，独特の癖
jQuery　→　ネットの情報多い，古典的おもちゃ

Answer 5

ドラゴンボールでの "身勝手の極意" みたいなもんです。

サーバー側(頭)で判断するのではなく、端末側(体)が勝手に動くのです。

１００万台の端末の除道をすべてサーバーで行うより、ある程度のことは端末側だけで処理をしてしまうようにすれば、いろいろと便利です。
サーバーの負担が減る、ネット接続が不調でも、端末側がだけで画面変更ができる ...

あくまでも雰囲気を伝えるだけのたとえ話なので、厳密に "身勝手の極意" との類似や差異を突き詰めてツッコミを入れないでいただければ幸いです)

Answer 6

どんな不都合があるか試してみては？
各ブラウザでJavaScriptを無効にする

Answer 7

作る側やシステム管理者側の立場の問題で、エンドユーザからしてみればあまり意味ないかもしれません。

自分のパソコンで自由に使うことができるならば必要性は薄いです。ただ、例えば会社のパソコンの場合は内部規則で自由が利かないことも多々ありえます。

ブラウザアプリを例に説明します。windowsなどのデファクトスタンダードパソコンの基本機能だけで動かせるプログラ厶を作れば互換性が高くなります。そうなると魅力的なものはインターネットエクスプローラなどのブラウザです。ブラウザならば、ネットワーク機能とユーザインタフェースがある程度期待できます。したがって、ブラウザを経由すれば互換性の高いプログラ厶を作れるといえます。このガワとなるのがフロントエンドプログラ厶です。

もっとも、現在はブラウザなしでも、javascript動きますけどね。スマホでも動かせるのは魅力的です。