8

私は、JSライブラリでNode.jsとNPMを使用しているJSコミュニティのすべての人と本当に混乱しています。なぜ私たちはそのような極端な手段に頼らなければならないのですか?これは私たちにとってどのような問題を解決していますか?

[編集]私の質問は要点ではなかったと思います。

  1. Ember.js、Batman.js、最近ではYahooのMojitoなどのフレームワークでは、node.jsを使用する必要があります。なぜこのNode.jsとNPMに依存しているのでしょうか。
  2. なぜ私たちは物事を複雑にしているのですか?「まだインストールしていない場合は、node.jsをインストールする必要があります...」このようなメッセージを読んだら、電源がオフになります。

なんで?JSにはすでに多くの問題があります-選択するにはアクティブなJSライブラリ/フレームワークが多すぎます-JSライブラリの記録を見ると、ほとんどがすぐに非アクティブになります。依存関係の管理、ルーター、MVC、テンプレートなど、アプリ内に複数のフレームワークが生じることが多いため、探すべきことが多すぎます。さらに、Node.jsを使用してこれらのライブラリ/フレームワークを使用しています...方法これにより、これらのライブラリの使用が新しいJS開発者にプッシュされますか?JSは簡単にするためのものでした!

4

4 に答える 4

11

「まだインストールしていない場合は、node.jsをインストールする必要があります...」このようなメッセージを読んだら、電源がオフになります。なんで?

NodeJSは、「独自に実行する」GoogleのV8です。これは、追加の低レベルAPI(ネットワーク、I / Oなど)を備えたJSエンジンです。NodeJSは、ブラウザーでの作業に限定されていたJS開発者に「欠けているプラ​​ットフォーム」を提供します。

なぜこのNode.jsとNPMへの依存?

Node.jsは、アプリ(サーバー、プロキシ、ボットなど)として使用するだけでなく、ツールのビルドや開発支援としても使用できます。たとえば、Makeに似たスクリプト可能な自動化ツールであるGruntを取り上げます。単なるJSでのスクリプト作成では、自動化を行うために別のツールや言語を学ぶ必要はありません。もう1つのツールは、フロントエンドのパッケージ管理ツールであるBowerです。あなたがする必要があるのはabower install jqueryであり、それはその単一のコマンドでjqueryをインストールします。手動でダウンロード、コピー、貼り付けする必要はありません。

一方、NPMはNode.jsのパッケージマネージャーです。これは、NodeJSで使用するモジュールを管理するプログラムです。モジュールを手動でリストする必要はなく、他の場所で開発するときにモジュールを覚えておく必要もありません。NPMが作成したパッケージリストがある限り、再インストールはの問題ですnpm install

なぜ私たちは物事を複雑にしているのですか?

そうではなかった。実際、開発者が簡単に利用できるようにしています。ワークフローを心配したり、ライブラリを管理したり、手動で作業したりする代わりに、これらのタスクをNPMに存在するいくつかのモジュールにオフロードできます。そうすれば、実際に行っていることに集中できます。

これに加えて、Node.jsを使用してこれらのライブラリ/フレームワークを使用しています...これにより、これらのライブラリの使用が新しいJS開発者にどのようにプッシュされますか?JSは簡単にするためのものでした!

上記のように、NodeJSは用途の広いプラットフォームです。サーバー(Connect、Express)、自動化ツール(Grunt)、パッケージ管理システム(NPM、Bowerなどを使用)、テストプラットフォーム(QUnit、Mocha)、プロキシ、ゲームサーバー、チャットボットとして使用できます。 。

そして、これらはJSでは不可能だったので、特にJS開発者にとっては有益です。

JSにはすでに多くの問題があります-選択するにはアクティブなJSライブラリ/フレームワークが多すぎます-JSライブラリの記録を見ると、ほとんどがすぐに非アクティブになります。依存関係の管理、ルーター、MVC、テンプレートなど、アプリ内に複数のフレームワークが生じることが多いため、探すべきことが多すぎます。

ええと、フレームワークのセットが豊富にあるのは良いことです。それらのいくつかを学んだ後、あなたの仕事は半分にカットされます。さまざまなスタイルのコーディングやさまざまな実装アプローチに対応するために、実装の多様性も優れています。一部のライブラリは異なるアプローチから生じますが、他のライブラリは他のライブラリの非互換性および/または不完全性から生じます。

開発者は、JSの癖を正規化することで他の開発者の生活を楽にするために一生懸命働いており(ブラウザベンダーは標準に従うという正しいことを行うことができないため)、それらのほとんどは無料のビールのように自発的に行われています-あなたは嬉しいです。その上、とにかく誰もあなたにそれを使うことを強制しません。

于 2012-05-14T14:23:28.667 に答える
5

CommonJS標準(私の意見では、Node.jsとNPMによって最適に実装されています)は、モジュールの概念をJavascriptに導入しています。何年もの間、PerlとPythonのコミュニティは、モジュールが素晴らしい理由を示してきました。

  • Unixスタイルの「1つのことを実行してうまく実行する」ライブラリ。小さくてバグに対して徹底的にテストされており、特定のタスクを解決するために簡単に(名前空間の問題なしに)組み合わせることができます。
  • モジュールを簡単にプルできるオープンソースモジュール(CPAN、NPMなど)の中央リポジトリ(NPMは、すべてのバージョンを利用可能な状態に保つことで1レベル高くなるため、コードで最後の既知の「良好」を使用するように指定できます) CPANを再デプロイするときに何も壊れないことを期待するのではなく、バージョン)。
  • コードのより優れたピアレビュー(より簡単に構成できるため、より多様な状況で使用されるため、これはバグを減らすのに役立つだけでなく、モジュールをより一般化するのに役立ちます)。
  • さまざまなタスクが解決されました。ライブラリは短いので、ほとんどの人が書くことができます。これは、フィルタリングする必要のあるものがもっとたくさんあることを意味します(広く使用されているライブラリに関する記事がこれに役立ちます)が、非常に特定の問題(文字列や日付のローカライズなど)を解決するライブラリもおそらく存在することを意味します。

そして、browserifyと呼ばれるNodeモジュールを使用すると、クライアント側のコードの実際のビルドプロセスが非常に簡単になり、NPMで見つかったほぼすべてのコードを使用できます。

これは、jQuery(コードのモジュール化を開始できるように独自のカスタムビルドシステムを開発した)のようなライブラリの「キッチンシンク」の考え方から脱却し、ユーザーが抱える可能性のあるすべての問題を解決する必要があると考えています。他のライブラリで使用できる結果。

于 2012-05-14T16:27:19.353 に答える
1

多くの場合、JavaScriptのさまざまなビルドが必要です。通常、それはさまざまなファイルに分散されており、場合によってはコーヒースクリプトに分散されています。多くの場合、AMD互換ビルドとCommonJSビルドに加えて、通常の最小化および非最小化ビルドが必要です。

依存関係を解決する可能性もあります。

jQueryとprotoype用にビルドされたライブラリを見たことがあります...

于 2012-05-14T14:24:45.780 に答える
1

編集:質問の本文に記載されているように質問に回答していることに気づきましたが、タイトルの編集の質問を見逃していました。

これを「極度の対策」と見なすための基準は何ですか?これは、クリーンで読みやすいコードを書くために何年にもわたって行われてきましたが、電信送金(およびおそらく他の最適化)用に最適化されるようにプリコンパイルされています。Node.jsは、JavaScriptも使用しているため、JavaScriptコードをコンパイルするために使用する人々に馴染みがあるため、このための優れたソリューションになります。以前は、これは通常Pythonのようなもので行われていました。これは機能しますが、一般的な言語に固執するよりも私にはあまり意味がないようです。

于 2012-05-14T14:24:54.600 に答える