RailwayJS vs TowerJS
繰り返しますが、フレームワークを選択します。これら2つのTowerJSとRailwayJSを停止しましたが、これらは非常に類似しており、どちらを選択するかは非常に困難です
どちらもExpressに基づいており、どちらもRoRスタイルのフレームワークです...
どれが最も有望で、どれがより人気がありますか？
それとも、私はすでに間違った道を進んでいますか？他のフレームワークを選択する必要があるかもしれません。
選択するフレームワークが非常に多く、依存する業界標準がない場合、フレームワークが数年以内に開発されることを多少なりとも確信するとき、私は嫌いです...
助けてください、専門家の提案が必要です。ありがとう
以下に概要の簡単な表を示します。いくつかの項目について以下で説明します。
+ ----------------------- + -------------------- ---------- + ------------------------------------ + | | RailwayJS | Tower.js | + ----------------------- + ---------------- -------------- + ----------------------------------- -+ |最初のコミット| 2011年1月| 2011年10月| | Rails | 2.3.x | 3.x | | Node.js |> = 0.4.x |> = 0.4.x | |サーバー|✓ |✓| |クライアント| |✓| |テンプレートに依存しない|✓|✓| |デフォルトエンジン| EJS | CoffeeKup | |データベースに依存しない|✓ |✓| |デフォルトのデータストア| MongoDB | MongoDB | |モデルの検証| validatesPresenceOf（ 'email'）| validates（ 'email'、Presence：true）| |クエリスコープ|✓|✓ | |チェーン可能なスコープ| | ✓| |パラメータ解析| | ✓| |コントローラー| ✓| ✓| |リソースコントローラー| | ✓| |ファイルの命名| users_controller.js | usersController.coffee | | vm.runInCustomContext | ✓| | |資産パイプライン| | ✓| |資産圧縮| | ✓| |ルーティング| map.resources（ 'posts'）| @resources 'posts' | |ネストされたルート| ✓| ✓| |生成されたURLヘルパー| ✓| | |ジェネレーター| ✓| ✓| |コマンドラインAPI | ✓| ✓| | REPL（console）|✓|✓| | CoffeeScriptコンソール| |✓| |アセットキャッシュメソッド|タイムスタンプ| md5ハッシュ| |運用資産パス| /app.css?123123123 | /app-859c828c89288hc8918741.css | |優先言語| JavaScript | CoffeeScript | | CoffeeScriptサポート|✓|✓| |国際化|✓|✓| | Herokuサポート|✓|✓| |文字列の場合| snake_case | camelCase | |フォームビルダー|✓|✓ | |セマンティックフォームビルダー| | ✓| |テーブルブイラー| | ✓| |ファイル監視API | | ✓| |ライブリロードアセット| | ✓| |テストスイート| | ✓| |テスト用ジェネレーター| | ✓| | Twitter Bootstrap |✓|✓| | HTML5ボイラープレート| |✓| + ---------------- ------- + ------------------------------ + ----------- ------------------------- +
Tower.jsを作成して、既存のフレームワークでは適切に達成できなかったいくつかの目標を達成しました。これらの目標の一部を以下に示します。
1.クライアントとサーバーで同じコード
Node.jsがサーバー上でJavaScriptを可能にしたため、Railsでアプリの一部を、Backboneでアプリの一部を作成する理由はありません。それはドライ以外の何かです。モデルを一度定義すれば、クライアントとサーバーの両方で使用できるはずです。
RailwayJSは、エクスプレスを中心に構築されているため、サーバー上でのみ機能します。 Tower.jsもexpressを中心に構築されていますが、クライアントとサーバーの両方で動作するようになっています。 Tower.jsは、クライアントとサーバーにまったく同じAPIを提供します。これは、クライアントとサーバーで同じように動作するようにルーターのようなものを書き直す必要があったことを意味しました（さらに、同じルートのセットを使用して、history.pushStateフォールバックで#のようなことを行うことができます）。
2.クライアントとサーバーで同じ「ビュー」
RailsとHamlテンプレートの作成に多くの時間を費やしました。Mustacheのようなテンプレート言語を使用して、WebおよびモバイルJavaScriptインターフェイスを作成していました。クライアント（JavaScriptテンプレートとして）とサーバー（静的HTMLのレンダリング）の両方のビュー/テンプレートのセット。
Hamlは非常に素晴らしかったため（非常にきれいで、任意のRubyを実行でき、プリティプリンティングに組み込まれているなど）、最も近いJavaScriptの代替は CoffeeKup でした。そして、クライアントとサーバーの両方で動作します。 CoffeeKupを使用すると、JavaScriptのすべての能力を備えたテンプレートを作成できるため、制限はありません。 MoustacheでFormBuilderを構築するには、多くの作業または大量のコード、あるいはその両方が必要になります。
ただし、テンプレートエンジンを交換して、クライアントまたはサーバーにJade、Mustache、Handlebarなどを自由に使用できます。 CoffeeKupは、クリーンで強力なデフォルトです。
3.クライアントとサーバーのRails品質モデルAPI
ActiveModel（ActiveRecord for SQLおよびMongoid for MongoDB for Railsで実装）は、開発者がデータを定義および操作できるようにする非常に徹底的で十分にテストされたAPIです。パワフルで楽しいです。以前の（および現在の）JavaScript実装はすべて、これほど堅牢で適切に設計されたものではありませんでした。また、近い将来何も発生しませんでした。
これをRailsで書くことができる場合：
User.where(:email => /[a-z/).page(2).limit(20)
あなたはJavaScriptでそれを行うことができるはずです：
App.User.where(email: /[a-z/).page(2).limit(20)
Tower.jsには、ハードコアクエリ+ページネーションを意味する「チェーン可能なスコープ」が付属しています。 MongoDB Query API をモデルにしていますが、このAPIの「入力」は、さまざまなデータストアに適したデータベースコマンドに変換されます。
4. SQLおよびNoSQLデータストアへの統一インターフェース
Tower.jsには現在MongoDBとメモリ（ブラウザ内）ストアがあり、残りの一般的なデータベース（CouchDB、Neo4j、PostGreSQL、MySQL、SQLite、Cassandraなど）への統一されたインターフェースを提供することを目指しています。
RailwayJSもJugglingDBを介してこれを行っているようで、良いスタートのようです。しかし、いくつかの理由で使用しないことにしました。最初に、Rails 2.x API（User.validatesUniquenessOf "email" vs. User.validates "email", presence: true）を中心に構築されているように見えます。2番目に、Rails 3があります。第三に、コードベースにコードをすばやく追加できるようにしたいのですが、非常に気難しいので、CoffeeScriptを使用するためにすべてをリファクタリングすることになります（笑）。クライアント上でも動作する必要があるため、その周りにレイヤーを構築したいので、ライブラリアーキテクチャを可能な限り最小限に保つことが最優先事項です。
5.リソースフルなコントローラー
inherited_resources Ruby gemは、私のRailsコントローラからコードの約90％を切り取りました。 Tower.jsにはこのようなものが含まれているため、デフォルトでコントローラーにコードを記述する必要はなく、JSONとHTMLで応答します。また、ネストされたルートを定義できるようにします。 。
6. URLからデータベースへの自動クエリパーサー
Tower.jsでは、URL内の特定のパラメーターを監視するようにコントローラーに指示することができ、モデルクエリに適用する準備ができたハッシュに変換します。
class App.UsersController extends App.ApplicationController
@param "email"
index: ->
App.User.where(@criteria()).all (error, users) =>
@respondTo (format) =>
format.json => @render json: users
format.html => @render "index", locals: {users}
/users?email=abc&something=randomのようなURLを指定すると、@criteria()はハッシュ{email: /abc/}を提供します。
Railsにはありませんが、そうだったらいいのにと思います。
7.セマンティックフォーム
セマンティックHTMLが大好きです。 RailsのフォームビルダーはかなりいHTMLを生成するため、多くの人々と私は Formtastic を使用しました。これにより、より意味のあるフォームが生成されます。 Tower.jsは、Formtasticとほぼ同じAPIを使用します。また、セマンティックテーブルビルダーもあり、管理ビュー用の検索可能/ソート可能なテーブルを簡単に構築できます。
8.資産パイプライン
Rails 3にはすばらしいJavaScriptパイプラインがあり、JavaScriptをCoffeeScriptで、CSSをSCSSで記述すると、自動的に再コンパイルされます。その後、アセットをrake assets:precompileすると、md5ハッシュgzip圧縮されたアセットがS3の準備が整います。それを自分で構築するのはかなり難しく、Node.jsで作業している人は誰もいませんでした。
RailwayJSは、アセットパスのタイムスタンプにRails 2メソッドを使用するため、このmd5-hashedバージョンの代わりに：
/stylesheets/application-51e687ad72175b5629f3b1538b65ea2c.css
次のようなものが得られます。
/stylesheets/application.css?1306993455524
これはいくつかの重要な理由で問題です。 Rails Asset Pipeline Guide に詳細がありますが、大きなことはS3がタイムスタンプを認識しないため、/ stylesheets/application.cssを読み込んでおり、将来のExpiresヘッダーを使用してCSSを変更した場合、以前にサイトにアクセスしたユーザーは、キャッシュを消去するか、ページを強制的に更新して更新を確認する必要があります。
RailwayJSには、（少なくとも私の知る限り）組み込みのアセットコンパイルパイプラインもありません。
9.ウォッチファイル
Guard はRailsの生産性を大幅に向上させました。パターンに一致するファイルが作成/更新/削除されたときに実行される、基本的にレーキ/ケーキタスクのような、迅速な「監視タスク」を作成できました。
Towerにはこれが組み込まれています（ design.io を使用）。これは、実際には、CoffeeScriptおよびStylusアセットにJavaScriptおよびCSSにコンパイルするよう指示しています。ただし、この機能を使用すると非常に強力なことができます。例については、 https://github.com/guard/guard/wiki/List-of-available-Guards を参照してください。
10. CoffeeScript
CoffeeScriptの大ファン。
CoffeeScriptは、記述する必要のあるJavaScriptの量を半分に削減します（ 6,501追加、15,896削除 Node.jsライブラリ全体をCoffeeScriptに変換します）。また、コーディングがはるかに速く簡単になります。
また、CoffeeScriptは、Railsが世界を示した生産的で楽しいコーディング体験を維持する唯一の方法です。JavaScriptはそれを行いません。
小さなこと
私は標準のファンです。 RailwayJSはRuby snake_caseを使用する慣習に固執しており、私もそれをしたかったのですが、JavaScriptコミュニティはcamelCaseを使用しているため、Towerはそれを活用しました。サーバー側のRails snake_caseとクライアントのcamelCaseの変換を行う必要はありません。その余分な文字を削除すると、ファイルサイズが小さくなります。
私はまた、非常にクリーンなコードが大好きです。プロジェクトへの貢献を検討する前に、ソースコードを読みます。それが非常に面倒な場合は、おそらくそれを書き直します。
コードの最適化も大好きです。 Tower.jsの大きな目標は、可能な限り最小限のコードを使用して、クライアントとサーバーの両方でまったく同じAPIを提供し、Railsが行うすべてを実行するように構造化することです。ただし、コードベースのサイズを最小化することと、使用するのが明確で楽しくて生産的なコードを書くこととの間のトレードオフです。
長距離でもこれに間違いなく参加しています。これが当社の基盤であり、私が個人的に将来構築するものすべてです。うまく設計された、機能的で高度に最適化されたアプリを1日でポンプアウトできるポイントに到達したいと思います。
お役に立てば幸いです。
Derbyjs に注意しましたか？これはまだベータ版ではありませんが、非常にエキサイティングです。 ex google従業員と everyauth の著者によって作成されています。これで最小限のクライアント側javascriptを記述する必要があります。公式ページからの抜粋をご覧ください。
Rails and Backbone？を使用しないのはなぜですか？Derbyは、Rails and Backbone。
Rails、Django、およびその他のサーバー側フレームワークで作成されたアプリに動的機能を追加すると、混乱が生じる傾向があります。サーバーコードはさまざまな初期状態をレンダリングしますが、jQueryセレクターとコールバックは必死にDOMとユーザーイベントの意味を理解しようとします。通常、新しい機能を追加するには、多くの場合異なる言語でサーバーとクライアントの両方のコードを変更します。
多くの開発者は現在、BackboneなどのクライアントMVCフレームワークを組み込んで、クライアントコードの構造を改善しています。いくつかは、KnockoutやAngularなどの宣言型モデルビューバインディングライブラリの使用を開始して、定型的なDOM操作とイベントバインディングを減らしています。これらは優れた概念であり、構造を追加するとクライアントコードが確実に改善されます。ただし、レンダリングコードの複製と、ますます複雑化するサーバーとクライアントのコードベースでの変更の手動同期につながります。それだけでなく、これらの各部品は手動で接続し、クライアント用にパッケージ化する必要があります。
ダービーは、動的な相互作用を追加するこのプロセスを根本的に簡素化します。サーバーとブラウザーで同じコードを実行し、データを自動的に同期します。 Derbyは、テンプレートのレンダリング、パッケージ化、およびモデルビューのバインドをすぐに処理します。すべての機能は連携して動作するように設計されているため、コードの複製やグルーコードは不要です。 Derbyは、すべてのアプリのすべてのデータがリアルタイムである将来の開発者に装備します。
グルーコードなしの柔軟性Derbyは、サーバー、サーバーテンプレートエンジン、CSSコンパイラー、スクリプトパッケージャー、ミニファイアー、クライアントMVCフレームワーク、クライアントJavaScriptライブラリ、クライアントテンプレートおよび/またはバインディングエンジン、クライアント履歴ライブラリ、リアルタイムトランスポート、 ORM、およびデータベース。モデルとビュー、クライアントとサーバー、複数のウィンドウ、複数のユーザー、モデルとデータベースの間で状態を同期させる複雑さを解消します。
同時に、それは他の人とうまくいっています。 Derbyは、Node.js、Express、Socket.IO、Browserify、Stylus、UglifyJS、MongoDB、その他の一般的なデータベースやデータストアなど、一般的なライブラリの上に構築されています。これらのライブラリは直接使用することもできます。データ同期層のRacerは、個別に使用できます。 jQueryなどの他のクライアントライブラリ、およびnpmの他のNode.jsモジュールは、Derbyと同様に機能します。
デフォルトのファイル構造に従うと、テンプレート、スタイル、およびスクリプトが自動的にパッケージ化され、適切なページに含まれます。さらに、上記の簡単な例に見られるように、Derbyは動的API経由で使用できます。
しかし、それはまた、次の免責事項が付属しています
ダービーとレーサーはアルファ版ソフトウェアです。 Derbyは、プロトタイピングや週末のプロジェクトには十分に機能するはずですが、まだ大きな開発が行われています。 APIは変更される可能性があります。
まだ承認の実装はなく、 セキュリティの問題 に満ちていますが、今後数か月のうちに対処されます。数か月待てば、これは有望なフレームワークのようです。
TowerJSはデータストアとしてMongoDBとより緊密に結合されているように見えますが、RailsJSはモデルアダプターに柔軟性があるようです。これは、2つの選択に影響する可能性があります。個人的には、RoRを使用してRailsサイトを作成することを選択します。 Nodeは、さまざまな種類のサービスにより適しているようです。 （AJAX RESTサービスを備えたクライアントのバックボーンを考えています）。
フレームワークを選択することは、あなたの快適さのレベルに依存します。
プロジェクトはどの程度活発ですか？最後のコミットはいつですか？ githubにない場合、ユーザーの貢献が難しくなるので、それは私にとって差し迫った懸念です。
フレームワークにはいくつのブログ投稿がありますか？誰もそれについて話していなければ、それは通常悪い兆候です。なぜなら人々は彼らを興奮させるものについて自然に話すからです。
[〜＃〜] i [〜＃〜]フレームワークについてどう思いますか？これは判断が難しい場合がありますが、少なくとも基本的なアイデアを得ることができる十分な例があるはずです。そうでない場合、それ自体が大きな問題です。
えーと。もちろん、RoRフレームワークが必要かどうかは明らかな質問です。RoRを使用しないのはなぜですか。 ;）