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コンポーネント単位のエンド・ツー・エンドの開発パイプライン」だという仮説で、引き続き検証していきます。
このプロジェクトは「単に物を作るプロジェクトじゃなくて、方法を作るプロジェクトでもある」という位置づけなので、なかなかアーキテクチャが決定しませんが、淡々と技術検証を続けていきます。
