Download as PDF, PPTX
Uploaded bymizuky fujitani
PDF, PPTX843 views
JSer Class #3
「JSer Class - JavaScriptの基礎と軽量フレームワーク」と題して職場で開催した勉強会の資料の第3回分。
Recommended
![XPages Day 2013 [B-3] XPages開発を始める Notes技術者のためのWeb技術概論](/image.pl?url=https%3a%2f%2fcdn.slidesharecdn.com%2fss_thumbnails%2fxpagesday2013-b3-131104200209-phpapp01-thumbnail.jpg%3fwidth%3d640%26amp%3bheight%3d640%26amp%3bfit%3dbounds&f=jpg&w=240)
More Related Content
What's hot
Viewers also liked
Similar to JSer Class #3
JSer Class #3
- 1.
- 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再掲
- 5.
- 6.前回学んだこと• DOM/Event/XHRの概要• prototype.js/jQueryの基本的な概念と使い方•軽量FWの存在意義• 関数（とくにそのスコープと変数束縛）の活用方法兎にも角にも関数関数関数…。
- 7.
- 8.
- 9.
- 10.
- 11.変わらなかったもの①クライアント側のプログラムはJavaScript• 規模の拡大に伴いJSの性質のことごとくが悪く働く結果に…• package/moduleが存在しない•動的型付けである• classベースのOOPでない• 可視性の制御ができない• ほぼあらゆる変数/プロパティが再代入できてしまう• 結果IDEによるサポートが提供できない• 上書きによる既存ロジックの破壊のリスクがある• ようするに組織的開発にまったく向かない（Rubyよりマシ、というレベル）
- 12.
- 13.
- 14.HTMLJavaScriptシームレスなページ遷移の障碍→ サーバ・サイドクライアント・サイド ←PersistenceModelControllerViewAjaxはあくまで副次的なコンテンツのやり取りを担当HTTPGET/POSTページ遷移時はサーバ側へのリクエストを行う
- 15.
- 16.
- 17.altJS（alternative JS）• 新しい千年紀の最初の10年が終わらんとするころ登場。•その名の通りJavaScriptを置き換えようとする思想/実践の総称。• 一般にコンパイラがJavaScriptコードを生成する。• ただし動機はいろいろ、有用性もいろいろ。それにしてもセンスのないタイポグラフィ…
- 18.altJSの動機/形態• 勉強会で紹介してきた種々の課題克服• JavaScriptコーディングの省力化•コンパイラ言語との統合構文/パラダイムを置換え構文/パラダイムを拡張
- 19.altJSの例言語名 開発元 説明CoffeeScriptJeremyAshkenasaltJSの嚆矢となった言語。便利な構文/ショートハンドの導入。それと不可分のコードの曖昧性の急拡大（XML/JSONに対するYAMLのようなもの）。ようするに状況は却って悪化。ClojureScript Rich Hickey JVM上で稼働するLisp方言であるClojureのコードを元にJavaScriptコードを生成する。Clojureの売りは並列分散処理のはずだが…。Dart Google クライアントサイドにランタイムが必要。つまりJavaScriptの糖衣構文ではなく、独立した言語。TypeScript Microsoft JavaScriptのスーパーセットであり、ECMAScript v6以降の先行実装でもある。後程さらに詳しく取り上げる。Scala.js Écolepolytechniquefédérale deLausanne/TypesafeJVM上で稼働する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
- 23.
- 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はデータ型ではなく変数型である。当たり前だが、念のため。
- 26.
- 27.TypeScript言語仕様インターフェースたち（複数形?!）• プロパティ宣言を持つインターフェース（ふつう）• オプションのプロパティの宣言を持つ〃 （独特）• 関数インターフェース（関数オブジェクトのための定義）• コンストラクト・インターフェース（初期化子の定義）• 配列/辞書インターフェース（添字型と戻り値型の定義）• ハイブリッド・インターフェース（関数でありオブジェクト）NOTETypeScriptのインターフェース概念はあきらかに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コードとのマッピングのためのファイル
- 33.
- 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.Scalaclass 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をつくる：interfacePerson {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月時点ではこの自動ビルドがバグっている。VSCode Microsoft社が提供。Atomと同じElectronをベース。WindowsはもちろんLinuxやMac OS Xでも使える。自動ビルドには対応していないがショートカット・キーを使って任意のタイミングでビルドできる。ビルドはtsconfig.jsonに基づくもの、固定パラメータに基づくものいずれにもでき、その点の柔軟性は高い。＊ 詳しくはこちらも参照のこと： http://m12i.hatenablog.com/entry/2016/03/13/085936
- 46.付録）開発環境構築VS Codeおすすめの理由• LinuxOSや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）でビルド実行。
- 48.
- 49.ロジックの分散/MVCのいびつ化/シームレスなページ遷移の障碍→ サーバ・サイドクライアント・サイド ←PersistenceModelControllerViewHTMLJavaScriptHTTPGET/POST課題（再掲） JSがMVCのロジックの一部を負担し始め、動的要素が両サイドに存在、設計/開発/保守が煩雑化。 Ajaxはあくまで副次的なコンテンツのやり取りを担当、ページ遷移時はサーバ側へのリクエストを行う。
- 50.RESTful APIクライアントサイドMVCの基本的な構成→ サーバ・サイドクライアント・サイド←PersistenceModelHTMLJavaScriptHTTP GET/POSTModelControllerView
- 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 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を削除する。
- 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#の既存リソースが再利用できない。• しかたないので高度な操作はやはりRESTfulAPIの向こう側に封じ込めることにしよう。• Scala.jsのような標準API丸ごとを移植しようというような大それた試みを以ってしても、サードパーティ製の既存リソースは移植できない。
- 57.新たな課題エラーログが残らない• クライアント側でエラーが起きた時もはやサーバ側には何も残らない。• ということは「エラーが起きる条件」を再現できる環境やテストデータの準備が必要になる。•また今回まったく取り上げられていないが、JavaScript用の単体テストFWなどを用いてくだらないバグをあらかじめ完全に潰してやることも必要になる。• というかそれくらいでしか対策できない。
- 58.
- 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のもっとも「うんざり」な部分は、しかしもっとも堅実な部分でもあるということ…。
- 68.
- 69.
- 70.余談）考えてどうなるものでもないけど…• 盛者必衰なのはまあよい。• 問題は（みんなで）選択を誤ったことが後から知られてきて、それでも緩慢な死の過程を生きていかなくてはならない苦痛。•なにしろ、IE6のお葬式が始まったあと、彼がほぼ墓穴に収まるまでにおよそ10年の歳月を要した。• そうしてなぜか思い出される湯浅誠のあの本…。• 福音を期待するのでなく自分たちでつくっていかないとってことね？
- 71.参考文献TypeScriptについて• 『JavaScriptプログラマのための 実践的TypeScript入門』•スラスラ読めてTSの酸いも甘いも何となく分かる。• String Literal型が紹介されるあたりで、「JSと互換性を保ちつつ型を導入する」という試みのとてつもない困難さがよくわかります。
- 72.参考文献AngularJSについて• 『AngularJS アプリケーションプログラミング』•AngujarJS 1.x系のコアAPIと標準モジュール、それらを利用したWebアプリのつくりかたが一通り載っている。
- 73.