[10年のツケを支払ったフロント界隈におけるJavaScript開発環境（2016年4月現在）。](http://d.hatena.ne.jp/tomoya/20160403/1459665374)

[日本のWebエンジニアの大半が、変化に対応しきれなくなっている件について。](http://d.hatena.ne.jp/tomoya/20160410/1460274822)

この辺のあれこれを読んで。

フロントエンド界隈の動き早い？ まあ早いですかね、確かに。
それは正直ブラウザというフロントエンド開発におけるOS的な位置付けのものが恐ろしい速度で更新されているし、JSの処理速度も互換性も向上したし、ブラウザ上でやろうとしていることがそれなりに複雑化多様化しているのでまあそうなるよね、と思いますが。

じゃあ、常に最先端をキャッチアップして導入していくべきかというと、んなこたーない。
Webデベロッパは、それぞれで取り組んでいるサイトの種類が違うので、最先端で流行っているからといってそれを導入しなくてはいけない、なんてことは全くないと思います。

たとえばWebサービス系などでSPAを作っている人にとっては有用ツールやライブラリ（だいたい今先端のほうで話題になってるのはこっち）も、広告系などでキャンペーンサイトを作っていて、毎回数ページ作りきったら次に行くような作り方をしている人にはあまり役に立たないでしょうし。

作っているものがそれぞれ違うのに、同じ最先端のツールを皆が使うべきなんてそんなことはあり得ません。それぞれがそれぞれ最適だと思うものを使えばいいと思います。

ただ、界隈で話題になるような、新しいライブラリやフレームワーク、記法やアイデアというのは、必ず**何かの問題を解消している**からこそ話題になっています。

その「解決している問題」がどういうものなのかだけは、把握しておいたほうがよいです。

Reactは一体どういう問題を解決して、何が改善するのか。
Webpackはどういう問題を解消して、他より何がよいのか。

たとえば前に「Promise」というのが一気に広まった時期がありましたが、あれは多数の非同期処理をするとコールバック地獄になって見通しの悪いコードになってしまうのを解消しました。
SassはCSSをDRYに書けない状況を改善したし、CoffeeScriptはJSをコンパクトに書けるようにしたり、thisやclassの問題を改善しました。jQueryも出てきた当時のブラウザごとの差異の大きな状況で本当にありがたいライブラリでしたし、jQueryプラグインの仕組みがたくさんのWeb制作者を救いました。

そういう、「何を解決して何をよくしているのか」という部分だけは、実際にコードを書いたり導入したりはしなくても、できるだけ把握しておいたほうがよいと思ってます。
なぜなら、Web開発者を続けていれば、どこかで同じ問題/課題に出くわす可能性も高いですし、そんな時、「ああ、これはあのフレームワーク/ライブラリが解決してたやつだ」という事がわかれば解決も早いし、設計段階でもよいツール選びができるからです。

テンマド社の場合だと、自分は先の記事にあがってるようなものはおおよそ把握しているつもりですが、一部を除いて導入してません。
[conasu](https://conasu.co/)はAngular＋Webpackだし、一番最近のものであるこの[mimemo](https://mimemo.io/)は全てjQueryなども使わずにほとんど素のJS（※ただしES6）で書いて、browserifyでまとめてます。他の受託案件ではjQuery＋jQueryプラグインなんていうのもいくらでもあります。それが作ろうとするものに対して最適だったからです。

使うべきツールは案件によってまったく様々です。
作りたいものに対して「最適」なものを選ぶためになるべく先端の情報にアンテナは立ててますが、先端であるとか、話題になっているとかいう事は、「最適」なものを選ぶ上で理由にはしません。

唯一、できるだけ先端方面にキャッチアップしていったほうがいい理由があるとすれば、jQueryプラグインをかつて作って公開していたような、有能なデベロッパの人たちはだいたい先端のほうに流れていくため、古い技術のほうはメンテされなくなりがち、みたいなことはありますが。（実際に最近、jQueryプラグインなどでメンテされなくなり更新が止まってしまっているものが多くなってきているのは肌感覚としてある

現場からは以上です！