JSer Class #3
•
0 gefällt mir•841 views
「JSer Class - JavaScriptの基礎と軽量フレームワーク」と題して職場で開催した勉強会の資料の第3回分。
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (18)
Andere mochten auch
Andere mochten auch (19)
Ähnlich wie JSer Class #3
Ähnlich wie JSer Class #3 (20)
JSer Class #3
- 2. 目的 • 一般的観点 • Webアプリケーション開発のなかで存在感を増し続けるJavaScriptに ついて、「なんとなくわかる」でない知識を身に付ける。 • JavaScriptのメリット、デメリット、代替技術について知ることで、 保守/開発の生産性や品質を向上させる。 • 特殊的観点 • 数カ月後に身近な存在となる某クライアントサイドMVCライクなアプ リケーションの保守/開発のための基礎知識を得る。 再掲
- 3. 開催概要 • 開催日時 • 3/2（水）〜 毎週水曜 19:30〜21:30 全3回予定 • 会場 • コラボレーションスペース（N・W） • コンテンツ • 第1回 JavaScriptの言語仕様 • 第2回 DOMとXmlHttpRequest、軽量フレームワーク • 第3回 クライアントサイドMVC 再掲
- 4. 参考情報 • サイト • 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 再掲
- 6. 前回学んだこと • DOM/Event/XHRの概要 • prototype.js/jQueryの基本的な概念と使い方 • 軽量FWの存在意義 • 関数（とくにそのスコープと変数束縛）の活用方法 兎にも角にも 関数関数関数…。
- 11. 変わらなかったもの① クライアント側のプログラムはJavaScript • 規模の拡大に伴いJSの性質のことごとくが悪く働く結果に… • package/moduleが存在しない • 動的型付けである • classベースのOOPでない • 可視性の制御ができない • ほぼあらゆる変数/プロパティが再代入できてしまう • 結果IDEによるサポートが提供できない • 上書きによる既存ロジックの破壊のリスクがある • ようするに組織的開発にまったく向かない （Rubyよりマシ、というレベル）
- 14. HTML JavaScript シームレスなページ遷移の障碍 → サーバ・サイドクライアント・サイド ← Persistence ModelController View Ajaxはあくまで副 次的なコンテンツ のやり取りを担当 HTTP GET/POST ページ遷移時は サーバ側へのリク エストを行う
- 15. 変わらなかったもの（再び） ① クライアント側のプログラムはJavaScript →プログラミング言語の課題 ② ページをつくるのはサーバ側のプログラム →アプリケーション設計（デザイン）の課題
- 17. altJS（alternative JS） • 新しい千年紀の最初の10年が終わらんとするころ登場。 • その名の通りJavaScriptを置き換えようとする思想/実践の総称。 • 一般にコンパイラがJavaScriptコードを生成する。 • ただし動機はいろいろ、有用性もいろいろ。 それにしても センスのない タイポグラフィ…
- 18. altJSの動機/形態 • 勉強会で紹介してきた種々の課題克服 • JavaScriptコーディングの省力化 • コンパイラ言語との統合 構文/パラダイム を置換え 構文/パラダイム を拡張
- 19. 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
- 20. altJSの実行時エラー解析 • altJSには以下の2つのコードが存在することになる： A) もともとのソースコード（非JS） B) コンパイル後のソースコード（JS） • 実行時のエラーはもちろんB側で起きる。 • エラーを解析するには、B側のコードのエラー箇所がA側のコー ドのどこに対応するかを知る必要がある。 • この対応付けを実現するのが、コンパイラにより生成され る.mapファイル（*）。 • .mapに対応したブラウザではエラー発生時にもともとのコード の位置情報を表示してくれる。 ＊ .mapファイルはjQueryなどのライブラリでも利用されている。この場合.mapはライブラリのもとのソースコー ドとそれをminifyしたコードとを対応付ける（たぶん歴史的にはこの利用法が先行する）。
- 21. 余談）ランタイム on ランタイム • Python • IronPython .NETランタイムで稼働するPython • Jython JVM上で稼働するPython • Cython コンパイルされC言語化されるPython • PyPy Pythonインタプリタ上で稼働するPython • Ruby • JRuby JVM上で稼働するRuby。CRubyより早い？ • Erlang • Elixir Erlangランタイム上で稼働するRubyライクな言語 研究目的、既存リソー スとの統合目的など いろいろな動機
- 22. TypeScriptとは何か？ • Microsoftが開発。 • JavaScriptのスーパーセット ＆ ECMAScript 6+の先行実装。 • Windows/Linux/Mac OS X向けにコンパイラが提供されている。 typescriptlang.org
- 24. TypeScriptの難しさ • TSを知るにはまずJSを知らないと（絶対にではないが…）。 • 問題が起こった時の分析がしにくいケースがある（mapファイ ルをサポートしないブラウザで）。 • 非常に強力な型概念が「生産性と品質を向上」とともに「従来 のJSコードとの統合」を実現してくれる反面やはり難解。
- 25. TypeScript言語仕様 基本型 • string JavaScriptのstring • number JavaScriptのnumber • boolean JavaScriptのboolean • any 変数/戻り値型。あらゆる型のサブタイプ。 • void 戻り値型。「戻り値がない」の意。 • enum データ/変数/戻り値型。numberのサブタイプ。 • Array<T> JavaScriptのArray。 • null/undefined 説明省略！ なぜかここだけ C#チックという謎。 any/voidはデータ型 ではなく変数型である。 当たり前だが、念のため。
- 27. TypeScript言語仕様 インターフェースたち（複数形?!） • プロパティ宣言を持つインターフェース（ふつう） • オプションのプロパティの宣言を持つ 〃 （独特） • 関数インターフェース（関数オブジェクトのための定義） • コンストラクト・インターフェース（初期化子の定義） • 配列/辞書インターフェース（添字型と戻り値型の定義） • ハイブリッド・インターフェース（関数でありオブジェクト） NOTE TypeScriptのインターフェース概念はあきらかにJavaや C#よりも複雑なものになっている。理由は明解で、 JavaScriptとの整合性を保つため。安堵と倦怠を同時に感 じさせられるという、複雑な気分である。
- 28. TypeScript言語仕様 クラス • プロパティ（フィールド/メソッド）の宣言を持つ。 • プロパティはprivate/publicの別を持つ。 • コンストラクタを持つ。 • アクセサ（C#におけるプロパティに相当）を持つ。 • 添字アクセサを定義できる。 • オーバーロードの仕方がだるい。 • staticプロパティの宣言を持つ。 追記 ここでいきなり皆さん を意気阻喪させたくな いので、列挙だけ…。
- 29. TypeScript言語仕様 その他重要な要素 • 型推論（機械的に推論可能な型表記は省略可能） • 構造的部分型（所定のメンバを持つなら何型だろうと不問） • モジュール（名前空間を実現、公開するAPIを制限） • アロー関数（=>） • ジェネリクス（もちろんクラス/メソッドの両レベルで可能） • 宣言ファイル（〜.d.ts）による既存コードとの統合（*） • constの再定義（今度こそ再代入不可能） ←「その他」≒早くも力尽きた。 ＊ jQueryやAngularJSなどの既存リソースのためのd.tsファイルは有志により作成されたものがGithub上で公開さ れている： https://github.com/DefinitelyTyped/DefinitelyTyped
- 30. TypeScript Handbook • http://www.typescriptlang.org/Handbook （部分抄訳：http://m12i.hatenablog.com/entry/2016/03/16/112829） • ここまで列挙したTypeScriptのビルディング・ブロックがサン プルとともに紹介されている。 • 少なくともBasic Types〜Classesまでは「すっきりした印象」 を受ける（Modules以降雲行きが怪しくなる）。 追記
- 31. TypeScriptのサンプル・アプリ（*） • 前回も登場したTODOアプリをTypeScript化。 • jQueryを型安全に扱うためd.tsファイルも導入。 • 前回アプリのapp.jsと今回アプリのapp.tsを比較してみよう。 • TypeScript対応IDE/エディタでapp.tsを開き編集してみよう。 ＊サンプル・アプリのリポジトリはこちら： https://github.com/mizukyf/jserclass3ts
- 32. サンプル・アプリ のファイル構成① • app.tsが開発者がコーディン グしたもの • jquery.d.tsはjQueryのAPIを TSから型安全に利用するため の型定義ファイル • app.jsはtscが生成したJSコー ドのファイル • app.js.mapは元になったJS コードとのマッピングのため のファイル
- 34. サンプル・アプリのコード① d.tsによる既存リソースとの統合 • jquery.d.tsによりjQueryに明確な型が与えられている。 • インターフェースの違いからJQueryStaticとJQuery（次スライ ドで登場）という区別がある点に注意。 (function($ : JQueryStatic) { // ...ページ・ロード中に実行される... $(document).ready(function() { // ...ページ・ロード後に実行される... }); })(jQuery);
- 35. サンプル・アプリのコード② 変数/定数と型推論 • 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);
- 36. サンプル・アプリのコード③ クラスの定義とショートハンド • TodoTaskクラスの宣言部。 • コンストラクタの宣言では、仮引数の定義と同時に public/privateフィールドを定義することができる。cf. Scala class TodoTask { constructor( public id :number, public title :string, public createDate :string) { } }
- 37. サンプル・アプリのコード④ 関数の仮引数/戻り値の型指定 • 仮引数も戻り値も型指定された関数。 • 戻り値は関数のコード本文から推論されるのでvoidは省略可能。 // ↓は function addTask (task :TodoTask) : void と同義 const addTask = function(task :TodoTask) :void { // ... $.ajax({ // ... }); });
- 38. サンプル・アプリのコード⑤ 構造的部分型 • 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(""); });
- 39. 補足）構造的部分型 • Structural Subtype（Subtyping）。 • 型の宣言によらず、インスタンスが持っている"形"（Shape。 JSの場合ようはプロパティ）によってサブ型と判定されること。 • 「ダックタイピング」（アヒルに見えるしアヒルのようにガー ガー鳴くならアヒルに違いない）を実現するための仕組み。 • Python/RubyではAPIの柔軟性のためダックタイピングが推奨 されるが「だからAPI開発者はまず引数として渡されたオブ ジェクトのメンバーの存否をチェックして…」となる。しかし ScalaやTypeScriptでは「そういうことはコンパイラに任せて ください」となる。
- 40. 付録）開発環境構築 コンパイラの導入 • 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
- 41. 付録）開発環境構築 Hello World • まずgreeter.html をつくる： <!DOCTYPE html> <html> <head><title>TypeScript Greeter</title></head> <body></body> <script src="greeter.js"></script> </html>
- 42. 付録）開発環境構築 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);
- 43. 付録）開発環境構築 Hello World • コンパイルしたあとhtmlファイルをブラウザで開く： $ tsc greeter.ts
- 44. 付録）開発環境構築 エディタの選定 • もちろんVisual Studio（VS）はTypeScriptに対応。VSのユー ザは特段の準備もなくコーディングを開始できる。 • ふだんVSを使用していないという方も、もし開発マシンが Windowsに限定されるなら導入を検討もよし。 • 一方そうでない方はEclipseやWebStormのようなIDE、Atomや Visual Studio Code（VS Code）の導入を検討。現段階でおす すめはVS Code。 • それぞれのツールについてまとめたのが次表。
- 45. 付録）開発環境構築 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
- 46. 付録）開発環境構築 VS Codeおすすめの理由 • Linux OSやMac OS Xでも利用できる。 • 初期費用がかからない。 • 言語と同じ開発元でサポートに信頼がおける。 • 現時点でツールの安定性が高い。 • 独自拡張など便利だが非公式のナレッジが不要。 • EclipseなどのIDEと併用する上で機能が十分にシンプル。
- 47. 付録）開発環境構築 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）でビルド実行。
- 49. ロジックの分散/MVCのいびつ化 /シームレスなページ遷移の障碍 → サーバ・サイドクライアント・サイド ← Persistence ModelController View HTML JavaScript HTTP GET/POST 課題（再掲） JSがMVCのロジックの一部を負担し始め、動的要素が 両サイドに存在、設計/開発/保守が煩雑化。 Ajaxはあくまで副次的なコンテンツのやり取りを担当、 ページ遷移時はサーバ側へのリクエストを行う。
- 50. RESTful API クライアントサイドMVC の基本的な構成 → サーバ・サイドクライアント・サイド ← Persistence Model HTML JavaScript HTTP GET/POST ModelController View
- 51. 補足）RESTful API • REST: Representational State Transfer。 • RESTful API: RESTの原則に準じたAPI。 • そもそもRESTの概念がよくわからない＆一定していないので RESTfulの定義もあやふやっぽい（*）。 • しかしようするに「標準化されたスキーマ情報を持たない（**） Web サービスで、リソースのCRUDをHTTPメソッド POST/GET/PUT/DELETEで表現するもの」。 • ─って、ますますよくわからない？ ＊ 白状すると少なくとも「あやふや」な原因の半分は私の勉強不足なだけだと思います。 ＊＊ これは「スキーマがない」ということではない。「スキーマを機械/プログラムが理解可能な形式で表現す ることはしない」ということである。RESTful API登場以前から一般に利用されてきたSOAPというプロトコルで はWDSLというXMLのサブセットで、クライアント/サーバがやり取りするデータの形式を定義している。
- 52. 補足）RESTful API TodoTaskオブジェクトの場合 • 例えばサンプル・アプリの場合、以下のような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を削除する。
- 53. 何が変わった？ クライアント側 • クライアント側にMVCの全要 素が移動し、データ永続化以 外のすべての制御を掌握。 • ページ遷移すらもクライアン ト側で閉じた処理になる。 サーバ側 • VC要素がほぼ消滅。多様なリ クエストを処理する複雑なロ ジックはなくなった。 • XML/JSONを受け付ける RESTful APIがデータの永続 化とTXを担保。
- 54. いやまあ、 理論的にはそうなんだけど… • 実際問題としてTXを担保したAPIデザインがむずい。 • JavaScriptであれもこれも実装となるとJava/C#の既存リソー スが再利用できない。 • クライアント側でエラーが起きた時もはやサーバ側には何も残 らない。 • JavaScriptの言語的な課題（勉強会を通じて確認してきた）が ずっしり重ーくのしかかる。
- 55. 新たな課題 TX担保の難しさ • 実際問題としてTXを担保したAPIデザインがむずい。 • ステートレス通信であるHTTPを利用している以上、クライアント側 にはTXの完全性を担保する手段がない。 • よってその担保はサーバ側に委ねられ、適切な粒度で「リソース」を 扱う（URLとして表現する）必要が出てくる。これが難しい。 • ただこの壁を乗り越えるとクライアント側の拡張性が飛躍的に高まる。 • 「PC向けにはWebアプリを提供しつつ、スマホ向けにはネイティブ・ アプリを提供する」など。
- 56. 新たな課題 既存リソースの再利用 • JavaScriptであれもこれも実装となるとJava/C#の既存リソー スが再利用できない。 • しかたないので高度な操作はやはりRESTful APIの向こう側に封じ込め ることにしよう。 • Scala.jsのような標準API丸ごとを移植しようというような大それた試 みを以ってしても、サードパーティ製の既存リソースは移植できない。
- 57. 新たな課題 エラーログが残らない • クライアント側でエラーが起きた時もはやサーバ側には何も残 らない。 • ということは「エラーが起きる条件」を再現できる環境やテストデー タの準備が必要になる。 • また今回まったく取り上げられていないが、JavaScript用の単体テス トFWなどを用いてくだらないバグをあらかじめ完全に潰してやること も必要になる。 • というかそれくらいでしか対策できない。
- 59. クライアントサイドMVCの例 AngularJS • Googleが開発を主導するクライアントサイドMVCフレーム ワーク（*）。略号は"ng"らしい。 • バージョン1.x系はJavaScript、2.x系はTypeScriptで開発されて いる。 • モジュール構成をとっており、公式の機能であってもコア以外 は必要に応じて読み込む形式。 ＊ 参考資料を読むと「MVCではなく○○だ」的な記載もそここにあるのだが、あまり分類を細分化したり再定義 したりする意味を感じないので、ここではともかく単にMVCとしておく。
- 60. AngularJSの重要概念 • DI：依存性注入の概念をJSの世界に導入。 • DOMの隔離：もはやDOMを直接操作したりせず、より上位の ディレクティブと呼ばれる単位で制御を行う。 • バインド：ディレクティブに対してデータ・オブジェクトを関 連付け（bind）すると、データの変化に伴って自動でディレク ティブの表示も変化する。ユーザが画面操作してディレクティ ブの状態が変化すると、データ側に自動反映される。 • ルーティング：URLと対応するControllerを紐付けること。
- 61. AngularJSを使用した アプリケーション構築の手順（例） ① angular.module(...)でアプリのためのモジュールを定義する。 ② モジュールのconfig(...)で、アプリ初期化時のロジックを登録する （例えばここでURLとコントローラを紐付ける）。 ③ モジュールのfactory (...)でファクトリ関数（アプリ内で共通に利 用するデータの初期化ロジック）を登録する。 ④ モジュールのservice(...)でサービス初期化関数（アプリ内で共通 に利用するサービス・オブジェクトの初期化ロジック）を登録す る。 ⑤ モジュールのcontroller(...)でコントローラ関数（データ・バイン ドを行うロジック）を登録する。 ⑥ アプリの起点ページ、JSコードをロードするHTMLを作成する。 ⑦ アプリのページ遷移で利用されるテンプレートHTMLを作成する。
- 62. TypeScriptのサンプル・アプリ（*） • 三度登場のTODOアプリを今度はAngularJS化。 • AngularJSを型安全に扱うためd.tsファイルを導入。 • jQueryやDOM関連操作が完全に消滅。 • 前回アプリのapp.jsと今回アプリのapp.tsを比較してみよう。 • TypeScript対応IDE/エディタでapp.tsを開き編集してみよう。 ＊サンプル・アプリのリポジトリはこちら： https://github.com/mizukyf/jserclass3ng
- 63. サンプル・アプリ のファイル構成① • app.tsが開発者がコーディン グしたもの • 〜.d.tsはjQueryやAngularJS のAPIをTSから型安全に利用 するための型定義ファイル • index.htmlはJS/CSSをロード している以外ほとんど中身の ないものになっているが、 ng-〜で始まる属性が付与さ れている（*）。 ＊ここで詳細には立ち入らないがこの属性はAngularJSの用語で「ディレクティブ」と呼ばれる。
- 64. サンプル・アプリ のファイル構成② • app.jsはtscが生成したJSコー ドのファイル • app_v0.jsはTS化前のJS。 • angular〜.jsはAngularJSの標 準モジュールのファイル • ui-bootstrap〜.jsはAngularJS とBootstrapを仲立ちするモ ジュールのファイル • tplにはページ遷移で利用され るテンプレが格納されている
- 65. 何が変わった？（再掲） クライアント側 • クライアント側にMVCの全要 素が移動し、データ永続化以 外のすべての制御を掌握。 • ページ遷移すらもクライアン ト側で閉じた処理になる。 サーバ側 • VC要素がほぼ消滅。多様なリ クエストを処理する複雑なロ ジックはなくなった。 • XML/JSONを受け付ける RESTful APIがデータの永続 化とTXを担保。 注：サンプル・ア プリではサーバ側 の変化はわかりに くい。
- 66. さいごに
- 67. JavaScriptの現在/今後 わりと楽観的に説明してきたけど… • JavaScriptの言語仕様理解が重要であることは疑い得ない。 • jQueryのような軽量FWの将来性はなんとも言えない。 • AngularJS（1.x）のようなクライアントMVCは前のめり気味で あり、JSの言語的/ランタイム的課題に起因する欠点に目を瞑 る覚悟なしに導入はできない。 • TypeScriptのようなaltJSはそれぞれ個性的なアプローチをとる が、いずれも厄介な問題を抱えている。5年後・10年後に 「○○Scriptが第2のRuby/CoffeeScriptであった」ということ になりかねない。 JavaScriptのもっとも 「うんざり」な部分は、 しかしもっとも堅実な部 分でもあるということ…。
- 69. さてまあ どうなることやら…
- 70. 余談） 考えてどうなるものでもないけど… • 盛者必衰なのはまあよい。 • 問題は（みんなで）選択を誤ったことが後から知られてきて、 それでも緩慢な死の過程を生きていかなくてはならない苦痛。 • なにしろ、IE6のお葬式が始まったあと、彼がほぼ墓穴に収ま るまでにおよそ10年の歳月を要した。 • そうしてなぜか思い出される湯浅誠のあの本…。 • 福音を期待するのでなく自分たちで つくっていかないとってことね？
- 71. 参考文献 TypeScriptについて • 『JavaScriptプログラマのた めの 実践的TypeScript入門』 • スラスラ読めてTSの酸いも甘 いも何となく分かる。 • String Literal型が紹介される あたりで、「JSと互換性を保 ちつつ型を導入する」という 試みのとてつもない困難さが よくわかります。
- 72. 参考文献 AngularJSについて • 『AngularJS アプリケー ションプログラミング』 • AngujarJS 1.x系のコアAPIと 標準モジュール、それらを利 用したWebアプリのつくりか たが一通り載っている。
- 73. おしまい