More Related Content
Similar to クライアントサイドjavascript簡単紹介 (20)
クライアントサイド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のツール群も合わせて整備される。
• 今後のプログラム界でも一番人気の言語になる可能性が高い
- 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などが人気となっている。
- 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__を参照)
- 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行書くだけで全体に反映できたりす
るので、便利
- 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が高速化したバージョンを出した時はぶったまげた速度で笑った記憶が。単にパラレルでテストをするよ
うになっただけなのかな。ブラウザ依存なども各ブラウでテストを流せば良いので、実はサーバーサイドよりも
テストを書く対費用効果が高い。最近でテストがないコードを産むのは恥ずかしいですよね。
- 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
脱
線