これら2つの製品を比較することがよくあります。 私たちのグループであるGoogle Groupで優れた比較を行ったNick Retallackに感謝します。 彼の結論のいくつかはこの記事で使用されます。
それがすべて始まった方法
まず、11月にブライアンとMeteorチームと会ったのは、Derbyの初期バージョンのデモでKeeping it Realtimeカンファレンスで初めて会ったことです。 会ったとき、 Meteorチームはすでにフレームワークの開発を開始しており、類似点は肉眼で見ることができました。 少し前に、David Greenspan（最近Meteorに入社した）にも会いました。Etherpadの作成における彼の経験を話し、議論するのは面白かったです。 私たちのチームは友達であり、お互いにコミュニケーションを取り、多くのことを学びます。
私たちは、すべてのアプリケーションが「リアルタイム」および「コラボレーションモード」で動作する世界という共通のビジョンに基づいています。 他の多くの開発者と同様に、1年半前に突然、Web開発への最新のアプローチを使用して、特にデータが動的に更新される場合、ポジティブなユーザーエクスペリエンスを作成することは非常に難しいことに気付きました。
ブライアンと私は1年前にこれについて議論しました。 当時、私はGoogle検索チームでプロダクトマネージャーとして働いていました。彼は、 Mongooseやeveryauthなど、いくつかのオープンなNode.jsプロジェクトに関与していました 。 私はこのフレームワークの開発に興味がありました。必要なパフォーマンスを備えたアプリケーションを作成するのが最善だと考えたためです。BrianはNode.jsコミュニティがRailsまたはPHPを好む開発者にとって使いやすいフレームワークを必要としていると感じました。
聖杯：提供されたクライアントコード
Google検索での作業中に、アプリケーションが応答するためには、サーバーとクライアントの両方でWebページを生成することが非常に重要であることに気付きました。 Googleはこれを行うことができます-多くの開発者がおり、検索では速度が最重要です。 高速ロードと迅速な更新を実現するために、Google検索のすべてのページ生成コードはC ++で半分記述され、JavaScriptで半分だけ記述されています。 過去数年にわたって、彼らはこのタスクを簡素化するためにいくつかのプロジェクトを立ち上げましたが、そのような開発プロセスはスタートアップや複雑なアプリケーションにとっては高価すぎて役に立たないことは言うに値しません。
Gmail、Twitter、およびクライアントでのみレンダリングされる他のサイトの読み込みが遅すぎる。 Twitterは完全に循環しました-彼らはRailsでサーバー側の生成を開始し、すべての生成をクライアントに転送しました。その結果、140文字のメッセージを読むにはユーザーから4秒かかりました。 Twitterは、サーバー上のScalaでページの半分を形成し、クライアント上のJavaScriptで残りの半分を形成します。 これらすべてが一緒になってコードのサポートがより複雑になり、ページの重要性の低い部分がページが完全にロードされてから数秒後にしか表示されなくなります。 人々は変化に対して非常に敏感であり、再出現する要素はより重要な要素から注意をそらす。
V8でJavaScriptのパフォーマンスが復活し、Node.jsでJavaScriptサーバーを簡単に作成できるため、多くの開発者はクライアントとサーバーで同時にJavaScriptを使用するというアイデアに触発されました。 しかし、この驚くべき機会にもかかわらず、一部のアプリケーションのみが共有コードを使用しています。 1つの言語でも、遅延と接続の安定性の違い、サーバーとブラウザーのURLの操作方法の違い、ブラウザーのDOMの存在とクライアントのDOMの不在、最後にファイルシステムへの直接アクセスなど、多くの問題があります。サーバー上のみ。
要するに！
これらすべてを考慮して、私たちのチームはいくつかの問題で同様の方法で移動し、他の問題ではまったく異なる方法で移動することを決定しました。 Derbyの目標は、開発者が検索エンジンと同じくらい高速で、テキストエディターと同じくらいインタラクティブでオフラインで作業するアプリケーションを作成できるようにすることです。 Meofforの目標は、インターネット上のサイトの90％が使用する「広範な市場プラットフォーム」を作成し、その90％がWeb開発を可能な限り高速化することです。
GPL対MIT
Meteorは現在GPLでのみ利用可能です。 つまり、ソースをGPLの下で公開したり、GPLと互換性がない場合は、ソースに連絡して商用ライセンスに同意する必要があります。
ダービー、レーサー、およびフレームワークの他のすべてのコンポーネントは、MITライセンスの下で公開されていますが、これらの欠点はありません。 あなたはあなたのアプリケーションで何でもできるようになります、そして私たちはあなたに今も将来も干渉することはできません。
私は弁護士ではないので、私が今言ったすべてを文字通り受け止めてはいけません。 私は水晶玉などで未来を見ませんでした。 （はい、私たちの弁護士はかつてこれについて言及するように頼みました。）
Meteor vs npmパッケージシステム
Meteorは独自のパッケージシステムとパッケージ配布ツールを作成しました。
Node.jsモジュールは、明確に定義されたCommonJS標準に従い、組み込みのモジュラーAPIを備えています。 ただし、当初はパッケージ配布システムはありませんでした。 当初、Node.jsにはいくつかのパッケージマネージャーがありましたが、ほとんどの開発者はnpmの使用に注力しています 。 それは非常に普遍的であるため、Node.jsの配布物に含まれています。
率直に言って、これは流星について私を心配する主なものです。 Meteorを試している人がNode.jsを使用したことがなく、 npmを介してパッケージを配布する利点を認識していないかのようです。 私と他の多くの開発者は、Node.jsの重要なパワーをnpmで見ており、互換性のないパッケージシステムによって弱められるのを見るのは非常に悲しいでしょう。
他の多くのNode.jsプロジェクトと同様に、Derby、Racer、およびそれらのプラグインをnpmモジュールとして配布しています。 そして、私たちはプロジェクトを小さなモジュールに分割し続け、他の人が使いやすいようにします。 Derbyを使用していない可能性がありますが、HTMLを解析する必要があります。 テンプレートシステムが機能するには、シンプルで高速なHTMLパーサーを作成する必要があり、Node.jsプロジェクトで使用できます。 Connectは、それに基づいたモジュールの豊富なエコシステムを備えたプロジェクトの優れた例であり、npmを通じて配布されています。
他のライブラリとの互換性
Meteorでは、モジュールの一部を他のライブラリに置き換えることができます。 このアプローチの柔軟性は、クライアントライブラリの場合に特に顕著ですが、Meteorモジュールのように最初にラップする必要があります。
Meteorは通常、サーバーの作成を独自の方法で管理します。 これにより、Meteorアプリケーションを作成してサーバーにデプロイするプロセスは非常に簡単になりますが、同時に、Meteorを通常のNode.jsサーバー上のモジュールとして使用することは非常に複雑になります。
対照的に、Derbyは通常のnpmモジュールであり、任意のNode.jsサーバーに追加できます。 8900 npmモジュールの1つ（現在39000-約）を使用する場合は、package.jsonファイルに追加して
npm install
を実行
npm install
です。
Derbyは、ホスティングソリューションを提供していません。これは、市場に優れたホスティングサービスがすでに数多く存在しているためです。 将来的には、パブリックサーバーにDerbyをすばやくインストールして実行する方法についての指示を提供する予定です。
Racer （Derbyのモデルを管理するリアルタイムエンジン）は別のモジュールであり、Derbyから独立して使用できます。 Racerの任意のUIレベルに侵入し、モデルを更新するときに呼び出されるメソッドを制御できます。 Racerは、必要に応じて直接アクセスできる人気のあるモジュールSocket.IOに基づいています。
Derbyカーネルはまた、いくつかの一般的なライブラリ、特にルーティング用のExpressとブラウザ用のほとんどのNode.jsモジュールを自動的にパックするBrowserifyを使用します。
MongoDB APIとRacerメソッド
Meteorは、ブラウザーでMongoDB APIを直接使用します。 MongoDB APIは強力で、JavaScriptから簡単に使用できます。 それらはすでに慣れており、特定の開発パターンが発生しています。一般に、アプリケーション開発中に発生する可能性のあるほとんどの問題を解決するのに十分です。 多くの人がこのアプローチをアプリケーションの作成に非常に便利だと思うようです。なぜなら、抽象化の層を理解する必要がなくなるからです。 セキュリティの問題について話す人もいますが、Meteorチームが認証と承認へのアプローチを明らかにするまで、厳密に判断すべきではないと思います。
Racerには、「データ変更メソッド」と「パス」を中心に構築された独自のAPIがあります。 このAPIを使用すると、MongoDbを含むドキュメント指向のリポジトリに1対1で接続できます。 これにはもちろん長所と短所がありますが、いくつかの理由でこれが優れていると考えています。
紛争解決
「パス」と「メソッド」は、競合解消手法に最適です。これは、レーサーの最大の利点の1つになると予想されます。 現在、デフォルトでは、「最後のレコード変更が優先される」手法を使用します。これは、Meteorがデータを保存する方法と同等です。 ただし、ソフトウェアトランザクションメモリおよび操作変換メソッドを使用した競合解決システムの予備的な実装があります。 これらの手法により、Derbyアプリケーションをオフラインで使用してから、正しく同期することができます。 Google Docsのスタイルで物事を実装することも可能になります-1つのテキストフィールドでコンテンツを同時に同時編集します。
データウェアハウスの互換性
「パス」と「メソッド」は、ほとんどのデータウェアハウスの機能を使用したり、切り替えたり、同時にいくつかの機能を使用したりするのに十分な柔軟性を備えています。 Riak、Postgres、CouchDb、またはその他のサービス間の切り替えは、ソースコードを変更することなく行われます。
PubSub Efficiency（データの公開/データ変更の購読）
「パス」はPubSubメカニズムと完全に組み合わされています。これが、データの変更をリアルタイムで同期する方法です。 MeteorのLiveMongo実装では、データはデータベースに書き込まれるだけで、その後データベースは定期的にポーリングされて変更が行われ、クライアントごとにポーリングされます。 クエリプールの利点は、Mongoリクエストをデータベースに適用できることですが、データベースにアクセスする必要なく、ほとんどのPubSubリクエストのラッパーを実装しました。 今のところ明らかな証拠はありませんが、PubSubはデータベースクエリプールよりもはるかに優れたスケーラビリティを期待しています。
拡張API
他のサーバーとやり取りしたり、サードパーティのAPIを使用したりしても、データウェアハウスとして機能する拡張機能を作成できます。 データベースアダプタはかなり高いレベルの抽象化で構築されているため、非常にさまざまな方法で使用できます。
サーバーページの生成と一般的なルーティング
Derbyは、同じページ生成およびルーティングコードがサーバーとブラウザーの両方で機能するように設計された少数のフレームワークの1つです。 Derbyを使用して、動的アプリケーションと同じテンプレートを使用する静的ページを生成することもできます。
これは、箱から出してすぐにページを非常に高速にロードできることを意味します。 クライアントでページを生成する単純なアプリケーションであっても、ページのロードとレンダリングには1〜2秒かかります。 単純なDerbyアプリケーションでは、200ミリ秒後にonloadイベントがトリガーされます。 アプリケーションが複雑になるほど、サーバーの再生成による速度の増加が大きくなります。
Google、Amazon、Facebookなどの多くの大企業は、ページの読み込み時間の最適化に膨大なリソースを投入しています。これは、コンバージョンと収益に直接影響するためです。 Gmailが負荷インジケータ付きのプログレスバーを追加したその日、私はほとんど死にました。 絶対にしないで。
さらに、サーバー上でのページの生成はSEOにとって重要であり、JavaScriptのサポートがないブラウザーやリーダーへのアクセスを提供します。
サーバー上のDerbyルーティングモジュールはミドルウェアExpressモジュールであるため、他のExpressサーバールートと組み合わせて使用して、たとえばファイルをダウンロードしたり、同じルートセットを使用して多くのアプリケーションを記述したりすることもできます。 Expressサーバー。 たとえば、デスクトップバージョンのすべてのコードをダウンロードしない別の管理者またはモバイルアプリケーションを作成できます。
Derbyは通常のマルチページアプリケーションの速度と可用性のすべての利点を提供しますが、ブラウザーで直接パターンとルーティングを生成できる完全に最適化された単一ページアプリケーションを作成する機会も提供します。 クライアント側のルーティングを使用すると、ページをリロードせずにリンクごとにリンクを簡単に描画でき、ルーティングに特定のAPIを使用する必要はありません。 クライアントに通常のリンクを設定するだけで、Derbyがすべてを行います。
Meteorにはこの機能はありませんが、最近テンプレートエンジンを書き換えて追加できます 。
モデルとビューデータのリンク
Meteorは、リアクティブプログラミングアプローチを使用してテンプレートを更新します。これにより、任意のテンプレートエンジンで作業できるようになります。 テンプレートから生成する場合、生成に使用されるすべてのデータはページの結果の部分に添付されます。 データを変更した後、テンプレートが再生成され、結果がDOMの既存の部分と比較されます。 そしてその後、Meteorは、最小限の介入で、廃止されたDOMチャンクのみを置き換えます。 このアプローチの大きな利点は、テンプレート言語を簡単に使用できることです。
対照的に、DerbyはHandlebarsに基づいたテンプレートエンジンを使用します。 バインディングは明示的に指定され、HTMLテンプレートは、更新が必要なDOMの部分を計算するための解析を必要とします。 Meteorとは異なり、Derbyバインディングは2つの方法で機能します。要素がアタッチされると、ユーザーが編集フィールドに何かを入力するか、チェックボックスをオンにするか、ドロップダウンリストから要素を選択すると、モデルが自動的に変更されます。 すべてのデータをバインドするか、必要なデータのみのバインドを手動で最適化することができます。 開発者がDOMの要素を操作して自分の手でビューを更新する場合、無関係なデータの出力が望ましい場合があります。
DOMイベントハンドラー
ここでの違いはごくわずかです-MeteorはテンプレートでCSSセレクターを使用し、DerbyはHTML属性を使用してイベントハンドラーをバインドします。 jQueryとBackboneはCSSセレクターを人気にしました; KnockoutとAngularはHTML属性を使用します。
どのCSSセレクターが必要な要素を担当しているかを把握するのが難しく、HTML構造が変更され、CSSセレクターが慎重に破壊されることがよくあるため、 HTMLマークアップを好みます 。 マークアップを使用すると、関数名が誤って変更され、必要な関数が見つからなかったという例外がスローされる可能性が低くなります。
Derbyは、従来のアプローチに比べて直感的で理解しやすい革新的なアプローチを使用してイベントをバブリングします。 イベントをDOMノードからルートにポップアップする代わりに、Derbyは最初のバインドされたハンドラーを見つけるとポップアップを停止します。ルートと同様に、next（）を呼び出してイベントのポップアップを続行できます。
繊維
Meteorは、コールバックチェーンに基づくほとんどのNodeプロジェクトで従来使用されているコードの代わりに、同期的に見えるコードを作成できるNodes.js拡張機能であるFibersを使用します。 非同期コードを記述するこの方法を好む人もいれば、断固として反対する人もいます。 賛否両論の多くの議論があります。
この問題は議論の余地がありますが、現時点ではそれを避けたいと考えています。 npmモジュールのごく一部がこのスタイルで記述されており、コールバックを使用したNode.jsのより伝統的なアプローチに従います。
まとめると
両方のフレームワークでほぼ同じ結果を達成できます。 どちらも、RailsやPHPなどの従来のWebフレームワークを使用して行うのが難しいプログラムを開発するための強力なツールです。
Derbyは、競合検出、オフラインクライアントのサポート、非常に高速なページ生成などのサポートテクノロジーに重点を置いています。 また、Node.jsエコシステムに存在し、オープンにライセンスされている他のモジュールとの互換性にも重点を置いています。
最終的に、私たち全員が開発者に最適なツールを作成しようとしますが、競争の精神はより多くのイノベーションを生み出すだけです。 Meteor 、 SpaceMagic 、 Firebaseなどの製品で他のアプローチを見ることができてうれしく思います。私たちは皆互いに学び合っています。 最終的に、これはより良いツール、より良いウェブ、そしてユーザーにとってより便利なものにつながるでしょう。
翻訳者から ：レビューの執筆以来、製品は大きく成長し、Meteorで変更されました。
1.現在、MeteorはMITの下でライセンスされています
2. npm-modulesを使用できるようになりましたが、アプリケーションでは直接使用できません。まず、Meteor-packagesのラッパーでラップする必要があります
3.通常の認証、認証は流星に現れました
4.サーバー側のページ生成に関して、この機能はSpark（Meteorのハンドルバーの下にある中間DOM生成モジュール）に組み込まれていますが、まだ実装されていません。 スパイダブルモジュールを接続することで、ページのインデックス作成が可能です。これは、GoogleとYandexの両方で機能します。
MeteorまたはDerbyで他に何が変わったのかを伝えることができる場合はコメントしてください。
PS翻訳中に使用： DERBY VS METEORについての考え