Movatterモバイル変換

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

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

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

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

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

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

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

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

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

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

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

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

Object# いわゆる連想配列obj = {c: 3}# .でアクセスできるobj.b = 2obj.b #=> 2# []でもアクセスできるobj[‘a’] = 1obj[‘a’] #=> 1# stringでアクセスできるので変数化できるkey = ‘a’obj[key] #=> 1obj #=> {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チェーンと呼んでる

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 Humanhuman #=> {name: “taro”}# prototypeを使う場合User = function(){ this.name = “taro” }User.prototype = { type: “user” }user = new Useruser #=> {name: “taro”}user.name #=> “taro”user.type #=> “user” (__proto__を参照)

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

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

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

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

イベントの監視方法<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行書くだけで全体に反映できたりするので、便利

イベントのバブリング• 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>

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

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

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

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

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

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

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

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

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の中間くらい世代のフレームワークだが、フルスタックという感じはないAngularGoogleの人が作っているMV*フレームワーク。HTMLを拡張してデータをバインディングするのが特徴。デファクトになりそうだが、too much感もあるAngular2 Angularのv2だが互換性が微妙らしく批判もある。まだ開発中Vue.js 最後発で、データバインディング中心。AngularとRivetsなどの良いとこ取りをしていて筋が良さそう。試してみたい。• 老舗のBackbone.jsがかなり薄い実装なので周辺に組み合わせる関係のフレームワークが大量に発生• Angularが最大勢力になりそうだが、一長一短な状態。まだ発展途上な状態。ただ、データバインディング、ディレクティブ辺りは必須機能として取り込まれそう。• BackboneのようにModelはAPIとのIFも担当、データバインディングやディレクティブみたいなものに落ち着くんじゃないかな

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

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

MVVMのフレームワーク考察その3UI 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 ModelUI ModelAPIModel脱線

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

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

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

Movatterモバイル変換

Change Language

クライアントサイドjavascript簡単紹介

Embed presentation

Recommended

More Related Content

What's hot

Viewers also liked

Similar to クライアントサイドjavascript簡単紹介

クライアントサイドjavascript簡単紹介