JSer ClassJavaScriptの基礎と軽量フレームワーク

目的

• 一般的観点• Webアプリケーション開発のなかで存在感を増し続けるJavaScriptに

ついて、「なんとなくわかる」でない知識を身に付ける。

• JavaScriptのメリット、デメリット、代替技術について知ることで、保守/開発の生産性や品質を向上させる。

• 特殊的観点• 数カ月後に身近な存在となる某クライアントサイドMVCライクなアプ

リケーションの保守/開発のための基礎知識を得る。

再掲

開催概要

• 開催日時• 3/2（水）〜 毎週水曜 19:30〜21:30 全3回予定

• 会場• コラボレーションスペース（N・W）

• コンテンツ• 第1回 JavaScriptの言語仕様

• 第2回 DOMとXmlHttpRequest、軽量フレームワーク

• 第3回 クライアントサイドMVC

再掲

参考情報

• サイト• JavaScriptガイド＠MDN

• https://developer.mozilla.org/ja/docs/Web/JavaScript/Guide

• 書籍• JavaScript 第6版（サイ本）

• http://www.amazon.co.jp/dp/4873115736

• Effective JavaScript• http://www.amazon.co.jp/dp/4798131113

再掲

JSer Class #3 代替技術/クライアントサイドMVC

前回学んだこと

• DOM/Event/XHRの概要

• prototype.js/jQueryの基本的な概念と使い方

• 軽量FWの存在意義

• 関数（とくにそのスコープと変数束縛）の活用方法

兎にも角にも関数関数関数…。

「いや、jQueryなんて古臭い話どうでもいいし」

「はやく最近とこれからの話をしたいし」

─という方、同感です。

お待たせ致しました。

達成と課題の連鎖…

HTMLの登場ちょっとしたインタラクショ

ンがほしい…。表現手段がな

い。

JavaScript

/JScriptの登場

ユーザ操作に合わせてダイナ

ミックにコンテンツを変化さ

せたい。APIがない。

DOM/Event

/XHRの登場

ブラウザ間で動作がバラッバ

ラ。標準APIはちょっと使い

づらい。

prototype.js

/jQueryの登場

便利なんだけど、そろそろJS

でやっていくの辛い。クライ

アント/サーバ両サイドにロ

ジックが散らばっていていろ

いろ面倒。

サーバ/クライアントそれぞれの発展/分化の系譜

静的Webページ

CGI

Servlet/ASP.NET/etc

Ajax

RESTfulAPI

ちょっとしたインタラクション

DOMによる動的書き換え

MVC（Struts/Spring）

↑サーバ・サイド

↓クライアント・サイド

ほぼ死滅

Flash/Applet死滅

CoC

変わらなかったもの

① クライアント側のプログラムはJavaScript

② ページをつくるのはサーバ側のプログラム

変わらなかったもの①クライアント側のプログラムはJavaScript• 規模の拡大に伴いJSの性質のことごとくが悪く働く結果に…

• package/moduleが存在しない

• 動的型付けである

• classベースのOOPでない

• 可視性の制御ができない

• ほぼあらゆる変数/プロパティが再代入できてしまう

• 結果IDEによるサポートが提供できない

• 上書きによる既存ロジックの破壊のリスクがある

• ようするに組織的開発にまったく向かない（Rubyよりマシ、というレベル）

変わらなかったもの②ページをつくるのはサーバ側のプログラム

• ロジックの分散が深刻化しMVCの役割分担がいびつ化

• シームレスなページ遷移の障碍（ActionScriptが担った領分）

言い忘れていたけど、FlashのためのOOP言語ASもECMAScriptの実装

系です。

HTML

JavaScript

ロジックの分散/MVCのいびつ化

→ サーバ・サイドクライアント・サイド ←

Persistence

ModelController

View

JSがMVCのロジックの一部を負担し始める

動的要素が両サイドに存在し、設計/開発/保守が

煩雑化

HTML

JavaScript

シームレスなページ遷移の障碍

→ サーバ・サイドクライアント・サイド ←

Persistence

ModelController

View

Ajaxはあくまで副次的なコンテンツのやり取りを担当

HTTP GET/POST

ページ遷移時はサーバ側へのリクエストを行う

変わらなかったもの（再び）

① クライアント側のプログラムはJavaScript→プログラミング言語の課題

② ページをつくるのはサーバ側のプログラム→アプリケーション設計（デザイン）の課題

代替技術プログラミング言語の課題克服

altJS（alternative JS）

• 新しい千年紀の最初の10年が終わらんとするころ登場。

• その名の通りJavaScriptを置き換えようとする思想/実践の総称。

• 一般にコンパイラがJavaScriptコードを生成する。

• ただし動機はいろいろ、有用性もいろいろ。

それにしてもセンスのない

タイポグラフィ…

altJSの動機/形態

•勉強会で紹介してきた種々の課題克服

• JavaScriptコーディングの省力化

•コンパイラ言語との統合

構文/パラダイムを置換え

構文/パラダイムを拡張

altJSの例

言語名 開発元 説明

CoffeeScript Jeremy Ashkenas

altJSの嚆矢となった言語。便利な構文/ショートハンドの導入。それと不可分のコードの曖昧性の急拡大（XML/JSONに対するYAMLのようなもの）。ようするに状況は却って悪化。

ClojureScript Rich Hickey JVM上で稼働するLisp方言であるClojureのコードを元にJavaScriptコードを生成する。Clojureの売りは並列分散処理のはずだが…。

Dart Google クライアントサイドにランタイムが必要。つまりJavaScriptの糖衣構文ではなく、独立した言語。

TypeScript Microsoft JavaScriptのスーパーセットであり、ECMAScript v6以降の先行実装でもある。後程さらに詳しく取り上げる。

Scala.js École polytechnique fédérale de Lausanne/Typesafe

JVM上で稼働するOOP+FP言語であるScalaのコードを元にJavaScriptコードを生成する。Java/C#以上に強力な型システム、高度な型推論、にも関わらずシンプルな記法、内部DSL、強力な標準APIといったScalaの特徴をそのまま移植（*）。当然の結果としてものすごいファイルサイズになる。

＊ Scala.jsについてはこちらも参照のこと： http://m12i.hatenablog.com/entry/2015/07/20/104347

altJSの実行時エラー解析

• altJSには以下の2つのコードが存在することになる：A) もともとのソースコード（非JS）B) コンパイル後のソースコード（JS）

• 実行時のエラーはもちろんB側で起きる。

• エラーを解析するには、B側のコードのエラー箇所がA側のコードのどこに対応するかを知る必要がある。

• この対応付けを実現するのが、コンパイラにより生成される.mapファイル（*）。

• .mapに対応したブラウザではエラー発生時にもともとのコードの位置情報を表示してくれる。

＊ .mapファイルはjQueryなどのライブラリでも利用されている。この場合.mapはライブラリのもとのソースコードとそれをminifyしたコードとを対応付ける（たぶん歴史的にはこの利用法が先行する）。

余談）ランタイム on ランタイム

• Python• IronPython .NETランタイムで稼働するPython

• Jython JVM上で稼働するPython

• Cython コンパイルされC言語化されるPython

• PyPy Pythonインタプリタ上で稼働するPython

• Ruby• JRuby JVM上で稼働するRuby。CRubyより早い？

• Erlang• Elixir Erlangランタイム上で稼働するRubyライクな言語

研究目的、既存リソースとの統合目的などいろいろな動機

TypeScriptとは何か？

• Microsoftが開発。

• JavaScriptのスーパーセット ＆ ECMAScript 6+の先行実装。

• Windows/Linux/Mac OS X向けにコンパイラが提供されている。

typescriptlang.org

TypeScriptのアドヴァンテージ

JSコードに対しほぼ完全な互換性がある

ECMA標準準拠を標榜している

構造的部分型による柔軟/強力な型安全性を持つ

結果としてIDEによるコーディング支援が可能になる

Java/JavaScript経験者にとって学習曲線が緩やか

俄に/急速にOSS傾斜を強める巨大ベンダが開発している

TypeScriptの難しさ

• TSを知るにはまずJSを知らないと（絶対にではないが…）。

• 問題が起こった時の分析がしにくいケースがある（mapファイルをサポートしないブラウザで）。

• 非常に強力な型概念が「生産性と品質を向上」とともに「従来のJSコードとの統合」を実現してくれる反面やはり難解。

TypeScript言語仕様基本型• string JavaScriptのstring

• number JavaScriptのnumber

• boolean JavaScriptのboolean

• any 変数/戻り値型。あらゆる型のサブタイプ。

• void 戻り値型。「戻り値がない」の意。

• enum データ/変数/戻り値型。numberのサブタイプ。

• Array<T> JavaScriptのArray。

• null/undefined 説明省略！ なぜかここだけC#チックという謎。

any/voidはデータ型ではなく変数型である。当たり前だが、念のため。

TypeScriptのオブジェクト・グラフ（推測）

Object

PrimitivesArray<T> RegExp

Any Void

その他オブジェクト

すべての型のサブクラス?!

戻り値がない…という値

実のところ「考えたら負け」的な

要素が若干ある

TypeScript言語仕様インターフェースたち（複数形?!）• プロパティ宣言を持つインターフェース（ふつう）

• オプションのプロパティの宣言を持つ 〃 （独特）

• 関数インターフェース（関数オブジェクトのための定義）

• コンストラクト・インターフェース（初期化子の定義）

• 配列/辞書インターフェース（添字型と戻り値型の定義）

• ハイブリッド・インターフェース（関数でありオブジェクト）

NOTETypeScriptのインターフェース概念はあきらかにJavaやC#よりも複雑なものになっている。理由は明解で、JavaScriptとの整合性を保つため。安堵と倦怠を同時に感じさせられるという、複雑な気分である。

TypeScript言語仕様クラス• プロパティ（フィールド/メソッド）の宣言を持つ。

• プロパティはprivate/publicの別を持つ。

• コンストラクタを持つ。

• アクセサ（C#におけるプロパティに相当）を持つ。

• 添字アクセサを定義できる。

• オーバーロードの仕方がだるい。

• staticプロパティの宣言を持つ。

追記

ここでいきなり皆さんを意気阻喪させたくないので、列挙だけ…。

TypeScript言語仕様その他重要な要素• 型推論（機械的に推論可能な型表記は省略可能）

• 構造的部分型（所定のメンバを持つなら何型だろうと不問）

• モジュール（名前空間を実現、公開するAPIを制限）

• アロー関数（=>）

• ジェネリクス（もちろんクラス/メソッドの両レベルで可能）

• 宣言ファイル（〜.d.ts）による既存コードとの統合（*）

• constの再定義（今度こそ再代入不可能）

←「その他」≒早くも力尽きた。

＊ jQueryやAngularJSなどの既存リソースのためのd.tsファイルは有志により作成されたものがGithub上で公開されている： https://github.com/DefinitelyTyped/DefinitelyTyped

TypeScript Handbook

• http://www.typescriptlang.org/Handbook（部分抄訳：http://m12i.hatenablog.com/entry/2016/03/16/112829）

• ここまで列挙したTypeScriptのビルディング・ブロックがサンプルとともに紹介されている。

• 少なくともBasic Types〜Classesまでは「すっきりした印象」を受ける（Modules以降雲行きが怪しくなる）。

追記

TypeScriptのサンプル・アプリ（*）

• 前回も登場したTODOアプリをTypeScript化。

• jQueryを型安全に扱うためd.tsファイルも導入。

• 前回アプリのapp.jsと今回アプリのapp.tsを比較してみよう。

• TypeScript対応IDE/エディタでapp.tsを開き編集してみよう。

＊サンプル・アプリのリポジトリはこちら： https://github.com/mizukyf/jserclass3ts

サンプル・アプリのファイル構成①• app.tsが開発者がコーディン

グしたもの

• jquery.d.tsはjQueryのAPIをTSから型安全に利用するための型定義ファイル

• app.jsはtscが生成したJSコードのファイル

• app.js.mapは元になったJSコードとのマッピングのためのファイル

サンプル・アプリのファイル構成②• tsconfig.jsonはTSのビルド設

定などを定義したJSON（*）

• ここでビルド後のファイル名（app.js）を定義しており、かりにtsファイルが複数あってもすべて1つのJSファイルに統合されるようにしている。

＊なお、このJSONのMicrosoft公式のスキーマでサポートされたオプションは貧弱。結果、atom-typescriptなどが勝手に拡張したスキーマを宣言しており、Web上で情報を得ようとした時に混乱しがち。

サンプル・アプリのコード①d.tsによる既存リソースとの統合• jquery.d.tsによりjQueryに明確な型が与えられている。

• インターフェースの違いからJQueryStaticとJQuery（次スライドで登場）という区別がある点に注意。

(function($ : JQueryStatic) {

// ...ページ・ロード中に実行される...

$(document).ready(function() {

// ...ページ・ロード後に実行される...

});

})(jQuery);

サンプル・アプリのコード②変数/定数と型推論• TypeScriptではconstが利用できる。再代入のつもりがないこ

とを明示することができる。

• 型指定を指定していないがその実コンパイラがJQuery型を自動推論しており、異なる型の値を代入しようとするとコンパイル・エラーになる。

// ↓は const taskTpl :JQuery = $("tr.task-tpl"); と同義const taskTpl = $("tr.task-tpl");

const taskNew = $("tr.task-new");

const taskNewTitle = $("input:text", taskNew);

const taskNewBtn = $("td.task-action > button", taskNew);

サンプル・アプリのコード③クラスの定義とショートハンド• TodoTaskクラスの宣言部。

• コンストラクタの宣言では、仮引数の定義と同時にpublic/privateフィールドを定義することができる。cf. Scala

class TodoTask {

constructor(

public id :number,

public title :string,

public createDate :string) {

}

}

サンプル・アプリのコード④関数の仮引数/戻り値の型指定• 仮引数も戻り値も型指定された関数。

• 戻り値は関数のコード本文から推論されるのでvoidは省略可能。

// ↓は function addTask (task :TodoTask) : void と同義const addTask = function(task :TodoTask) :void {

// ...

$.ajax({

// ...

});

});

サンプル・アプリのコード⑤構造的部分型• addTask関数呼び出し箇所に注目。仮引数の宣言では

TodoTask型のオブジェクトが求められている箇所に、{} で値を渡している。

• これが構造的部分型のパワー。「TodoTaskと寸分たがわぬインターフェースを持つ限りそれは事実TodoTaskと見做しうる」ということ。差異があればコンパイル・エラーになる。

taskNewBtn.click(function (event :JQueryEventObject) {

const title = taskNewTitle.val() as string;

// addTask(new TodoTask(0, title, null))

addTask({id: 0, title: title, createDate: null});

taskNewTitle.val("");

});

補足）構造的部分型

• Structural Subtype（Subtyping）。

• 型の宣言によらず、インスタンスが持っている"形"（Shape。JSの場合ようはプロパティ）によってサブ型と判定されること。

• 「ダックタイピング」（アヒルに見えるしアヒルのようにガーガー鳴くならアヒルに違いない）を実現するための仕組み。

• Python/RubyではAPIの柔軟性のためダックタイピングが推奨されるが「だからAPI開発者はまず引数として渡されたオブジェクトのメンバーの存否をチェックして…」となる。しかしScalaやTypeScriptでは「そういうことはコンパイラに任せてください」となる。

付録）開発環境構築コンパイラの導入• VS 2015を利用される場合、プリイントール済み。

• VS 2013の場合はMicrosoftが公開している無料のツールTypeScript 1.5 for Visual Studio 2013を導入するだけ。

• LinuxやMac OS Xで開発をする場合やWindows OSでもVS以外を利用される場合、まずnode.jsのパッケージ管理ツールであるnpmを導入し、その後下記コマンドを実行してTypeScriptコンパイラをインストール：

$ sudo npm install -g typescript

付録）開発環境構築Hello World• まずgreeter.html をつくる：

<!DOCTYPE html>

<html>

<head><title>TypeScript Greeter</title></head>

<body></body>

<script src="greeter.js"></script>

</html>

付録）開発環境構築Hello World• 次にgreeter.tsをつくる：

interface Person {

firstname: string;

lastname: string;

}

function greeter(person : Person) {

return "<h1>Hello, " + person.firstname +

" " + person.lastname + "</h1>";

}

var user = {firstname: "Marc", lastname: "Bloch"};

document.body.innerHTML = greeter(user);

付録）開発環境構築Hello World• コンパイルしたあとhtmlファイルをブラウザで開く：

$ tsc greeter.ts

付録）開発環境構築エディタの選定• もちろんVisual Studio（VS）はTypeScriptに対応。VSのユー

ザは特段の準備もなくコーディングを開始できる。

• ふだんVSを使用していないという方も、もし開発マシンがWindowsに限定されるなら導入を検討もよし。

• 一方そうでない方はEclipseやWebStormのようなIDE、AtomやVisual Studio Code（VS Code）の導入を検討。現段階でおすすめはVS Code。

• それぞれのツールについてまとめたのが次表。

付録）開発環境構築VS以外のエディタ

WebStorm JetBrains社が販売するIDE。年間129ドル。定評あり。

Eclipse（TypEcs） Github上のIssuesでのやり取りを見る限りメンテナンス状況はあまりよくないようす。実際利用してみるとプラグインの設定やプラグインの構成を変更するたびに何かしらのエラーが発生してその解決にあたふた（*）。

Atom（atom-typescript）

atom-typescriptというTypeScriptコーディング＆ビルド用のパッケージがコミュニティから提供されている。ファイル保存時の自動ビルド、コード入力中の候補表示や型チェックなどの機能が有効になる。ただし、2016年3月時点ではこの自動ビルドがバグっている。

VS Code Microsoft社が提供。Atomと同じElectronをベース。WindowsはもちろんLinuxやMac OS Xでも使える。自動ビルドには対応していないがショートカット・キーを使って任意のタイミングでビルドできる。ビルドはtsconfig.jsonに基づくもの、固定パラメータに基づくものいずれにもでき、その点の柔軟性は高い。

＊ 詳しくはこちらも参照のこと： http://m12i.hatenablog.com/entry/2016/03/13/085936

付録）開発環境構築VS Codeおすすめの理由• Linux OSやMac OS Xでも利用できる。

• 初期費用がかからない。

• 言語と同じ開発元でサポートに信頼がおける。

• 現時点でツールの安定性が高い。

• 独自拡張など便利だが非公式のナレッジが不要。

• EclipseなどのIDEと併用する上で機能が十分にシンプル。

付録）開発環境構築VS Codeでビルド・タスクを用意① プロジェクト・ディレクトリ（ただのディレクトリ）を作成する。

② VS Codeを起動する。

③ ［File］→［Open］でファイル／ディレクトリ・ピッカーを表示する。

④ 上記ディレクトリを選択して［Open］。

⑤ Ctrl+Shift+P（Mac OS XではCommand+Shift+P）でコマンド・パレットを表示する。

⑥ 「Tasks: Configure Task Runner」と入力しEnter。

⑦ .vscodeというサブディレクトリが作成され、その中にtasks.jsonが作成される。

⑧ tasks.jsonのargsの値をコンパイル対象ファイルにあわせ修正し保存。

⑨ Ctrl+Shift+B（Mac OS XではCommand+Shift+B）でビルド実行。

クライアントサイドMVCアプリケーション設計の課題克服

ロジックの分散/MVCのいびつ化/シームレスなページ遷移の障碍

→ サーバ・サイドクライアント・サイド ←

Persistence

ModelController

View

HTML

JavaScript

HTTP GET/POST

課題（再掲） JSがMVCのロジックの一部を負担し始め、動的要素が

両サイドに存在、設計/開発/保守が煩雑化。 Ajaxはあくまで副次的なコンテンツのやり取りを担当、

ページ遷移時はサーバ側へのリクエストを行う。

RESTful API

クライアントサイドMVCの基本的な構成

→ サーバ・サイドクライアント・サイド ←

Persistence

Model

HTML

JavaScript

HTTP GET/POST

ModelController

View

補足）RESTful API

• REST: Representational State Transfer。

• RESTful API: RESTの原則に準じたAPI。

• そもそもRESTの概念がよくわからない＆一定していないのでRESTfulの定義もあやふやっぽい（*）。

• しかしようするに「標準化されたスキーマ情報を持たない（**）

Web サービスで、リソースのCRUDをHTTPメソッドPOST/GET/PUT/DELETEで表現するもの」。

• ─って、ますますよくわからない？

＊ 白状すると少なくとも「あやふや」な原因の半分は私の勉強不足なだけだと思います。＊＊ これは「スキーマがない」ということではない。「スキーマを機械/プログラムが理解可能な形式で表現することはしない」ということである。RESTful API登場以前から一般に利用されてきたSOAPというプロトコルではWDSLというXMLのサブセットで、クライアント/サーバがやり取りするデータの形式を定義している。

補足）RESTful APITodoTaskオブジェクトの場合• 例えばサンプル・アプリの場合、以下のようなURL/HTTPメ

ソッドの組み合わせでTodoTaskオブジェクトのCRUDを表現している（リソース名は複数形にするのが慣例）：

I/O メソッド URL 説明

C POST /api/tasks HTTPリクエスト・ボディのJSONをTodoTaskオブジェクトとしてデリシアライズして、DBに登録する。

R GET /api/tasks/{id} 指定されたIDを持つTodoTaskオブジェクトをDBから取得し、結果をJSONとしてシリアライズして返す。

R GET /api/tasks DBからTodoTaskを全件取得してJSONとして返す。

U PUT /api/tasks/{id} 指定されたIDを持つTodoTaskをリクエスト・ボディの内容で更新する。

D DELETE /api/tasks/{id} 指定されたIDを持つTodoTaskを削除する。

何が変わった？

クライアント側

• クライアント側にMVCの全要素が移動し、データ永続化以外のすべての制御を掌握。

• ページ遷移すらもクライアント側で閉じた処理になる。

サーバ側

• VC要素がほぼ消滅。多様なリクエストを処理する複雑なロジックはなくなった。

• XML/JSONを受け付けるRESTful APIがデータの永続化とTXを担保。

いやまあ、理論的にはそうなんだけど…• 実際問題としてTXを担保したAPIデザインがむずい。

• JavaScriptであれもこれも実装となるとJava/C#の既存リソースが再利用できない。

• クライアント側でエラーが起きた時もはやサーバ側には何も残らない。

• JavaScriptの言語的な課題（勉強会を通じて確認してきた）がずっしり重ーくのしかかる。

新たな課題TX担保の難しさ• 実際問題としてTXを担保したAPIデザインがむずい。

• ステートレス通信であるHTTPを利用している以上、クライアント側にはTXの完全性を担保する手段がない。

• よってその担保はサーバ側に委ねられ、適切な粒度で「リソース」を扱う（URLとして表現する）必要が出てくる。これが難しい。

• ただこの壁を乗り越えるとクライアント側の拡張性が飛躍的に高まる。

• 「PC向けにはWebアプリを提供しつつ、スマホ向けにはネイティブ・アプリを提供する」など。

新たな課題既存リソースの再利用• JavaScriptであれもこれも実装となるとJava/C#の既存リソー

スが再利用できない。• しかたないので高度な操作はやはりRESTful APIの向こう側に封じ込め

ることにしよう。

• Scala.jsのような標準API丸ごとを移植しようというような大それた試みを以ってしても、サードパーティ製の既存リソースは移植できない。

新たな課題エラーログが残らない• クライアント側でエラーが起きた時もはやサーバ側には何も残

らない。• ということは「エラーが起きる条件」を再現できる環境やテストデー

タの準備が必要になる。

• また今回まったく取り上げられていないが、JavaScript用の単体テストFWなどを用いてくだらないバグをあらかじめ完全に潰してやることも必要になる。

• というかそれくらいでしか対策できない。

新たな課題JavaScriptの言語的課題• JavaScriptの言語的な課題（勉強会を通じて確認してきた）が

ずっしり重ーくのしかかる。• ここでaltJSに白羽の矢が立つ。

クライアントサイドMVCの例AngularJS• Googleが開発を主導するクライアントサイドMVCフレーム

ワーク（*）。略号は"ng"らしい。

• バージョン1.x系はJavaScript、2.x系はTypeScriptで開発されている。

• モジュール構成をとっており、公式の機能であってもコア以外は必要に応じて読み込む形式。

＊ 参考資料を読むと「MVCではなく○○だ」的な記載もそここにあるのだが、あまり分類を細分化したり再定義したりする意味を感じないので、ここではともかく単にMVCとしておく。

AngularJSの重要概念

• DI：依存性注入の概念をJSの世界に導入。

• DOMの隔離：もはやDOMを直接操作したりせず、より上位のディレクティブと呼ばれる単位で制御を行う。

• バインド：ディレクティブに対してデータ・オブジェクトを関連付け（bind）すると、データの変化に伴って自動でディレクティブの表示も変化する。ユーザが画面操作してディレクティブの状態が変化すると、データ側に自動反映される。

• ルーティング：URLと対応するControllerを紐付けること。

AngularJSを使用したアプリケーション構築の手順（例）① angular.module(...)でアプリのためのモジュールを定義する。

② モジュールのconfig(...)で、アプリ初期化時のロジックを登録する（例えばここでURLとコントローラを紐付ける）。

③ モジュールのfactory (...)でファクトリ関数（アプリ内で共通に利用するデータの初期化ロジック）を登録する。

④ モジュールのservice(...)でサービス初期化関数（アプリ内で共通に利用するサービス・オブジェクトの初期化ロジック）を登録する。

⑤ モジュールのcontroller(...)でコントローラ関数（データ・バインドを行うロジック）を登録する。

⑥ アプリの起点ページ、JSコードをロードするHTMLを作成する。

⑦ アプリのページ遷移で利用されるテンプレートHTMLを作成する。

TypeScriptのサンプル・アプリ（*）

• 三度登場のTODOアプリを今度はAngularJS化。

• AngularJSを型安全に扱うためd.tsファイルを導入。

• jQueryやDOM関連操作が完全に消滅。

• 前回アプリのapp.jsと今回アプリのapp.tsを比較してみよう。

• TypeScript対応IDE/エディタでapp.tsを開き編集してみよう。

＊サンプル・アプリのリポジトリはこちら： https://github.com/mizukyf/jserclass3ng

サンプル・アプリのファイル構成①• app.tsが開発者がコーディン

グしたもの

• 〜.d.tsはjQueryやAngularJSのAPIをTSから型安全に利用するための型定義ファイル

• index.htmlはJS/CSSをロードしている以外ほとんど中身のないものになっているが、ng-〜で始まる属性が付与されている（*）。

＊ここで詳細には立ち入らないがこの属性はAngularJSの用語で「ディレクティブ」と呼ばれる。

サンプル・アプリのファイル構成②• app.jsはtscが生成したJSコー

ドのファイル

• app_v0.jsはTS化前のJS。

• angular〜.jsはAngularJSの標準モジュールのファイル

• ui-bootstrap〜.jsはAngularJSとBootstrapを仲立ちするモジュールのファイル

• tplにはページ遷移で利用されるテンプレが格納されている

何が変わった？（再掲）

クライアント側

• クライアント側にMVCの全要素が移動し、データ永続化以外のすべての制御を掌握。

• ページ遷移すらもクライアント側で閉じた処理になる。

サーバ側

• VC要素がほぼ消滅。多様なリクエストを処理する複雑なロジックはなくなった。

• XML/JSONを受け付けるRESTful APIがデータの永続化とTXを担保。

注：サンプル・アプリではサーバ側の変化はわかりに

くい。

さいごに

JavaScriptの現在/今後わりと楽観的に説明してきたけど…• JavaScriptの言語仕様理解が重要であることは疑い得ない。

• jQueryのような軽量FWの将来性はなんとも言えない。

• AngularJS（1.x）のようなクライアントMVCは前のめり気味であり、JSの言語的/ランタイム的課題に起因する欠点に目を瞑る覚悟なしに導入はできない。

• TypeScriptのようなaltJSはそれぞれ個性的なアプローチをとるが、いずれも厄介な問題を抱えている。5年後・10年後に「○○Scriptが第2のRuby/CoffeeScriptであった」ということになりかねない。

JavaScriptのもっとも「うんざり」な部分は、しかしもっとも堅実な部分でもあるということ…。

再び サーバ/クライアントそれぞれの発展/分化の系譜

Ajax

RESTfulAPI

DOMによる動的書き換え

↑サーバ・サイド

↓クライアント・サイド

CoC

altJS

MVC

altJS+MVC?

Comet（WebSocket）

これが福音なのか?!

あ、そういえばこんなのもありましたね…

さてまあどうなることやら…

余談）考えてどうなるものでもないけど…• 盛者必衰なのはまあよい。

• 問題は（みんなで）選択を誤ったことが後から知られてきて、それでも緩慢な死の過程を生きていかなくてはならない苦痛。

• なにしろ、IE6のお葬式が始まったあと、彼がほぼ墓穴に収まるまでにおよそ10年の歳月を要した。

• そうしてなぜか思い出される湯浅誠のあの本…。

• 福音を期待するのでなく自分たちでつくっていかないとってことね？

参考文献TypeScriptについて• 『JavaScriptプログラマのた

めの 実践的TypeScript入門』

• スラスラ読めてTSの酸いも甘いも何となく分かる。

• String Literal型が紹介されるあたりで、「JSと互換性を保ちつつ型を導入する」という試みのとてつもない困難さがよくわかります。

参考文献AngularJSについて• 『AngularJS アプリケー

ションプログラミング』

• AngujarJS 1.x系のコアAPIと標準モジュール、それらを利用したWebアプリのつくりかたが一通り載っている。

おしまい