node.JSとRingoJSという2つのサーバーサイドJavaScriptが有名(node.JSの方が遥かに知名度は上)ですが、「どっちを使うべきなのか?」という話をtwitterで見かけました。実際、周りでも同じような意見を聞きます。僕自身は、RingoJSについて「サーバーサイドJavaScriptで簡単Webアプリ開発」でも書き始めたように、最近ちょくちょく触りだしているのでなじみがあります。node.JSについては、「hello world」どまりで、比較しようにも比較できない状況でした。そこでネットで調べてた所、海外のブログサイトでnode.JSとRingoJSの比較内容が書かれたブログが2つあったので、自分なりに訳してまとめてみました。
参考にしたブログ
どちらも2010年7月、9月に書かれているので、内容は若干古くとなっているところもあると思います。(特にnode.JSに関してはupdateスピードが早いので)
ブログ名から察するにnode.JSラブな人が書いているんだと思いますが、node.JSだけに偏った意見ではなく、RingoJSについてもわりと公平に比較されていたと思います。
こちらはブログ件名とは異なり、RingoJSの長所を中心に書かれおり、比較はあまりされていませんでした。そのせいか、コメント欄では、色々と反論されており、その投稿した人の反論からnode.JSのメリットをひっぱりあげました
まとめた比較情報の多くはnodejsbotを参考にさせてもらいました
node.JSについて
短所
- C++のアドオンをコンパイルするのに管理者権限が必要になる
レンタルサーバとかで一般ユーザ権限しか貸与されてないとコンパイルできない可能性があるということだと思います
- Windows上で動作させるには注意が必要である
たぶんブログが書かれた当時はnode.JSのWindows対応がいまいちだったのではないかと推測しました。LinuxとWindowsにnode.jsをインストールしてみたによると最新のnode.JSとWindows7だと、簡単にインストールできるみたいです。なので以前の話かと思います
- ノンブロッキングシステム(非同期)のコードは、スレッド、同期ベースのコードを書いてきた開発者にとって、制御のフローはなじみが薄い
JavaScriptをやり始めたころ、コールバックという処理に違和感を感じとことがあります。まぁこれも慣れれば便利なものに
- 過去の遺産からなる、様々なモジュールが存在していない
RingoJSでいう、Javaでできたライブラリの存在をさしていると思います。当然、V8エンジンという新しいミドルゥエアであるため 、専用モジュール以外は存在していないですね
- バージョンUPが速いので、利用者は古いバージョンに取り残されていくかもしれない
0.0.1がリリースされてから約10カ月の間に、0.4まであがっているのですごい勢いで更新されていますね。これはまだBetaバージョンに近い位置づけだから、現状はある意味しょうがないのではないでしょうか
長所
- 非同期APIによってクライアントサイド開発のようにイベント駆動型の開発が可能になる
短所でもでてきた内容の反対の理由ですね。node.JSの長所中の長所かと
- シングルスレッドは多くの同期問題を回避できることを意味する
当たり前ですが、マルチスレッドならではの同期問題は発生しなくなりますよね
- V8エンジンは高速でAPIは綺麗(google v8.hファイルを見る事で、悩んだ際の答えがほとんどのっている)
V8エンジンのソースを見た事はないのですが、Googleのスーパーエンジニアが設計コーディングしているのだから、いけている実装なんでしょうね
- C++のアドオンで、何でもやりたいことは実現できる
C++ベースのV8環境なので、足りない機能があれば、C++で自分でアドオンを作成すればOKということでしょうね
- APIはJavaScriptのクロージャを使用しており、楽をすることができる
クロージャ自身はJavaScriptの言語機能だから、node.JS固有のものでもないと思うのですが・・・
- ローレベルのAPIは多くのAPIと比べて、簡単に複雑な実装が可能である
ローレベルAPIがどれをさすのか曖昧なので、よくわかりませんが、、、processやstreamのあたりのことでしょうか
- イベント駆動型システムはスレッド型モデル(コンテキストの変更、メモリのオーバヘッド、ロッキングがある)と比較してすばらしい
コンテキストの変更はJ2EEモデルでの開発をさしているかと思います。確かにアプリケーションで修正するたびに、コンテキストの変更が発生するようなモデルだと、発狂しそうです。ちなみに、RingoJSではコンテキストを変更したりする事は基本的に無いです
- ファイルディスクリプタの入出力は素晴らしい
たぶん、プロセス間でストリーム通信を行う際のファイルディスクリプタの扱いの効率性を指摘しているんじゃないのかなと思いました。badmathさんのnode.js とは何か (2)の記事を見て頂ければnode.JSの内部アーキテクチャの概要が理解できメリットが分かると思います。
- メモリの消費量が少ない
シングルスレッド万歳!
- コミュティは大きく、非常に活発で、フレンドリーである
これは意外に重要だと思いました。オープンソースアプリケーションの多くは利用するユーザによって、発展している歴史があるので
RingoJSについて
短所
- JVM上でJavaScriptを実行しているので、node.JSの実行環境であるC++で書かれたV8エンジンより遅い
これも当たり前の事実だと思っていましたが、RingoJSとnode.JSでベンチマークをとったブログRingoJS vs. Node.js: Runtime Valuesによると、遅いどころか、node.JSよりパフォーマンスが良い結果もありました。node.JSが2010年9月のスナップショットで比較しているので、最新版だとどういう結果になるかは不明ですね
- APIでJavaScriptらしいコーディングが使われていない
node.JSのコードと比べるとコールバックなど使わなくても実装できるので、そうかもしれないです。これはアーキテクチャが非同期モデルとスレッドモデルの違いもあると思います
- ハイレベルAPIのコードがクライアントJavaScriptの記述と似ていない
ハイレベルAPIがどこを指すのか分からないのですが、この理由も上記に近いのではないでしょうか
- アドオンについての情報が記載されていない。
node.JSではアドオン、RingoJSではパッケージの事を指しているんだと思うのですが、確かにnode.JSみたいにアドオン(パッケージ)の作成方法やルールなどが記載されたページはなかったです。
- JVMを使用しているので、メモリを大量に消費しやすい
これはVMの弁慶の泣き所ですね。
長所
- Javaを使ってアドオンの開発ができる、過去のJavaのライブラリなどを再利用可能
node.JSの長所でもあったように、RingoJSではベースがJavaなので、Javaを使っての機能拡張が可能です
- JavaScript1.8の機能を使うことにより、より良いスクリプトがかける
RingoJSは内部でRhinoエンジンを使用しているので、Mozilla Foundationで開発されているJavaScriptの新機能の恩恵を受ける事ができるということですね
- シングルプロセスの中で、複数のインスタンスを動作させることができる(V8エンジン上でも同じ事はやろうと思えばできるば、難しいだろう)
たぶん、マルチスレッドだといいたいんだと思います。マルチスレッド全盛の時代で、いまさら長所ポイントとしては弱い気が・・・
- 別スレッドで動作しているJavaScriptをsync()関数を使って、ブロック(同期化)することができる
sync()関数はRhinoエンジンが提供する関数で、Javaでの同期処理より簡単に書けるみたいです
- JVM上で実行されるので、Google App Engine、自宅のPC、携帯電話などで動作する
自分もRingoJSを使用しようと思った際の決め手となったポイントです。多くのデバイスで動作する可能性というのは魅力的です
- データーベースはテスト、サポートされたJavaライブラリを経由して行われる
実績があるJDBCを使用できることのメリットを言いたいんだと思います
- デスクトップアプリケーションを作成する場合、GUI、マルチメディア、入出力のJavaライブラリを利用できる
これも上と同じように豊富なJavaライブラリの恩恵ですね
- Javaのアドオンは素晴らしく、JVM上で動作するので安全である。JNIを使う事で、C++のライブラリも使うことができる
RingoJSでもやろとう思えば、なんでもできると思います
- CommonJSに限りなく準拠している
node.JSよりRingoJSのほうが、CommonJSに準拠しているそうです
じゃあ、どっちをつかえばいいの?
正直それは僕にもよくわかりません(笑)。短所と長所をまとめていく過程で思った事は、node.JS、RingoJSはサーバーサイドJavaScriptという"枠組み"は同じではありますが、比較する対象としては相違点が多いというか、2つのミドルウェアの前提となる仕様の方向性が大きく違っており、比較対象にすべきではないように思いました。なのでプログラマがnode.JS、RingoJSの好きな方のスタイルを選択すればよいと思います。それでも、もしどちらかを選択しないといけなくなった場合、主観になってしまうですが「少ないリソースで大量のトラフィック(アクセス)をさばく必要がある場合はnode.JS」、「それほどトラフィックやリソースを気にする必要がない普通のWebアプリケーション開発ではRingoJS」という位でしょうか。後は、PaaSサービスやレンタルサーバなどの実行環境の制限も基準になりますよね。今の所、判断基準はこれくらいしか思いつかないです(汗)
Trackback URL
http://blog.fukaoi.org/2011/06/11/nodejs-vs-ringojs?tb=y&entry_id=32
コメント一覧
コメントありがとうございます!
>Rhinoの書き方がそのまま使えるんじゃないかと思っています
その可能性はありそうですね。灯台もと暗しでした。
>http://groups.google.com/group/ringojs/browse_thread/thread/4238cd010c2a1df9
まだじっくり読んでないのですが、良い記事ですね!
後、Hannesさんって、node.JSにかなりライバル心抱いてないですか(笑)。執念を感じるのは自分だけ?
>・Rhino Debugger
あ、、忘れてました、確かに。node.JSはnode-inspectorがありますが、別途インストールしないといけないですからね。
諸々、ブログの方にも内容を反映したいと思います。
ありがとうございました。
XML

> アドオンについての情報が記載されていない。
RingoJSで僕もこの記事は見たことないんですが、Rhinoベースになっているので、Rhinoの書き方がそのまま使えるんじゃないかと思っています(書いたことはないんですが)。
https://developer.mozilla.org/ja/Rhino_documentation
Rhinoの書き方については、サイ本6thEditionの12章1節"Scripting Java with Rhino"にも記述があります。
既にパッケージがいくつも出ているので( http://www.ringojs.org/wiki/packages )参考にすればできそうですが、公式ページが欲しいところです。
・RingoJSでのC10K問題とパフォーマンスに対してのHannesさんの言及
シングルスレッドでの何らかの負荷に対する遅延と、JettyのSelectSocketConnectorはnon-blocking I/Oを使っている(?)という内容っぽいです。
http://groups.google.com/group/ringojs/browse_thread/thread/4238cd010c2a1df9
・Rhino Debugger
RingoJSはRhinoに付属のGUIデバッガが使える点もメリットかなと思います。
http://www.ringojs.org/wiki/Debugger (SS: http://twitpic.com/5bhjf7 )