2018年のJavascript考察

ここ1年半くらいで、業務やプライベートでJavaScriptに触れる機会が増えてきて、
少しはJavaScriptとその周辺は理解出来てきたかな~、という感じ。

自分向けの整理も含めて、最近のJavaScriptの状況を連々と。

1. ECMAScript
ECMAScriptはEcma Internationalによって標準化された仕様で、
JavaScriptはこの仕様に則ってブラウザエンジンに実装されている。

ECMAScriptの新しいバージョンは毎年6月にリリースされ、
ES2015(リリース年表記)、またはES6(バージョン表記)と表現されている。
2018年4月現在の最新は、去年6月のES2017(ES8)で、もうすぐES2018(ES9)をリリース。

モダンブラウザ(Chrome / FireFox / Edge等)は、大体の新機能が実装されるけれど、
IE等の古いブラウザは未対応のままなので、実装時はこのバージョンを意識する必要がある。

自分の所感としては、ES2015(ES6)での実装がいまのところは無難かな、というところ。
IEを範囲に含めるなら、ES5かな。
古いブラウザを使っている所も多くて、2018年現在もES5で書かざるを得ない事が多い…
(早くIE滅びないかな、と思っている人は多いはず)

2. フレームワーク
デファクト・スタンダードが無いので、どれを使えば良いのか迷いやすい。
自分が選定する時に考えているのは、下記の4点。

[1] アプリケーションの規模
 → 規模が小さいのにめっちゃ多機能なものを選んでも仕方ないし、
   規模が大きいのに機能が少ないのを選ぶとあとで死ぬ(気がする)

[2] 設計内容
 → 当然の要素なんだけれど、意外と詰められていないことがある。

[3] 開発期間
 → 新しいフレームワークを導入する時限定で、キャッチアップする時間を考慮したい。
   学習コストの高いフレームワークだと、恩恵をあまり受けられず、
   トータルの生産性が低くなってしまうことがある。

[4] プロジェクトメンバの習熟度
 → 経験年数、得意な技術は把握しておく。
   掛かる学習コストや受け入れる速度は、人によって違う。

で、実際にどれを使っていこうか、というお話。

■Angular
 学習コスト: めっちゃ高い
 アプリ規模: 大規模向け

 Google社製。1.x系と2.x系以降で、まったく別物のフレームワーク。
 どちらも学習コストがかなり高く、「とりあえず使おう」という感じではない。
 
 データバインディングという「ViewとComponentを結びつける」仕組みがあり、
 これによって、Viewの変化をComponentに即時反映、その逆も同様の機能を提供している。
 本来はサーバサイドで行われることの多い処理をフロントだけで完結させているので、
 サーバへの負荷軽減や、パフォーマンス向上に繋がっている。

 他にも、DI(依存性の注入)、サービス、コンポーネントなどの仕組みによって、
 大規模開発でも煩雑にならない(運用次第だけれど…)ようになっている。

 日本国内だと1.x系で開発しているプロダクトがかなり多くて、
 2.x系以降はまだまだという感じ。これから移行していくのだろうか。

■React.js
 学習コスト: 普通
 アプリ規模: 小規模~大規模

 Facebook社製。厳密にはフレームワークではなくて、ライブラリ。
 Viewに特化したライブラリで、UIコンポーネントを作り、それらを組み合わせて使う。

 React単体で使うことはあまり無くて、
 よく見る構成は、React + Redux(状態管理をするフレームワーク)かな。
 コンポーネントはViewに専念したいので、状態管理の部分を切り離してRedux任せる構成。

 JSXという文法を採用しており、JavaScriptの中にHTMLをゴリゴリ書く。
 この表現方法はかなり独特で賛否両論。自分はしっくりこない。

 初版リリースが2013年でかれこれ5年が経つけれど、根強い人気があり、
 フロントエンドの案件を見ていると、使っているプロダクトが多い。

■Vue.js
 学習コスト: 低い
 アプリ規模: 小規模~中規模

 Angularを軽量版みたいなフレームワーク。データバインディングに特化している。
 一応、MVVMなんだけれど、Viewに焦点が当てられているので、提供機能は少なめ。

 公式でも、足りない機能は他のフレームワークやライブラリで補完してね、
 というニュアンスの記述があるので、必要に応じて組み合わせていくことを想定している。

 学習コストが低いので、個人利用やスピード感を求める時には良いと思う。

■Riot.js
 学習コスト: 低い
 アプリ規模: 小規模

 とにかく軽量なフレームワーク。gzipでのサイズが10.71KB。Reactの1/3のサイズ。
 その分、提供されている機能も最小限なので、大規模なアプリケーションには向いていない。
 自分が知る限りでは、学習コストが最も低いフレームワークなので扱いやすい。

 カスタムタグと呼ばれる仕組みが特徴で、
 タグ(.tagファイル)の中にHTML、CSS、JavaScriptをまとめて記述する。

 自分が一押ししているフレームワークなんだけれど、
 これを使っている案件はほとんど無い。。。

他にも、Backbone.js、Knockout.js、D3.jsとか色々あるんだけれど、
とりあえずこのくらいかなぁ。

3. 周辺ツール
ぶっちゃけJavaScriptの闇だと思っている部分。
他の言語も似たようなものだけれど、JavaScriptは知っておいた方が良いものが特に多い。

■npm
 Node.jsをインストールすると一緒にくっついてくるパッケージ管理ツール。
 これ一つで開発環境を爆速で構築出来る凄いヤツ。
 package.json(またはpackage-lock.json)に依存関係の情報を保持している。

■Gulp
 タスクランナーの一つで、作業を自動化するためのツール。
 コンパイルやファイルの圧縮のように、ひとつひとつの作業は小さいけれど、
 これを毎回繰り返すとなると、チリツモで結構な時間を食われてしまうので、
 「じゃあ、こういう単純作業は自動化しよう」という感じ。

■Jasmine
 JavaScript向けに作られたテスティングフレームワーク。
 Karmaというテストランナーと組み合わせて、ユニットテスト実施によく使う。
 Angularのテスト標準としても採用されている。

■Babel
 トランスパイラと呼ばれるツールで、ES6以降の構文で記述したコードを、
 ES5に変換してくれるツール。Gulp等のタスクランナーと併せて使う事が多い。

■ESLint
 JavaScriptの静的検証ツール。
 構文エラーを事前に検出したり、チームで決めたコーディング規約を適用するのに用いる。

■webpack
 バンドルツール。
 開発していると、HTML、CSS、JavaScriptファイルを分割して管理することが多くて、
 完成した時には総ファイル数が100, 200…となっていることがある。
 すると、ユーザがアクセスした時にファイルの数だけリクエストを送る事になるので、
 これらを1つにまとめてくれるのがバンドルツールの役割。
 ちなみに、画像ファイルなどもまとめてくれる。

最低限レベルでもこのくらいある。。。
先日、Twitterでもぼんやり載せたんだけれど、Qiitaに、

2017年のフロントエンドエンジニアならこの程度は知ってて当然だよな?

という記事があって、本当に関連するものが多い。網羅するのはほぼ不可能。
なので、必要な時に必要なものをうまく吸収していくのが、いまのところは良い気がする。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

CAPTCHA