専任のコマンドラインツール、クライアントプロジェクト、および当社製品の更新プログラムのリリースによる1年間の開発は、この間学んだことです。 私の経験を共有したいと思いますが、それはノードについてではなく、JavaScript全体についてです。
習得は簡単だが、マスターになることは不可能
ノードの学習は非常に簡単です。 JavaScriptに精通している場合は特別です。 Googleの初心者向けチュートリアルをいくつかご覧ください。Expressで遊んでみてください。 その後、何らかの方法でデータベースと対話する必要があることに気づき始めます。 問題ありません、NPMを実行します...ええ、ほんの一握りのまともなSQLパッケージ。 後で、既存のORMツールはすべて価値がなく、基本的なドライバーが最良の選択であることを理解できます。 これで、モデルの実装とロジックのチェックに問題があります。 その後すぐに、より複雑なクエリを記述し始め、コールバックで単純に迷子になります。 当然のことながら、「コールバック地獄」について読み、この問題について吐き出し、多くのpromiseライブラリの1つを使用し始めます。 これからは、リラックスした週末と引き換えに行うすべてのことを「無差別化」し始めます。
これにより、Nodeエコシステムは常に動いていると言えます。 そして、この動きのベクトルはあまり良くありません。 古いツールよりも「ずっとクール」な新しいツールが毎日見つかります。 想像してみてください。あなたはいつでも自分の持っているものを見つけることができますが、「輝き」も見つけることができます。 あなたはそれがあなたにどれほど簡単に起こるか驚くでしょう。 そして、コミュニティはそれを奨励しているようです。 Grunt！？を使用していますか？ みんなGulpを使用していますか！？ ちょっと待って、NPMネイティブスクリプトを使用してください！
わずか10行の些細なコードで構成されるパッケージは、NPMから毎日数千回ダウンロードされます。 本気ですか？ 本当に配列の型をチェックするために、この依存関係の文字列全体をインストールする必要がありますか？ そして、これらの同じパッケージは、ReactやBabelなどの巨人によって使用されています。
あなたはそのような不可解な速度で動くもののマスターになることはありません。 そして、これはそのような動きの「安定性」について言わずに言葉ではありません。
「ラッキー/アンラッキー」の原則に関するエラー処理
Python、Ruby、PHPなどの別の言語を使用している場合、何かが例外をスローし、何かがそれをキャッチし、最悪の場合、関数がエラーを返すことが予想されます。 これは正常です。 まったく問題ありません...しかし、ノードではそうではありません。 それどころか、コールバックまたはプロミスにエラーを渡します-そうです、例外をスローしません。 しかし、これは、いくつかのネストされたコールバックからコールスタックを取得するまで正確に機能します。 エラーが発生した場合にコールバックを返すのを忘れると、スクリプトは引き続き実行され、最初のエラーに加えて他の一連のエラーが発生するという事実は言うまでもありません。 通常のデバッグを行うには、デバッグ情報の量を2倍にする必要があります。
独自のエラーを処理するために標準で「真剣に」開始したとしても、（ソースを読まずに）NPMからインストールされたパッケージのほとんどが同じアプローチを使用することを確認できません。
これらの問題により、catchall例外ハンドラーを使用することになります。 これにより、問題のある場所をポーンでき、アプリケーションが「優雅に」落ちないようにできます。 Nodeはシングルスレッドです。 何かがプロセスをブロックすると、すべてが地獄に行きます。 しかし、これはクールです、Forever、 Upstart、Monitを使用しますか？
コールバック、約束またはジェネレーター！？
「コールバック地獄」、バグ、読みにくいロジックを管理するために、ますます多くの開発者がPromisを使用し始めています。 これは、狂気の「コールバック」ロジックなしで、多かれ少なかれ同期して見えるコードを書く方法です。 残念ながら、Promisを実装または使用するための単一の「標準」（JavaScriptの他の何かのような）はありません。
現在最も頻繁に言及されているライブラリはBluebirdです。 彼女はかなり上手で、速く働き、物事を「ただうまくいく」。 それがそうであっても、Promise.promisifyAll（）で必要なものをすべてラップすることは非常に便利であることがわかりました。
ほとんどの場合、素晴らしい非同期ライブラリを使用して、コールバックを制御し続けました。 彼女と一緒に、すべてがより自然に見えました。
Nodeでの経験の終わりに向かって、ジェネレーターの人気が高まりました。 私はそれらの「没入」を決して終えなかったので、私は本当に何も言うことができません。 もっと身近な人の話を聞きたいです。
不十分な標準化
最後のストローは、標準の欠如を発見したことです。 上記のことをどのように処理するかについて、誰もが独自のアイデアを持っているように感じます。 コールバック？ 約束？ エラー処理？ スクリプトをビルドしますか？ はい、これには終わりがありません。
それはすべて輝いています...誰も標準化されたJavaScriptコードを書く方法を言うことはできません。 「JavaScript Coding Standards」をグーグルで検索するだけで、私が言っていることを理解できます。
多くの言語には厳密な構造はありませんが、通常は言語メンテナーによって作成された標準ガイドラインがあります。
どういうわけか受け入れられる唯一のものは、 Mozillaで書かれました。
ノードの概要
JavaScriptとより具体的なNodeをチームで使用できるようにするために1年を費やしました。 残念ながら、この間、ドキュメントの検索、「標準」の理解、ライブラリの議論、些細なコードのデバッグなどに役立つ時間よりも多くの時間を費やしました。
Nodeに大規模なプロジェクトを勧めますか？ 絶対にありません。 とにかく人々はそれを使用しますか？ もちろん彼らはそうするでしょう。 私も試しました。
そうかもしれませんが、AngularやReactなどのフロントエンド開発者にはJavaScriptをお勧めします（別の選択肢があるかのように）。
また、主にWebソケットやAPIの提供に使用される単純なバックエンドサーバーにはNodeをお勧めします。 これは、 Quoterobot PDF処理サーバーに対して行ったため、Expressを使用して簡単に実行できます。 これは、スペースとコメントを含む186行のコードを含む単一のファイルです。 そして、それは単純であるのと同じように機能します。
Pythonに戻る
驚くかもしれませんが、私は今何をしていますか？ Pythonを使用して、製品とAPIの主要部分を書き続けています。 ほとんどはFlaskまたはDjangoで、PostgresまたはMongoDbを使用します。
これは、優れた標準、ライブラリ、簡単なデバッグ、安定した動作を備えた実績のあるオプションです。 もちろん、彼には欠陥があります。 しかし、彼は良いです、あなたはそれについて書き始めなければなりません。 何らかの理由で、Nodeが目を引き、私を引き締めました。 私は彼と友達になろうとする試みを後悔していませんが、私は彼に必要以上に多くの時間を費やしたと感じています。
JavaScriptとNodeが将来改善されることを願っています。 もう一度お試しください。
あなたの経験を教えてください？ 私が経験した問題はありましたか？ より快適な言語への「ジャンプ」を終えましたか？