CoffeeScript/JavaScriptで "write once, run anywhere" 的な話（MeteorとRendr）
やりたいこと：
ドメイン駆動設計の4層アーキテクチャ的に言うと「分厚いドメイン層」を作りたい。「やむを得ず複雑になるビュー層」は仕方ない。「アプリケーション層」は極力薄くしたくて、内部DSLみたいにしたい。それはつまりドメイン層が美しいインターフェイスを持つことを意味しますが。そしてインフラ層は自前で作らない。
そんな感じのことがやりたい。さて、以下はそれをCofeeScriptでやろうという試行錯誤の途中経過の話です。
同じJSコードがサーバーとクライアントで共有されるような仕組みにしたいと思っています。ドメインモデルのコードはプラットフォーム非依存なpure JavaScriptコードなのだから。
Java には “write once, run anywhere” というコピーがあります（した？）。 POJO (plain old Java object) ならそうなりますよね。同じことを JavaScript でやろうと。 JSON なんか面白くて、JavaScript 由来のポータブルなオブジェクト・シリアライズ表現なわけですね。
最近やってること：
Meteor.jsみたいなserver-client agnosticなフレームワークが欲しい。Meteorはちょっとクセが強すぎて、もっと素性のいいフレームワークがいい。そう、Backboneみたいな…
AirBnbが作ったBackboneベースのRendr、よく出来ているらしい。（調査・評価中）
そもそもBackboneってブラウザに依存してるんだっけ？
あ、jQueryを読み込んでるじゃん（イマココ
結局はRenderを使わせて頂くのがラクかなーと思いつつあるところです。
これまでの経緯 ver. 3 (2013-12-05)
から約半年、ブログを更新してませんでした。
いまはCoffeeScriptでフレームワーク開発してます。
やろうとしてること自体は一貫してるんですが。
要するに「ウェブMVC」ではなく「PCやスマホのMVC」がやりたい。
ウェブで言えば、やっぱりSmalltalkのSeasideみたいな。
それをモダンなreactive programmingやpub/sub、つまりMeteor的な仕組みで実現していこうと。
（気にしてるのはAngularJS、bone.io、Rndrなど）
いずれJava/Xtend+GWT+Vaadinに行くかもしれません。
ともあれ、しばらくはCoffeeScript/JavaScriptで出来ることを研究してみます。
フレームワーク開発ワークショップ
12月5日（木）時点で10回：
- 第1回: 11月5日（火） Facebookイベント
- 第2回: 11月8日（金） Facebookイベント
- 第3回: 11月12日（火） Facebookイベント
- 第4回: 11月15日（金） Facebookイベント
- 第5回: 11月19日（火） Facebookイベント
- 第6回: 11月21日（木） Facebookイベント
- 第7回: 11月26日（火） Facebookイベント
- 第8回: 11月28日（木）非公開
- 第9回: 12月3日（火）非公開
- 第10回: 12月5日（木）非公開
これまでの経緯 ver. 2 (2013-06-26)
なにぶん趣味性の高い案件でもあり、「技術選定」と称して新しい言語とIDEを学ぶのが楽しくて仕方ない状況になりつつありますが、あくまでも目的は見失わないよう心がけております（笑）
- ゼロベース会計システムの開発を決定（2012年12月）
- Play + Scalaを検討（2013年1月）
- DCI、継続的デリバリーを勉強
- Smalltalk + Seasideを検討（2013年2月）
- UIコンポーネント指向のアーキテクチャを構想（2013年3月）
ここまでは旧ver.（これまでの経緯 ver. 1 (2013–03–06)）のダイジェスト。ここからが直近3ヶ月の経緯:
- Smalltalkを断念してDartを検討（2013年4月）
- TypeScript + Meteorを検討（2013年6月）
- Haxe + Meteorを検討（2013年6月）
右往左往しまくりですが（笑）、ぼちぼち流浪の旅も終着点が近づいている気がしています。Haxe + Meteorでアプリケーション開発のためのアーキテクチャを設計しているところです。
Haxe + Meteor
TypeScriptとMeteorでアプリケーション開発に着手する直前に、第2回Shimokita.jsで新井さんのHead First Haxeという発表を聴いて、Haxeへの興味が高まっています。
ちなみに、Meteorの採用は決定しました。 TypeScript + Meteor から Haxe + Meteor に切り替えつつあるのが現状です。
前提
やりたいことは、
- IA DSLとしての抽象化CSSとドメイン駆動設計
- アーキテクトがリードするUIプロトタイピング（OOSass と JavaScript MVC と DDD）
- UIコンポーネント単位のエンド・ツー・エンドの開発パイプライン
です。これまでの経緯は『これまでの経緯 ver. 2 (2013–06–26)』の通りですが、要約すると
を検討してきました。
Haxe
Haxeの売り文句は “One language, everywhere” です。Javaが登場時に “Write once, run anywhere” と言っていたのに似ています。
前回「HaxeはTypeScriptより魅力的ではありませんでした」と書いたのですが、考えを改めました。よくよく調べると、じつに魅力的な言語です。その魅力については省略しますのでHead First HaxeやFIRST STEP to Haxe/JavaScriptをご覧下さい。
FlashDevelop
さて、まずはHaxeの開発環境です。静的型付け言語のメリットを活かすにはIDEが必要だと考えています。TypeScriptならVisualStudioですが、HaxeならFlashDevelopがいいようです。余談ですが、HaxeはFlashから派生したプロジェクトなので、一見関係なさそうな名前の “FlashDevelop” が先進的にサポートしているのも納得できます。
MassiveUnit
FlashDevelopでHaxeの開発環境を整えたうえで、MassiveUnit (munit) というunit testing frameworkを試してみました。ソースはBitBucketのzerobase/hellohaxeです。
追記：mocking libraryのMockatooを組み込んでみました。MockatooはHaxe 2.10では動作しますが、Haxe 3.0では動作しません。私はしばらくHaxe 2.10を使うつもりです。
TypeScriptとMeteorでアプリケーション開発へ
Smalltalkでのウェブ開発を断念してDartを検証中でしたが、DartをやめてTypeScriptにしようと思います。また、Node.jsベースのMeteorというアプリケーション・フレームワークを使うつもりです。（※さらに詳しい『これまでの経緯』）
TypeScriptとMeteorの組み合わせにした理由についてまとめます。
TypeScript
TypeScriptはJavaScriptにコンパイルする言語なのですが、
しかし、Dartと大きく違うのは、Dartが「JavaScriptにもコンパイルできる、JavaScriptを置き換える事を狙った言語」であるのに対して、TypeScriptはあくまでも「JavaScriptをより便利に使う為のコンパイル言語」にとどまっている点です。また、TypeScriptの仕様のほとんどが、基本的にはECMAScriptの先取りになっている点にも注目です。jQueryとnode.jsが、すでにTypeScriptベースで提供されている点もすばらしいですね。
つまり既存のJavaScript資産やnpm (Node.js)資産が活用しやすい。これがDartに対するJavaScriptのアドバンテージですね。
また、JavaScriptにコンパイルできる言語としてはCoffeeScriptやHaxeもあります。CoffeeScriptはTypeScriptの競合で、HaxeはDartの競合という感じです。いずれもTypeScriptより魅力的ではありませんでした。
Meteor
Meteorの解説は『第1回 Meteorをはじめよう：体感！JavaScriptで超速アプリケーション開発 －Meteor完全解説』に譲ります。Discover Meteorが出版されて、習得しやすくなりました。
そもそも『UIコンポーネント単位のエンド・ツー・エンドの開発パイプライン』を模索していました。また、『Smalltalkでのウェブ開発を断念してDartを検証中』に書いたように、Dartを使う目的に
- frontendとbackendを同じ言語で書く
- ドメイン・モデルのコードを共有・再利用する
- ブラウザのJavaScriptが有効ならAjax、無効ならサーバーサイド・レンダリングの切り替えを、透過的に行う
がありました。この目的を実現するならMeteorでもよさそうです。そして言語自体を比較するとDartよりTypeScriptのほうが魅力的でした。
そんなわけで、TypeScriptでMeteorアプリを開発する方向で研究しているところです。言語とフレームワークという、もっとも基盤的な技術の選定は、これで確定だと思っています。いよいよアプリケーション開発に着手です。
DartのintがJavaScriptのdoubleに変換されるのはどうかと思う
DartのコードはJavaScriptに変換できるわけですが、巨大な落とし穴が空いています。
Dartのintは、JSではdoubleに変換されてしまいます。かなり怪しげな問題です。バグの温床になると思います…
お金を扱うプログラム（をいまぼくは作ろうとしているわけですが）では致命的ですね。
解決策としては、Dart上で自前のbig int（というかcurrency的な）クラスを作ればよいと思っています。
どうせ最初からプリミティブ型を使うつもりはなくて、ドメイン・オブジェクトとしてラップするつもりだったので、まあ少し手間が増える程度（で済むといいなあ）かなと。適当な言語のbig int実装を移植すればいいかなと。
Integers can be arbitrarily large in Dart.
Note however, that when compiling to JavaScript, integers are implemented as JavaScript numbers. When compiling to JavaScript, integers are therefore restricted to 53 significant bits because all JavaScript numbers are double-precision floating point values. The behavior of the operators and methods in the int class therefore sometimes differs between the Dart VM and Dart code compiled to JavaScript.
Smalltalkでのウェブ開発を断念してDartを検証中
これまでの経緯を踏まえて、しばらくSmalltalkウェブ・アプリケーション・フレームワークSeasideとZincを比較してZincを採用する方向で検討していたのですが、Smalltalkを使うのは断念しました。
Smalltalkは全般的にHTML5などのフロントエンド技術への対応がなされていない、その理由はそもそもウェブ業界で使われている事例が少ない、従ってドキュメントやブログ情報なども充実していない、ということが理由です。
かなりSmalltalkを掘り下げたのですが、ちょっと車輪の再発明になりすぎるということで諦めた次第です。
とはいえ、Smalltalkを学んだことは良かったです。テスト駆動開発、オブジェクト指向の感覚は、以前よりも身に付いたと思います。
機会があればSmalltalk TDDワークショップなどできたらいいなと思います。ウェブ業界にSmalltalkのレッスンは有意義だと思います。現役ウェブ・プログラマーにSmalltalkを広めていきたいです。「教養としてのSmalltalk」という考え方は変わっていません。
次はDart
いま触っているのはDartです。Googleが開発している言語で、JavaScriptに静的な構造をもたらします。dart2jsでJavaScriptに変換して、ブラウザで動かすことができます。バックエンドとフロントエンドを同じ言語で書くために、Dartを試しています。
ちなみに、同じ目的ではGWTも有名です。サーバーサイドJavaでJavaScriptコードを自動生成します。
ウェブ開発において「エキセントリック」（ex-centric→中心から外れている）なSmalltalkから、ウェブ・セントリック（ど真ん中）なDartへと、極端に振り切った形です。あくまで結果論ですが。
Dartでやりたいことリスト（暫定版）
アクセシブルでセマンティックでSEOなAjaxアプリケーションを、それと意識せずに書けるようにしたい。フロントエンドのコードが、ブラウザ側とサーバー側のどちらで動いてるか意識しないで済む、透過的なプログラミング環境を実現したい。
細分化すると：
- frontendとbackendを同じ言語で書く
- ドメイン・モデルのコードを共有・再利用する
- ブラウザのJavaScriptが有効ならAjax、無効ならサーバーサイド・レンダリングの切り替えを、透過的に行う
- その場合のpathをpushStateで管理して、透過的なpermalinkにする（アドレスバーのURLがREST的にシェアなりブクマなりできる）
フロントエンド・フレームワークも
これまでの経緯として、
といったことを考えてきました。
そして先日のインブラウザーデザイン勉強会を受けて、自分でもPunchを触ってみたり、なぜ "Designing in the browser" ワークフローへの移行が必要なのかという文章を書いたりしました。
最近のフロントエンド・フレームワークの進歩はすごいですね。このようなツールと、”Designing in the browser”というワークフローと、ドメイン駆動設計（DDD）の開発フローを、うまく融合させたいと思っています。その鍵になる考え方が「UIコンポーネント単位のエンド・ツー・エンドの開発パイプライン」だという仮説で、引き続き検証していきます。
このプロジェクトは「単に物を作るプロジェクトじゃなくて、方法を作るプロジェクトでもある」という位置づけなので、なかなかアーキテクチャが決定しませんが、淡々と技術検証を続けていきます。
