「SproutCoreの将来」from SproutCore Blog

以前インストールして時間がなくて触れていない SproutCore ですが、開発者ブログを見ると1.0に向けた動きがあるようです。“On the future of SproutCore” をざっと訳してみました。

わざわざ互換性をとるためのフレームワークを用意するところをみても、いろいろと変更がありそうですね。
この後の投稿でより詳細な内容が説明されはじめています。

SproutCoureの将来

(Posted on October 31st, 2008 by charles)


WWDCでSproutCoreを公開してからほぼ4か月になるが、こんなにうれしいことになるとは思っていなかった。18,000人もの開発者がSproutCoreをインストールして(絶対に sudo gem install sproutcore だね)、1,000人もの開発者がメーリングリストに参加して、何十ものプロジェクトが世界中の会社で現在進行中だ。すでに公開されているプロジェクトもひとつある(OtherInbox)。

こうしている間、ぼくらSproutCoreの開発者たちはじっとしていたわけじゃない。150個のチケットをクローズしたし、大きな新機能をいくつか追加した。それに、WindowsやIE、Chromeなどのサポートも強化してきた。ぼくらが採用した変更の多くは、あなたたちコミュニティから送られてきたものだ。実際に、今では20名以上の人がSproutCoreのコードに貢献してくれている。まだ始まったばかりのプロジェクトなのに、これはすごいことだよ。

ぼくはたった今旅行から戻ってきたところだが、次にぼくらがどこへ向かうのか、少し時間をかけて話しておくべきだと思うんだ。

簡単に言ってしまえば、次の大きなマイルストーンは SproutCore 1.0だ。SproutCore 1.0の計画を始めたときに考えた基準をここにあげておこう。

  • よく使うものは簡単に、そうでないものも可能に。アプリケーションの典型的な動作は、ほとんど自動になるべきだ。でも、開発者がハックしてクールなことができなきゃならない。
  • アプリケーション全体をサポートする。SproutCoreはアプリケーション開発プロセス全体をサポートしなければならない。これにはモデル、ビュー、コントローラといった層や、設計、テスト、ドキュメント、デプロイといったものまで含まれている。
  • 小さくて一貫性のあるAPIにする。膨大なクラスよりも設定があるほうが好みだ。一貫性のある「推測可能な」設計パターンを使うこと。一度リリースしたら大きな変更をしなくていいよう、APIを厳しく精査すること。
  • プラットフォームを幅広くサポートする。あらゆる最新のブラウザでうまく動くこと。IE7やそれ以前のブラウザでも十分動くこと。
  • 今のところ、ここにあげた目標のほとんどが、あともう少しで達成できるというところまで来ている。具体的に言うと、SproutCoreはモデル層、ビュー層を構築することができ、ウェブサーバと通信することができ、それらをバインディングを使ってひとつにまとめることができる。こんなことができるオープンソースのウェブアプリケーションフレームワークはSproutCoreだけだ。それに、ビルドツールにちゃんとしたドキュメントとユニットテストがある数少ないフレームワークのひとつでもある。コードを数行書くだけでどれだけの機能が実現できるかを考えると、APIはかなりよくできていると思う。これもバインディングのおかげだ。

    SproutCoreで開発されたアプリを10個ほど見たところ、最終的に、APIにも実装にも、いくつか改善できるところが見つかったんだ。これを受けて、この数週間かけて、SproutCoreフレームワーク全体の大きなレビューをやったんだ。そして、そのレビュー結果に基づいて、もっと高速に、もっと効率よくメモリを使えるよう、昔からあるコードを書き直しているところだ。APIももっと一貫性のあるように、改訂しているところなんだよ。

    この膨大な作業は別のリポジトリでやっていて、一部はまだプライベートになっている。このコードを公開リポジトリに入れるのは、すべてが統合できてからになるだろう。それまでの間、これまでやった変更を少し話しておこう。これから数週間にわたって、API仕様の一部を深く掘り下げていくつもりだが、まずは今やっていることをざっくりと紹介しておこう。

    高速なオブザーバとバインディング

    プロパティの監視とバインディングは、SproutCoreフレームワークの土台だ。だから、この機能を小さく高速にするのは本当に重要なことだ。そこで、ぼくらはこの部分のコードを書き直した。何もしなくても約2倍高速になり、メモリ消費もかなり少なくなる。あと数日後にはもっとよくなるよ。

    DOM ライブラリに依存しないこと

    現在のSproutCoreにはクロスプラットフォーム関数がわずかにあるため、Prototypeに依存している。これにはそれほど大きな意味はない。具体的に言うと、ぼくらはPrototypeやjQueryなどを「DOM操作ライブラリ」として考えているんだ。低レベルの描画APIのようなものだね。SproutCoreはこの層の上にあるべきものだ。カスタムビューを作るときには、あなたはどれでも好きな描画ライブラリが選べるべきだ。それに、DOMライブラリに依存しなくなれば、Prototypeを使いたくない人はアプリケーションから重いページをなくすこともできる。

    新しいモデル層

    SC.Store、SC.Collection、SC.Record、そして現在のサーバ実装は、約2年前に書いたときのままだ。初めてデプロイしたときには小さなアプリだったので非常にうまく動いていた。ところが今では、定期的にメモリに40,000を超えるレコードをロードするようなアプリケーションを目にするようになった。それに最新のブラウザでは、ローカルストレージを利用しようという研究が進んでいる。こうした新しい、もっとスケールの大きな世界に対応するために、ぼくらはAPIを更新しながらコードを大きく書き直すつもりだ。

    もっとすぐれたドキュメント

    APIを再検討している間、ぼくらはすべてのクラスに対してインラインドキュメントを追加するよう改善を進めている。新しいチュートリアルと合わせて、最終的にSproutCoreはもっと学びやすく、使いやすいものになるはずだ。

    もっといろいろなこと

    ぼくらはSproutCoreにいくつか大きな変更をする。それについてはまだ話すことはできないが、ひとつだけあげておこう。

    互換性

    たとえSproutCoreのAPIが大きく変わったとしても、すでにたくさんのコードが現在のSproutCore APIを使って動作していることを、ぼくらは知っている。こうした古いアプリケーションをサポートするために、“sproutcore-deprecated”フレームワークを平行開発しているんだ。このフレームワークをアプリケーションにインストールすれば、既存のAPIをすべてサポートすることができる。あなたは自分のペースでコードをアップデートしていけばいい。

    ソフトウェアを開発するという点で、ウェブは大きな進化を遂げようとしているとぼくらは信じている。アプリケーションがクラウドに向かうにつれて、ユーザは使い慣れたリッチなデスクトップ体験を求めるようになるだろう。こうした体験をもたらすのに、SproutCoreが最もすぐれた選択肢のひとつになるとぼくらは思っている。SproutCoreはオープンソースであり、シンプルなAPIをそなえており、アプリケーション全体にフォーカスしている。
    ぼくらは新しいSproutCore 1.0がこうした世界を実現する土台となることを望んでいる。