1. Qiita
  2. 投稿
  3. JavaScript

あのライブラリは何故誕生したの?のまとめ

  • 1094
    いいね
  • 1
    コメント

はじめに

最近、フロントエンドのライブラリ乱立問題について盛り上がってました。
自分はnobkzさんの以下の文に全てがまとまっていると思います。

僕の最初の違和感は、「技術的な流行り」に乗ることに何の価値があるのだろうか?ということである。もちろん、最新のツールやフレームワークはより何かが良くなってるかもしれない。しかし、 それをあなたのプロジェクトで採用するには何の価値があるだろうか?

「最近のフロントエンドへの違和感 - nobkzのブログ」より

裏を返せば、新しいライブラリの内容、特に「どのような問題を解決するためにこのライブラリが生まれたのか」という思想を把握しておくことは重要だと言えます。

つまりは、

"How?(ライブラリの使い方)" よりも "Why?(なぜそのライブラリが必要なのか)" を学んでおこう

ということです。この記事では

  • どのような既存の問題・要求を
  • どう解決してくれるのか

をまとめました。

React

既存の問題・要求 どう解決してくれるのか
SPAでは、データバインドが煩雑になり、UI構築が大変。 表示すべき内容をHTMLのように(JSXで)宣言的に書けば良くなった
HTMLの標準機能ではコンポーネントの再利用ができない コンポーネントの再利用を可能にした
SPAでは、表示内容を更新すべき部分を全てクライアント側で計算しなければならない 全体を再描画するようなリクエストを投げても、本当に更新が必要な部分(差分)を自動的に計算してくれるので、無駄なく高速に画面更新ができる。

参考: Why React? | React

Fluxアーキテクチャ

既存の問題・要求 どう解決してくれるのか
MVCで役割を分担しても、各々が密に連携するため、結局、設計が複雑になる 連携の方向を一方向に限定して、設計を単純化した

参考: Flux | Application Architecture for Building User Interfaces

Redux

既存の問題・要求 どう解決してくれるのか
SPAでは一つのサイトが管理しなければならない「状態(state)」が複雑。
状態遷移(mutation)と非同期性(asynchronicity)を同時に扱おうとすると闇。人間には理解しづらくなる。 状態遷移を、人間に理解・定義しやすくした((oldState, action) => newStateという関数で状態遷移を表現した。)

参考: Motivation | Redux

react-router

既存の問題・要求 どう解決してくれるのか
SPAの場合、クライアントサイドでルーティングする必要がある ルーティング機能を提供した
Reactの強みの一つ「サーバーサイドレンダリング」がクライアントサイドルーターが邪魔でできない サーバーサイドレンダリングに対応した。

Reactのコンポーネントとして構成されたルーターなので、当然Reactと相性が良いです。
また、サーバーサイドレンダリングにも対応しており、Reactの強みを十分に活かすことができます。

material-ui

既存の問題・要求 どう解決してくれるのか
MaterialUIを使いたいが実装が大変 MaterialUIを実装したReactコンポーネントを提供した

Reactの再利用性を活かしています。
もちろん、同様のライブラリは Angular Materialなどのように各コンポーネントライブラリ毎に存在しています。

ES2015

既存の問題・要求  どう解決してくれるのか
jQueryやunderscoreなど、様々なユーティリティライブラリで補強してきたが、無駄に依存性を増やしたくない いろんな機能をブラウザ標準で提供した
ライブラリだと遅い ブラウザネイティブ実装なので速い
クラス継承機能欲しい。オレオレ実装辛い。 class構文
非同期処理めんどくさい。jQuery.Deferred! Promise
関数にデフォルト引数設定したい デフォルト引数対応
その他たくさんの要望 要望に答えた!

おもに機能面での大きな改善が見られました。ちなみにclass構文に関しては既存のprototypeベースのオブジェクト指向を壊すものだとも言われており賛否両論です。

Babel

既存の問題・要求 どう解決してくれるのか
ES2015使いたいけど対応ブラウザ少ない ES2015で書いたコードをES5以前に変換してくれる
jsxで書かれたコードは一旦jsに変換しないといけない Babelが直接jsxをサポートした

Browserify

既存の問題・要求 どう解決してくれるのか
Node.js向けに書いたコードをブラウザでも動かしたい Node.js標準ライブラリのブラウザ版実装を提供
Node.jsではrequireによるライブラリ読み込みが基本だが、複数のjsファイルを別々に読み込むと、リクエストが多発して遅い jsファイルを一つにまとめてくれる
フロントエンドのJavaScriptはコードの肥大化とともに変更がもたらす影響を追いにくくなる jQueryなど既存のモジュールをnpmパッケージ化することで完全な CommonJS module 化を実現するとともに、フロントエンドのコードでも関心の分離を実現

webpack

既存の問題・要求 どう解決してくれるのか
jsファイルのモジュール読み込み方法が乱立しすぎ。 全部一つのjsファイルにまとめました。
jsファイル以外にもまとめちゃえばもっと読み込み早くなるのでは? 画像もcssもjsも1つのファイルにまとめました。

webpackでdevserverとかの機能が提供されるようになった理由はなぜなんでしょう。
個人的には、ツールの肥大化を招き、学習コストを増加させるだけなので切り分けたほうがいいのではと思います。

ESLint

既存の問題・要求 どう解決してくれるのか
コードスタイルや静的に検査可能なエラーを見つけたい lint
JSは過渡期にあり、古いルールが不要なエラーを検出してしまうことがある 高いカスタマイズ性を提供

Airbnb JavaScript Style Guide

既存の問題・要求 どう解決してくれるのか
開発チーム内でコードスタイルを統一したい スタイルガイドを定義
JSは過渡期にあり、有名ドコロのスタイルガイドは大抵新しい文法に対応してない 新しい文法に対応

ひとまず、10年のツケを支払ったフロント界隈におけるJavaScript開発環境(2016年4月現在)。 - 日々、とんは語る。にて紹介されたライブラリやツールなどについてまとめました。加筆・修正等あれば編集リクエストを頂ければ幸いです。

参考