JavaScriptの過去と現在ガチな JSアプリケーション設計

@kiwanami

Hacker Tackle2015/09/26

@kiwanami

UIデザイン、プログラマー医療系システム開発、研究

経歴と作ったものなど

● 小さい頃：MSXなど● 学生時代：未踏● 仕事：画像解析、業務システム● OSS： Emacsでいろいろ、ブラウザ拡張など

最近 ... JavaScript, Emacs Lisp, Ruby

5つの世界

● パッケージ（サービス）● インターナル● 組み込み● ゲーム● 使い捨て

Joel Spolsky 2002

最近の JS周辺のまとめ

ES6 / ES.next

ブラウザー技術

その他

ES6

● 2015/6/17 published● class● module● scope● arrow function● default param / rest param● 文字列テンプレート● Promise

ES6

● すごく良くなっている– JSからではなくて、いきなり ES6から入門– 今まで書いてた人は、復習と Update

● ES.next– Object.observe

– async/wait

– など

ブラウザ技術

● HTML5 / CSS3● WebSocket● WebWorker● ServiceWorker● WebRTC（ORTC）● その他

– Touch/Pointer、WebAssembly

● 各プラットフォームの事情

Node.js

● サーバーに限らず、ビルドツールなどの JSの実行環境

● Electron

JavaScriptスタイル● 昔

– コピペプログラミング– 設計、構造化無し

● ちょっと前– jQuery, prototype.js → ブラウザ依存の吸収– altJS → JSつらさの回避

● 現代– ES6スタイルならつらくない– ブラウザの JSが十分速い– →大規模化　 　設計・構造化の必要性

JSへの入り方

● Want to learn JavaScript in 2015? — Medium– https://medium.com/@_cmdv_/i-want-to-learn-javascript-in-

2015-e96cd85ad225

● 初心者とすごい人の記事しか無い– 中間の人向けが無い

● とにかく基本– いい本、ビデオ、書いて試せるテキスト– 人のコード読みまくる– いろいろ試して経験する

JSのフレームワーク問題

フレームワーク多すぎ

どれを選ぶべきかわからない

なぜなのか？

→絶賛進化中だから

● カンブリア紀– 正しい現象– 多種多様な進化– その後淘汰

● この先生きのこるためには？

歴史から学ぶ

GUI周辺の歴史１● 〜 80年代

– GUI誕生– 68年マウス発表– GOTO is considered harmful

– 72年アルト● アルゴリズムとデータ構造

– 80年Smalltalk● GUIとOOPの融合

– 86年OOPSLA● OOPのシンポジウム

– 87年HyperCard

GUI周辺の歴史２

● 90年代– OOPの発展

● デザインパターン● MVC

– スタンドアロンアプリ全盛期● サバクラ、 2層

– IDE開発競争

GUI周辺の歴史３● 00年代前半

– CGI、Webアプリのブレイク– 3層、サーバー完結– Flash

● 00年代後半– JS盛り上がり– jQuery

● 10年代– スマートフォンアプリ– SPA

多様性と淘汰の歴史

● GUI誕生後、コンポーネント、操作方法、パターンの整理

● アルゴリズム、データ構造、デザインパターン● IDE開発競争● Webフレームワーク

– ポスト Struts

生き残っているもの

● デザインパターン● アルゴリズム、データ構造● ユーザーインタフェース設計● Visual Studio● Emacs/Vim● lisp

生き残っているもの● デザインパターン →　 　抽象化した設計パターン

– 言語やパラダイムによる● アルゴリズム、データ構造 →　 　学術的に研究されている● ユーザーインタフェース設計 →　 　人間（本質は変わらない）との接点– デバイスの進化により新しい提案

● Visual Studio →　 　金と気合● Emacs/Vim →　 　愛● lisp →　 　神

生き残るのに大事なこと

大企業だからといってあてにならない！！

どうすればよいか？

● 事前にどれが生き残るかわからない– 多様性の時代と淘汰のタイミング– 淘汰ではなくて衰退の可能性

● UIデザイン、基本設計は変わらない– 手段が変わっているだけ

● 圧倒的金や愛が感じられるもの

現代の JSのフレームワークについて

そもそも「フレームワーク」とは？

Webサーバー FWの機能● ルーター・ディスパッチ

– URL 解析 / コントローラー選択 / 呼び出し● パラメーターコンバート● 入力バリデーション、自動制御● レスポンス制御

– リダイレクト / テンプレート呼び出し● セッション管理● その他

– ORM / 認証

クライアント側に求められる機能とは？

● MVC/MVVM● テンプレート？● コレクション、ストア管理？● 全体の制御？

→フォームの制御？

GUI開発設計に必要なもの

● レイヤーアーキテクチャ● 通知（ Pub/Sub, Observer, Signal）● 粗結合

→すなわちMVC

● コンポーネント– 境界、汎用化、共通化

● 状態管理

求められているのはソフトウエア設計

● 抽象化● カプセル化● 情報隠蔽● モジュール化● 関心の分離● 結合度と凝集度● インタフェースと実装の分離● 参照の一点性● 分割統治

目的と手段、理由● http://steps.dodgson.org/b/2014/12/11/why-is-real-dom-slow/

フレームワーク自作のすすめ

● いちから全部やってみる● 他のフレームワークの実装が理解できる● 自作した上で他のフレームワークに乗ることもある

● MVC自作の本– → 既に書いてた

Isomorphic、 flux、 VirtualDOM（枝刈）

今のフレームワークに必要なもの

● 状態管理● コーディング規約、多人数ルール● 教育、使用の判断● ドキュメント

今後必要になると思われるもの

● ルーティング・画面遷移前後での処理– 状態の受け渡し、記憶– アニメーションの接続

● クライアント側のMとサーバー側のM– アプリ全体の設計でMと更新通知を考える– トランザクション、排他制御

今後必要になると思われるもの２● 非同期処理の設計

– Promise, async/wait の先– デッドロック、スレッドの闇– 同期・非同期

● →同期・待つ　 　人間が詰まる

– 非同期・待たない● push/pull どこかが詰まる

→ flow control / backpressure

– 処理の流れではなく、データの流れを定義● ロックの要らない設計● 並行処理の設計パターン

結局フレームワークはどうなのか？

● Vanillaがおすすめ● コードの寿命、チームの寿命を考える● フレームワークのコードを断片的にも読むぐらいは必要

● 覚悟の問題– フレームワークもメンテする– スクラッチから作りなおしてもいいやと思える

まとめ

● 最近の JSの状況と入り方の紹介● GUIの JSの混乱状況の整理● 今後の JSでのアプリケーション開発のヒントの提案