javascriptについて社内で説明した資料になります

1. クライアントサイド
javascript簡単紹介 しくみ製作所(株) 車 拓哉

2. 目次
• javascriptを取り巻く環境
• javascriptの言語的特徴
• クライアントサイドjavascriptのコーディング
• 実用に向けてのライブラリ紹介
• まとめ

3. javascriptを取り巻く環境
歴史や実行環境など

4. 超簡単な歴史
• JavaScriptはネットスケープのブレンダン・アイクによって開発され、Netscape 2.0で実装された。開発は
超短期で行われ、設計者も「もう少し時間をくれればもっと良い設計にしたのに・・・」という話もあっ
たそうな
• もともとLiveScriptと呼ばれていたが、当時javaが流行っていたので、JavaScriptという名前に変更された
• IE3.0への搭載、その後の政治的な絡みで標準化用にECMAScriptができたりと、色々ありつつも、そのお手
軽さから徐々に普及
• 2005年頃にGoogleMapでJavaScriptでajax(非同期通信)を使ったアプリケーションが出てきて再評価される
• その後、各ブラウザでの標準化の推進、大手サイトで次々に利用、iOSでflash利用不可などを経て、ブラウ
ザで動くプログラム = javascriptという状態になる
• その後、node.js(最近色々あってio.jsにforkされている模様)の登場で、ブラウザ(クライアント)だけでserver
side javascriptが発展。serverもclientもjavascriptで書ける時代に。また、server side javascriptの発展で、
client side javascriptのツール群も合わせて整備される。
• 今後のプログラム界でも一番人気の言語になる可能性が高い

5. ブラウザで動くということ
• 何を言っても、javascriptの最大の特徴で今後もweb屋は避けては通れない言語（もし、
違う言語をブラウザで動くようにしようということになると、すべてのブラウザで対応
しないといけないことになるため、そう簡単にはこの地位は不動）
• 標準化の流れはあるものの、ブラウザ間での実装違いはあり、ChromeのJavaScriptとIEの
JavaScriptなどは違った動きをする部分もある（もっと言えば、IE6,7,8,9,10,11で全部動
きが違うよ！）。ただ、最近はだいぶ違いは少なくなってきている。また、Chromeと
Safariはwebkitというブラウザのオープンソース部分を共有化しているので、ほぼ同じ挙
動。
• このように、各ブラウザで同じ言語を実行しないといけないことから、他の言語に比べ
て進化スピードは遅くならざるを得ない。
• 逆に、実行スピードはGoogle, Apple, MS, Firefoxの技術者が気合を入れて作っているので
かなり高速になっている(よく、C++に匹敵するスピードになどのニュースが出ている)。

6. イベントループ
• ブラウザでのプログラミングでは、「リンクをク
リックしたら、hogehogeする」「テキストを入
力したら、hogehogeする」などのオブザーバーパ
ターンのプログラミングになる。
• このため、ブラウザ上ではイベントを検知するた
めの無限ループ(=イベントループ)がグルグル回っ
ている。javascriptで重たい処理をしてしまうとこ
のイベントループが止まってしまうため、重たい
処理はあまりさせないようにした方が良い。
• イベントループを止めたないために、提供されるAPIも非同期の物が多く、他のプログラミングよりも困難になっている
（例: サーバーにリクエストを送りレスポンスが返ってきたらhogehogeするというパターンも、一度リクエストを送った
タイミングでイベントループを再度回し、レスポンスが戻ってきたイベントを受け取ってhogehogeを実行する動きに
なっている）
• 逆に、node.jではこのイベントループに着目し、webサーバーに適した言語ということでjavascriptでの実装が行われた(
webサーバーはDBなどに重たい処理を投げるため、実際には自信で重たい処理をせずに、リクエストの振り分けをする
ことが多いため。イベントループ型のnginxとスレッド型のapacheでパフォーマンスの差が如実に出ている）

7. coffeescript
• ブラウザで動くjavascriptの言語進化スピードは遅く、現代的なプログラミング言語の良い部分を
なかなか取り込めない
• そこで、コンパイルするとjavascriptのコードを生成する1階層上の言語を作ることに =
coffeescript
• Ruby, Python, Haskell辺りの良いとこ取りをした言語で、特にRubyコミュニティでの受け入られ
ている(Railsにも3.1正式に取り込まれる)
• javascriptで問題になりがちな部分をある程度勝手にケアしてくれている上に、可読性が上がるの
で個人的には採用をオススメ（もうcoffeeで書いてばかり。今後の説明もちょいちょいcoffeeで書
きます！）
• ただ、javascriptのことを分かってないのと辛いので、javascriptも分かった上で触った方が当然良
い
• MSが出しているTypeScriptも結構良さげな感じもあるが未着手
http://coffeescript.org/

8. node.js (=io.js)
• サーバーサイドでjavascriptを実行する環境
• 運営の問題でnode.jsから大量離反でio.jsにforkされた模様
• イベントループの動きに加えて、GoogleのV8エンジンを使いかなり高速に動作する
• coffeescriptのコンパイルなど、クライアントサイドのjavascriptのコンパイル環境に
も使われることも多い
• クライアントサイドでは存在しないfilesystemやprocessなども追加されている
• npmというパッケージマネージャーがあり、エコシステムができている
• clientサイドjavascriptでもnpmを真似てbowerというパッケージマネージャーが主流
化してきている

9. node.jsなプロジェクト
• socket.io: http://socket.io/ (websocketの実装。非対応ブラウザにはflashなども使
いpubsubを実現する現実的なプロジェクト)
• Express: http://expressjs.com/ (io.jsでwebサービスを作るためのフレーワワーク)
• hubot: https://hubot.github.com/ ( Githubのchatbot )
• Grunt: http://gruntjs.com/ (コンパイルなどの自動化ツール)
• その他、コミュニケーションやゲームなどのwebアプリケーションでは結構頻繁
に使われている
• 余談だが、node.jsの開発ではRDBではなく、ドキュメント指向データベースが
使われることが多く、mongodbなどが人気となっている。

10. まとめ
• javascriptの発展はどんどん続き、しばらくはホットな
言語で、才能も集まっていくと予想される
• IT全体がwebに寄ってきているため、web屋以外も含め
て、javascriptを知っておくことは今後も有益である
• javascriptの言語発展スピードは遅いため、基礎を抑え
てしまえば言語自体はそんなに難しくないが、周辺が
目まぐるしく意外と勉強しにくいかもしれない

11. javascriptの言語的特徴
object, function, prototype

12. javascriptで抑えるべき概念
• Object
• function
• prototypeチェーン
• clousure
• 非同期 (async)
とあるが、最重要な、Object, function, prototypeチェーンだけを軽く説明

13. Object
# いわゆる連想配列
obj = {c: 3}
# .でアクセスできる
obj.b = 2
obj.b #=> 2
# []でもアクセスできる
obj[‘a’] = 1
obj[‘a’] #=> 1
# stringでアクセスできるので変数化できる
key = ‘a’
obj[key] #=> 1
obj #=> {a: 1, b: 2, c: 3}
obj.__proto__ = {d: 4}
obj #=> {a: 1, b: 2, c: 3}
obj.d #=> 4
• javascriptで最もよく使うデータ構造。javascriptの
データは全てがobjectと言っても差し支えないレベ
ル
• 要は連想配列
• []でも、.でもアクセスできる特徴がある
• 大きな特徴としては、__proto__という親Objectを
指すプロパティを持っている
• 連想配列内に存在しないキーを参照しようとした
ときに、__proto__に設定されているObjectを探索
しにいくという使い方__proto__プロパティはす
る。このどんどん__proto__をさかのぼって探索し
ていく機能をprototypeチェーンと呼んでる

14. function
• 要は関数
• javascriptでは関数も変数にしまっておくことができる
• ただ、javascriptでは、functionは全てnewできる機能が付いている。こ
のnewがjavaのコンストラクタと同じシンタックスで、微妙な違いがあ
るのでまた色々と混乱して、ちゃんと勉強しないとまずい気がしてくる
（この辺りで混乱しないようにcoffeescirptだとclassとfunctionに分離さ
れている）
• functionにはprototypeプロパティがあり、Objectを設定する
• newの挙動は、
• 新しいオブジェクトを作る。
• 作ったオブジェクトの __proto__に関数のprototypeを設定（関数の
prototype の値がObjectでないのなら代わりに Object.prototype の
値を設)
• 関数を実行。このときのthisは新しく作ったオブジェクトにし、引
数には new 演算子とともに使われた引数をそのまま用いる
• 返り値がオブジェクトならそれを返す。そうでなければ新しく作っ
たオブジェクトを返す
# 関数を変数にしまっておける
func = function(a,b){return a+b;} (jsの例)
func = (a,b)-> a+b (coffeeの例)
func(1,2) #=> 3
# new用に使う関数
Human = function(){ this.name = “taro” }
human = new Human
human #=> {name: “taro”}
# prototypeを使う場合
User = function(){ this.name = “taro” }
User.prototype = { type: “user” }
user = new User
user #=> {name: “taro”}
user.name #=> “taro”
user.type #=> “user” (__proto__を参照)

15. prototypeについてもう少し
• prototypeで参照している属性を書き換
えようとすると、自身の連想配列を書
き換えるため、普通に使っている分に
は、あたかもそのオブジェクトだけ書
き換えた風に見える
• functionのprototypeに別のfunctionの
prototypeを代入することで、継承っぽ
い事も可能。
• そんなわけで、普通のオブジェクト指
向言語とは結構発想が違うので、注意
が必要
# prototypeの方は上書きしないように上手いこ
となっている
User = function{ this.name = “taro” }
User.prototype = { type: “user” }
user = new User
user.type #=> “user”
user.type = “aa”
user #=> {type: “aa”}
user.type #=> “aa”
user.__proto__.type #=> “user”
# 継承っぽいこともできる（prototype継承をす
るときは他の方法が推奨だが分かりやすいので）
Human = function(){}
Human.prototype = {name: “dummy”}
User = function(){}
User.prototype = new Human()
user = new User
user #=> {}
user.name #=> “dummy”

16. クライアントサイドjavascriptのコーディング
コーディングの流れを復習

17. そもそもwebの全体の流れ
Request) http://example.com
Response) HTML
server
client
Request) js,css,imgの必要なファイルのURL
Response) js, css, imgなど
javascriptの実行
Request) 必要があればJSON APIなどを叩く
Response) JSON
• クライアントサイドでjavascriptが実行されるまでのやりとり。
非同期通信

18. イベント監視からの実行
1. イベント監視から実行するコードを書く
2. さっきの流れでHTML, javascriptなどが配信される
3. ブラウザで監視しているイベントが起きる
4. 書いてあったコードが発火する

19. イベントの監視方法
<html>
<head>..</head>
<body>
<a href=“#” onlick=“alert()”>click</a>
</body>
</html>
• タグ埋め込みの方法
最近はほぼ使われなさそうだが、最も単純な方法で知って
おくべき。
使われない理由としては、HTML、CSS、Javascriptと分業
しようよという大義面分があること、ライブラリなどで使
い勝手が悪いこと、何よりjQueryが普及したことが原因
か。ただ、Angularなどで逆に揺り戻しが来ている気も。
<html>
<head>..</head>
<javascript>
$(function(){
$(“a”).click(function(){
alert()
})
})
</javascript>
<body>
<a href=“#”>click</a>
</body>
</html>
• 監視対象を切り出すパターン
こちらの方が最近では主流
まとめて指定できるので、DRY
ライブラリなどで1行書くだけで全体に反映できたりす
るので、便利

20. イベントのバブリング
• HTMLは木構造を取っているので、子
ノードで起きたイベントは上のノード
に上がっていく（止める用のメソッド
でstopPropagationなどもある） # aタグをクリックすると、aだけでなく、div.b
にもdiv.aでもclick eventが発生する
<html>
<head>..</head>
<body>
<div class=“a”>
<div class=“b”>
<a href=“#” onlick=“alert()”>click</a>
</div>
</div>
</body>
</html>

21. 非同期通信
• ページのリロードなしにデータを取得す
る通信方法
• javascriptでJSONやXMLのAPIを叩いて
持ってくる方法が主流
• 通信に成功失敗のコールバックを指定し、
APIからのレスポンを受けると実行される
• jQueryの場合はDeferred Objectが戻り値に
なるため、コールバックをメソッドチェー
ンで書くことも可能
# 非同期にJSONを
$.ajax({
type: "GET",
url: “sample.json”,
success: function(){alert(“成功したよ!”)},
error: function(){alert(“失敗したよ”)}
})

22. 実用に向けてのライブラリ紹介
たくさんあるよ！

23. ライブラリがなぜたくさんあるか
• javascriptは言語自体がなかなか動かせないという特徴があるため周辺が厚くなる傾向がある
• 元々、ブラウザ間での実装違いがあるためその部分を吸収するためにライブラリが必要だった
• 最近は、リッチなwebサービスが主流になってきっためjavascriptをきちんと管理する必要があ
り、フレームワークも増えている
• サーバーサイドで発展したMVCはオブザーバーパターンのjavascriptとは微妙に食い違う。MVVM
などの設計思想が主流になってきている。
• 発展途上的な要素が大きく、色々とたくさんのライブラリがでてきるという認識
• クライアントサイドではライブラリが巨大になると、転送量が多くなるためライブラリのバラン
スも難しい
• 以上、対応ブラウザ・機能・ラブラリサイズ・発展途上という要素が絡まり合って量が多くなっ
ている

24. DOM操作系のライブラリ
jQuery
DOM操作を中心に何でも入っていた
#=> 最近、少しずつ軽量化する方向に
jQuery UI jQueryとセットで使いDrag&Dropなどの操作などが実現できる
zepto.js jQueryをスマホのみをターゲットに軽量化したもの
prototype.js
jQueryによって駆逐された感がある。Rails2などでは採用されていたが
最近はダメそう
• javascriptはHTMLの構造を読み取り操作するものが多い。そのため、DOMの操作はメインの仕事の一つにな
る。このジャンルについてはjQueryが制覇しており、jQueryだけ覚えておけば今の所OK。ただ、近年のライ
ブラリ感からいくと、jQueryも重要性が薄れていく方向性にある。また、jQueryプラグインをポンと入れる実
装も最近だと結構微妙な感がある。

25. ユーティリティ系のライブラリ
underscore.js rubyなどで使うtap, map, injectなどのよく使う関数が使えるように
lodash.js
underscore.jsの高速化バージョン。最近はこっちの方がよく使ってい
る。
require.js
javascriptの大きな問題としてスコープがGlobalしかななく、名前が衝
突してしまう問題があった。このため、ファイル分割とそれを読み込
むrequire的な機能は大規模な開発では必ず必要になっている。最近の
開発では必須なライブラリだと言える
moment.js 時間関係のライブラリ。こいつもよく使う
• javascript本体の言語では不足している機能を足してくれるmodule的なライブラリ群。どれも知って
おいて損はなさそう。

26. テスト系のライブラリ
mocha テストフレームワークのデファクト
sinon モックやスタブ用のライブラリ
chai assert, except, shouldなどの記述をサポートしてくれる
mocha-phantom.js
mochaをphantom.jsで実行できる。ブラウザとかでテストしたくない
よね。
• mochaが高速化したバージョンを出した時はぶったまげた速度で笑った記憶が。単にパラレルでテストをするよ
うになっただけなのかな。ブラウザ依存なども各ブラウでテストを流せば良いので、実はサーバーサイドよりも
テストを書く対費用効果が高い。最近でテストがないコードを産むのは恥ずかしいですよね。

27. ブラウザ間の差異を吸収するライブラリ
modernizr
アクセスするブラウザ毎に利用できる機能に応じたclassをbodyにつけ
るためにつかう。特に何かを吸収しているわけではない。
es5-shim 古いブラウザでもecmascript5を使えるようにする
json2.js 古いブラウザでもJSONが使えるようにする
• 最近では出番は減ってきているが、古いブラウザへの対応などを考えると必須のライブラリ群。
必要ならもっと探しておいたほうが良いのかな。

28. テンプレートのライブラリ
mustache {{var}}で埋め込む超軽量のPull型のテンプレート。どちらかというと仕様に近いので、サーバーサイドでも使える
Handlebars.js mustacheにちょいと機能を足したもの
Hogan.js Twitter製でmustacheにちょい機能足し
jade slimっぽいシンタックスで書けるテンプレート
• 正直どれも似たり寄ったり。好きなの使ったら良いんじゃねという状態
• サーバーサイドjavascriptもあって、サーバーサイドとクライアントサイドで共有したテンプレートも作成可能に
• サーバーサイドで好きなテンプレートでコンパイルしてmustacheにしても良いかもしれないと思う今日この頃

29. MVVMのフレームワーク
backbone.js MVとModelやViewとLayerに分離した老舗。このmodelはAPIとのIFにもなっている
exoskelton backbone.jsの高速化版（少し触った感じがある）
chapin.js MVCのCを提供。backboneと組み合わせて複数ページをjsで作るためにつかう
backbone.stickit NYTで作成。backboneのデータバインディングを追加
marionette.js BackboneにLayoutやmoduleなどの共通化する仕組みを提供
rivets.js データバインディングを提供。Ractiveと同じ立ち位置だが、後発だけあってこっちの方が使い勝手が良さそう
knockout.js MSの人が作っている。backboneとAngularの中間くらい世代のフレームワークだが、フルスタックという感じはない
Angular
Googleの人が作っているMV*フレームワーク。HTMLを拡張してデータをバインディングするのが特徴。デファクトになりそうだ
が、too much感もある
Angular2 Angularのv2だが互換性が微妙らしく批判もある。まだ開発中
Vue.js 最後発で、データバインディング中心。AngularとRivetsなどの良いとこ取りをしていて筋が良さそう。試してみたい。
• 老舗のBackbone.jsがかなり薄い実装なので周辺に組み合わせる関係のフレームワークが大量に発生
• Angularが最大勢力になりそうだが、一長一短な状態。まだ発展途上な状態。ただ、データバインディング、ディレクティブ辺
りは必須機能として取り込まれそう。
• BackboneのようにModelはAPIとのIFも担当、データバインディングやディレクティブみたいなものに落ち着くんじゃないかな

30. API
MVVMのフレームワーク考察 その1
View
MVVM系のフレームワークでは、Modelと同じ名前だがフレームワーク毎に考え方
が違う設計になっている
- [ui model] Viewとのやりとりで、表示状態を保持するための変数 (angular)
- [api model] APIとのやりとりを中心にするもの (backbone)
最近の、angularやvuejsなどバインディングを中心にするフレームワークは、[ui
model]の方のmodelにフォーカスしている場合が多い。
2つのmodelは縮退している場合も多く、APIとのやりとりを考慮すると、backbone
の方が使いやすいシーンもある。
この2つのModelは別Layerとして再定義される可能性が高いと個人的には考えてお
り、Railsのdecoratorのように[api model]をwrapした[ui model]を定義する設計が良
いと思う。
また、[ui model]は単体でも動作し、その場合はAPI通信などは含まないアプリケー
ションとなる。
Model
Model
脱
線

31. MVVMのフレームワーク考察 その2
View
UI Modelについては、データバインディング(filter, directive)を通してViewでの操作を
自動的に反映される形にする現状のフレームワーク方向の進化が妥当でデファクト
になると思う。
- データ変更の検知 => Viewの何かしらの状態を変更
- Viewでのユーザー操作 => UI Modelのデータ変更
という2つの流れは普遍なので、
-「どこに」「何の」データを表示するか？
-「どこを操作すると」「何の」データに反映するか？
の2つをHTMLに埋め込んで定義するというプログラミングスタイルは定着するは
ず。Vue.jsのようにViewModelにより、Model(データ)とViewの紐付けを切り出す形
が適切でわかりやすいと思う。
UI
Model
UI Model
ViewModel
脱
線

32. MVVMのフレームワーク考察 その3
UI ModelはAPI Modelのdecoratorになるべきかと
基本、IFにはdecoratorのような機能があるべきだと最近は考えている
UI ModelのAPI Modelに該当する部分はそのままAPI Modelに移譲
UI Model独自部分だけをUI Model上に実装するスタイルが良いかと。
このため、データバインディングなどもAPI Modelに直接書き込みに行くものがあ
る状態だと思う。
また、UI Modelから計算してAPI Modelに反映する場合の反映タイミングなどは、
何かしらのイベントフックで対応するか明示的に実行するような形になると思われ
る。
UI Model - API Model
UI Model
API
Model
脱
線

33. MVVMのフレームワーク考察 まとめ
API
View
UI Model
API
Model
ViewModel
Angular, Vue.js
が得意
backbone
が得意
左図のように微妙に領域が違うので、decoratorで統
合するフレームワークがあると便利そう（試しに小
さく実装しようかな）。V
考察していたら便利そうな感じの設計ができた気が
する。Backbone + Rivets.jsあたりで実現できそう
か。
さらに、複数ページに遷移する場合はChaplin.jsなど
も絡めて作ると良さそう。
RailsのActiveModelなどのように抽象度を高めて実装
すると素晴らしそう。
まとめ
脱
線

34. まとめ
とりとめがなかったけれど・・・

35. これからjavascriptを勉強する場合
• 言語仕様はサクッとしたものなので、勉強しておくと後々も含めて良いので
読んでおく
• 言語を覚えても実際に使う場面は少なく、ライブラリをだいぶ勉強しないと
いけない。また、ライブラリが大量にあり、技術選定が難しい。色々普段か
ら触っておくと何かと良い
• マシンスペックが向上すればするほどHTML5アプリの出番も増えるので、今
後も進化するMVVM系のフレームワークはウォッチしておくと面白いと思う
• 今回は対象外だったけれど、サーバーサイドのio.jsも非常にホットなので合
わせてウォッチしておくと楽しいと思うので、両面含めて見ておくと色々ヒ
ントになりそう