RailsとNode.js/PHP/Pythonなどの比較

まず、これは比較記事ではありません。言語とフレームワークは比較できますか?

第二に、私はそれらすべてを使用したわけではありません

この記事の唯一の目的は、本当に注意する必要があるものを自分 (そして閲覧しているあなた) に思い出させることです

PHP
PHP はシンプルですが汚い言語です。簡単な手段です。主に、wordpress、discuz など、PHP ベースの絶対確実なアプリケーションが多数あるため、学習曲線は低くなります。一般的なブログやフォーラムのニーズのみがある場合は、うまく活用する限り、 Google の場合、コードを 1 行も記述する必要はありません。しかし、PHP 自体は単純なのでしょうか?個人的にはそうは思わないので、理由を一つ一つ挙げるつもりはありません。汚いということは、言語設計がかなり貧弱であることだと思います。経験豊富な PHP プログラマー以外には、関数名を見てわかるだけでわかります。重大ではない脆弱なコード。

推奨される PHP 開発フレームワーク: 第一クラス: Yii、Yaf、Symfony; 第二クラス: Zend、Cake、CI

Django
Django は、数年前の Rails に非常によく似た Python ベースの Web 開発フレームワークです。 Rails よりも優れていました。良い点は、Python は Ruby よりも「信頼性」が高いということです。いわゆる信頼性とは、より多くの人が使用し、より多くのドキュメントがあり、質問することで答えを見つけるのが簡単であることを意味します。近年、Ruby が徐々に台頭しており (主に Rails によって推進されています)、Rails を使用する Web サイトがますます増えています。言語設計だけに関して言えば、Python は必ずしも Ruby より単純であるわけではなく、その一貫性は若干劣りますが、Python の唯一の利点は、この分野で世界のほとんどを占める多くの本格的な科学者がそれを使用していることであると言えます。一方、Ruby は日本製です (Ruby は Python から借用したものです)。もしRubyがPythonと同時期に欧米諸国で誕生した言語であれば、今はPythonでも何も問題はなかったと思います。

Rails
Rails は、Ruby の特性を最大限に活用した、現在主流の Web フレームワークのほとんどにその影が見られます。 Rails は、大規模、中規模、小規模のすべてのアプリケーションに適用できます。非常に大規模なアプリケーションは、スクリプト言語だけでは処理できません。長年の開発を経て、Rails はその栄光を洗い流し、現在では総合的な機能 (使いやすさ、シンプルさ、効率性、学習曲線など) の点で Rails を超えるフレームワークはないと言えます。 .)、NodeJS はだめで、他の「ニッチ」言語はさらにダメです。それどころか、Rails は急速に発展しており、超大規模アプリケーションの成功例も出てきます。今後も続々と。

NodeJS
NodeJS は有望な Web フレームワークですが、数年後に誕生したのは残念です。そうでなければ、まだ Rails と競合できるはずです。PHP、Django、Rails と比較すると、NodeJS はオープンソースが比較的少ないです。成功事例は若干少ないですが、設計や性能も非常にシンプルで効率的です。近い将来も光ると信じています。

ASP、JSPなど
複雑で肥大化したエンタープライズレベルの、人材の蓄積に依存する企業、国有企業、銀行、電子商取引、新興企業は、これらを使用すると自殺するでしょう。重要な部門がこれらを利用しないと自殺行為にもなりかねません（採用が下手で、アフターサービスしか使えない）。

その他
他の言語にも独自の用途がありますが、Clojure、Ioなど、厳密に言えば、それらはたまたまビジネスで使用されていると見なすことはできません。今のところここでは議論しません。

要約:

もう一度学習ルートを選択するように求められたら (サーバー、DB の側面を除く、言語のみ)、私は

php を理解します。深く学ぶ必要はありません

PHP 用の MVC フレームワークである Yii を理解します、必要ありません 深く

Ruby を基本的に学ぶ

Rails を基本的に学ぶ

Ruby を徹底的に学ぶ

Rails を徹底的に学ぶ

Python、Django、Lisp、Clojure、NodeJS などを理解する

------ ------------------- ----------区切り線------------------- --------------

この記事は Rails に関するものです。nodejs に適用できるシナリオが非常に詳しく説明されています。 Rails と Nodejs は、最も注目すべき 2 つのバックエンド テクノロジです。
免責事項: この記事は決して NodeJS と Ruby on Rails の利点や戦略について議論するものではありません。ここでは、意思決定プロセスにおける考え方の一部と、決定の背後にある理由についてのみ説明します。どちらのフレームワークも優れており、当初の設計目標をうまく達成しています。そのため、一部のモジュールは依然として NodeJS 上で実行されます。

私は NodeJ の大ファンです。これは非常にエキサイティングなテクノロジーであり、今後ますます人気が高まると信じています。最近、Targeter アプリを NodeJS から Ruby on Rails に移行しましたが、私はこのテクノロジーに非常に感謝しています。

NodeJSを使って開発した理由は簡単です。私はアプリを非常に迅速にオンラインにするパッケージを持っています (これには 54 時間かかりました)。Ruby よりも JavaScript をよく使用します。私たちの技術アーキテクチャには MongoDB が含まれているため、私のこれらの専門知識は NodeJS 環境でのみ意味を持ちます。しかし、アプリケーションのサイズが大きくなるにつれて、このアプリケーションの実装に NodeJS を選択したのは間違った選択であったことに気づきました。その理由を説明しましょう。

NodeJS は、有効期間の短いリクエストを大量に扱うアプリケーションに適しています。従来の CRUD アプリケーションの場合は問題ありませんが、理想的ではありません。 PHP、Ruby、Python 言語には、この種のアプリケーションを処理するための非常に成熟し、最適化されたフレームワークがあります。 NodeJS 内のすべてが非同期で実行されるという考えは、CRUD アプリケーションには影響しません。他の言語で人気のあるフレームワークは、非同期実行を含むすべてのニーズを満たす非常に優れたキャッシュ テクノロジを提供します。

NodeJS は非常に若いテクノロジー フレームワークであり、その周囲のライブラリはあまり成熟していません。私は、優秀で多くの優れたライブラリを開発してきたコード提供者に対して、何の悪気もなくこれを言います。ただし、ほとんどのライブラリは改善が必要であり、NodeJS の環境は急速に成長しているため、最先端のテクノロジを使用する場合は、バージョンがアップグレードされるたびに多くの変更が加えられるため、できるだけ早く最新の状態に保つことが非常に重要です。のバージョン。これは起業家企業に多くの問題をもたらします。

もう 1 つの理由はテストに関するものです。 NodeJS のテスト フレームワークは悪くありませんが、Django や RoR プラットフォームのフレームワークと比較するとまだ劣っています。毎日大量のコードが送信され、1 ～ 2 日以内にリリースされるアプリケーションの場合、プログラムに問題がないことが重要です。問題がなければ、苦労した甲斐がありません。愚かなバグの修正に 1 日を費やしたい人はいません。

最後の点ですが、必要なのはすべてをキャッシュできるものであり、できるだけ早く実装する必要があります。私たちのアプリケーションは成長しており、毎秒数万件のヒットが発生しますが、大量のアクセス要求が発生することはありません。これはチャット プログラムではありません。メインプログラムは最大 1000RPS に達しますが、Ruby on Rails や Nginx にとってはこのような負荷は関係ありません。

もしあなたが今もこの記事を読んでいるなら、あなたは私が言わなければならないことをすべて理解しているでしょう、そしてあなたは非常にしつこく、私たちのアプリケーションがどこでまだNodeJSを使用しているのか知りたいかもしれません。さて、私たちのアプリケーションは 2 つの部分で構成されています。 1 つ目はインターフェイス、つまりユーザーに表示される部分で、2 つ目はレポート管理とログ機能を担当する部分です。後者は、多数の短いサイクルのリクエストが存在する NodeJS の最適な使用シナリオの 1 つです。アクションのこの部分は、データのプッシュが完了する前であっても、できるだけ早く実行する必要があります。リクエストの実行がまだ終了していない場合、ブラウザは応答が終了するまで待機し続け、ユーザー エクスペリエンスに影響を与えるため、これは重要です。 NodeJS の非同期の性質が私たちを救ってくれました。データはデータベースに保存されるか処理され、リクエストが完了すると、ブラウザは他の重要な作業を開始できるようになります。