読者です 読者をやめる 読者になる 読者になる

たなかこういちの資料室

システム開発に携わる筆者があれこれ試したことや学んだことについてのまとめ

非フロントエンジニア向け、JavaScript事情(2015年12月現在)

JavaScript Backbone.js JavaScriptにおけるモジュール
業務上の必要より、今時のJavaScript界隈の状況をサーベイしました。(※調査実施日は2015年12月中旬)
 
 
paiza開発日誌、「Backbone.JSからAngular2まで、全9大JavaScriptフレームワークを書き比べた!」:
 
自分がJSフレームワークに求めているのは下記3点です。
 
(1-1) HTML側で宣言的に行えるmodel-view binding(※必須)
(1-2) bindingしたmodelのデータに基づいて駆動されるHTMLテンプレート(※必須)
(2) よって、MVCよりもMVVM
(3) model-ajax連携があれば尚可
 
この指向もしくは嗜好に対してVueが一番フィットしそうです。VueのHTMLでの宣言は十分にコンパクト。
 
Angularは、求めるものに対してまだ複雑さが残る、controllerがリッチすぎる。
 
Backboneは、一番欲しいrenderingやHTMLテンプレートについて、直接のサポートは無かったんですね。むしろrendering engineやmodel-view bindingを自分で構築しようというときの下地にするようなものです。
 
Vue.jsについて
 
Vue.js公式:
 
Vue側の見解です。
 
Vue.js公式、「他のフレームワークとの比較」:
 
 
自分も過去のプロジェクトで宣言的自動データバインディングを行う仕掛けを作ってきたことがあって、宣言的自動データバインディングを行うには、Modelとするデータは、
 
(a) Observable的なものにくるむ
(b) setter/getterのフックをprototypeいじって差し込む
 
以上のいずれかの扱いをする必要があると理解しています。
 
Vueは、“Plain JS Object”をmodelとして用いることができます。それはつまり(b)をしていることを示唆します。実際そうであるようです。ここは要注意点ですね。
 
ブログ「てっく煮ブログ」、「Vue.jsがdataに渡した値を激しく書き換える件について」:
 
Vue公式では、"Vue.js will recursively convert its properties into getter/setters to make it “reactive”. The object must be plain"と云っていました。
 
Vue.js公式、"Options / Data":
 
Backbone.jsについて
 
Backbone自体はあくまでほんとうに下地であって、Backboneを導入したからといって、直ちに何かが一気に解決するというものでは無いようです。本当に背骨だけ。
 
Backboneプログラミングの解説記事をブックマーク。
 
Developers AppKitBox、Knowledge Note、「試して学ぶBackbone.js入門4」:
 
Underscore.jsについて
 
実はBackboneと同じ作者が提供するUnderscore.jsが、ユーティリティとしてなかなか秀逸そうです。下記公式ページに列挙される関数群を一瞥しておきましょう。
 
Underscore.js公式
 
特に、Underscoreの関数を使っていれば、JSの生のArrayとBackboneのCollectionを多分透過的に扱えます。BackboneのCollectionには、Underscoreの“Collection系関数”とセマンティクスとして互換性のあるメソッドが一揃え用意されています。
 
Backboneにおけるデータバインディング
 
Backboneでデータバインディングを行う方法の議論がありました。
 
stackoverflow、"Can I bind form inputs to models in Backbone.js without manually tracking blur events?":
 
いくつかPlug-inが存在するようです。
 
Backbone.ModelBinder:
 
概要から引用すると"Simple, flexible and powerful Model-View binding for Backbone."とのこと。
 
データバインディングでは無いですが、"A plugin to create entire Document structures with nested Backbone.js Models & Collections with deep model references and event bubbling."だというPlug-inも見つけました。ブックマークしておきます。
 
Backbone.DocumentModel:
 
HTML5の<template>タグ
 
HTML 5に<template>というタグが導入されていました。もう「<script type="text/template"></script>」などと書かない、ってことです。
 
HTML5 Rocks、「HTMLで利用可能になったTemplateタグ」:
 
ハンドリングするコードを実地に書いてみましたが、ちょっと一癖ありました。(※別記事で解説してみます。)
 
ES7あたりで導入のObject.observe()
 
同じく「HTML5 Rocks」にこんな記事が。もうObservableかsetter/getterフックかで悩まなくてよい!
 
HTML5 Rocks、「Object.observe()でデータバインディング革命」:
 
ES6
 
ES6に関する2つの見解を見つけました。
 
ブラウザーにおける実装状況、そしてサポートしなければならないブラウザーの“寿命”を鑑みるに、まだ早いという意見。
 
ブログ「None is None is None」、「ECMAScript6を使うのは5年ぐらい時期尚早だった」:
 
「6to5トランスパイラー」前提に、もう移行してしまおうという意見。
 
ブログ「ハブろぐ」、「もうES6 (ES2015)でいいんじゃないか」:
 
ES6に進むのは、アーリーアダプター・ターゲットなら着手してよし、マジョリティ・ターゲットなら今日明日のプロダクション向けとしては難しい、という判断かと思いました。
 
JSにおける「モジュール」
 
“モダン”JSは「モジュール」を意識して書くべきであり、またモジュール管理のメカニズムのデファクト標準もいくつかあるのですね。
 
Qiita、「JavaScriptのモジュールの書き方」:
 
Qiita、「最近の行儀のよいJavaScriptの書き方」:
 
モジュールおよびモジュール管理に関する要件は次のようにまとめられるでしょうか。
 
・モジュールのprivateな要素がglobalな名前空間に露出しないように、モジュール自体のコーディング方法に制約を課す。
・モジュール利用側が統一的手順でモジュールをimportできるように、モジュールがpublicな要素をglobalな名前空間にexportするときの、標準的な名前空間管理機構を提供する。
・モジュールが、ブラウザー、Node.js(※サーバーサイド)、その他実行環境の違いがあっても動作するようにする。
・モジュール管理のメカニズム自体に複数デファクト標準がある。モジュールは可能な限りいずれのモジュール管理メカニズムにも対応するようにする。
 
 
JSモジュールのテンプレートを作ってみました。
 
logger.js:
 
モジュールのprivate空間とpublicにexportする部分とを分別した記述方法についてのテンプレートとなっています。「複数のモジュール管理メカニズムに対応すること」、「export手続き周りを一般化すること」はサボっています。
 
このテンプレートは、ちょっとしたLoggerモジュールとしてこのまま使えます。(※ブラウザーFirefox)でのみ動作確認しています。)
 
◆以上