5

私はサーバー側の JavaScript プログラミングが初めてで、これと従来のサーバー側の Java との違いを理解しようとしています。重要な違いは何ですか? SSJS が一般的になったのはなぜですか? SSJS はどのように Java よりも優れていますか? 素人の観点から言えば、JS は Java よりもパフォーマンスが遅いと思います。これは主に、JS がインタープリター言語であるためです。

よろしく、 アナンド

4

5 に答える 5

8

node.jsは、この現象の発生と多くの関係があると思います。

http://nodejs.org/

それが多くのcommonjsライブラリ開発などの推進力になっていることは間違いありません。

クライアント側とサーバー側のコードが同じ言語であると、作業が楽になるというコメントがあります。私が取り組んだノードプロジェクトでは、最初はすべてのプログラマーが3人しかいなかったので、多かれ少なかれ、私たちが望むテクノロジーを使用するための自由を与えられました。誰もが異なる背景を持っていたので、これはいくつかの議論につながりました。しかし、誰かがnodejsを提案したとき、それが良い考えのように思われた理由の1つは、javascriptが私たち全員に共通するものであったということでした。

ただし、ノードの成功は主にjsを使用しているためではないと思います。それはデザインについてです。私が使用した他のほとんどのサーバーサイドテクノロジー（Rails、PHP、cgi、mod_perl、mason）よりもずっと気に入っていたので、インターフェイスで使用されている言語に関係なく、おそらく同じくらい気に入っていたでしょう。しかし、jsはそうです。

それが私のポイントです。特にjavascriptに関することとは関係がなく、「javascriptコミュニティ」で行われている巧妙な思考と開発のいくつかと関係があると思います。驚きです。PHPについて考えてみましょう。PHPの成功は、言語の設計（またはパフォーマンス特性）とはあまり関係がないと思います。PHPの使用方法の性質と、サーバー側プログラミングの考え方に関係していると思います。 10〜15年前、および（密接に関連して）彼らが構築しなければならなかったツール。

そこでの1つの問題（「賢い思考」部門）は、ノードの背後にいる人々によって行われた（非常に説得力のある）アサーションであり、たとえばnginxは、非同期のイベント駆動型モデルが従来の並列同期スレッド駆動モデルよりもサーバープログラミングに適しています。私は、後者がJavaで優勢であると信じていますが、それが他の方法でも同じように簡単に使用できると考えています。一方、Javascriptは元々、ブラウザの非同期のイベント駆動型の世界での使用を目的としており、スレッドはまったくありません。繰り返しますが、言語ではなく文化です。

また、交換フォーマットとしてのJSONの主な使用と、dbの構造化にJSONを基本的に使用するcouchdb（使用した）やmongodb（使用していない）などのNoSQLデータベースの主な使用も注目に値します。Couchdbは、一部のサーバー側プログラミング（基本的にはクエリハンドラー）にもjsを使用します。これは、おそらくデータベースドキュメントがJSONであるためです。これは、クライアントに渡すのにも便利です。非常に滑らかで賢い。モデルからビューまで、1つの言語、1つのプロトコル。重要な意味で、「交換」はまったくありません。

于 2012-05-13T11:12:40.477 に答える
7

これと従来のサーバー側 Java の違い

まず第一に、Java と JavaScript には共通点がありません。それらは2つのまったく異なるものです。心に留めておきます。

  • 1 つの言語にとどまることができるため、多くの人がサーバー サイド JavaScript を好むと思います。別の言語 (Java、PHP、Ruby など) を使用する代わりに、サーバーでもクライアントでも JavaScript を使用します。また、多くの Web プログラマーは JavaScript に精通しているため (クライアントで使用するため)、よく理解しています。

  • JavaScript は Java よりも簡単です。小さなプロジェクトの場合、Java は JavaScript に比べてオーバーヘッドが大きくなる可能性があります。コールバックのようなものは、JavaScript では非常に洗練されたものになる可能性があります。

  • また、Node.js のような新しいフレームワークにより、この言語の使用が魅力的になります。サーバー側のフレームワークがない限り、サーバー上で JavaScript を使用することはできません。しかし、言語は今日よく進化しています。

  • JavaScript の性能はサーバーにも依存すると思います。これについてはよくわかりませんが、私の知る限り、JavaScript も (ジャストインタイムで) コンパイルできます。Google の chrome はそのようなことをしています。また、ほとんどの Web サイトではパフォーマンスはそれほど重要ではありません。これは、パフォーマンスが主にデータベースへの IO であるためです。HTML ページの実際の作成は非常に単純で、大したことではありません。そして: PHP も解釈され、多くのサイトで使用されています。Ruby は Java よりもかなり遅いですが、Ruby on Rails は非常に人気があります。したがって、パフォーマンスはそれほど重要ではないようです。それは、その言語がいかに「素晴らしく」エレガントであるかということです。

于 2012-05-13T10:00:45.517 に答える
2

JS のような素晴らしいものがあるのに、GWT (Google の Java Web クライアント) を使用する理由のようなものです。

それはもっと心理的な問題だと思います-人々は、未知の言語に移動するのではなく、自分の保存された既知のゾーンにとどまる傾向があります. 過去 5 年間 Java を使用していて、Java の落とし穴をすべて知っていて、Java をとても気に入っている場合は、すべてのことを Java で作成する必要があり、Java が最も迅速な解決策であると確信し始めるでしょう。

Java が js よりも優れているとは言いませんが (大規模なサーバーサイド プロジェクトには Java の方が優れていると思いますが)、ほとんどの js-server-side ユーザーはこれを使用していると思います。変更したくありません。

于 2012-05-13T10:37:57.390 に答える
2

私の観点からの主な利点は、豊富な JS クライアント インターフェイスを使用している場合、クライアントとサーバーのやり取りが簡素化されることです。サーバー側とクライアント側で同じ言語を使用する場合、それらの間で共通のコードを共有できます (たとえば、検証などのビジネス ロジックがあり、それがクライアントとサーバーで使用される場合、JS で一度実装して複数で使用できます)。場所）。

また、すでに JS を知っている場合は、サーバー側の作業を行うために新しい言語を学ぶべきではありません。

于 2012-05-13T10:00:24.020 に答える
1

ここで私の意見を付け加えたいと思います。
一言で言えば、Node.js は、websocket を介したプッシュ テクノロジを採用するリアルタイム Web アプリケーションで際立っています。
ステートレス リクエスト/レスポンス パラダイムに基づくステートレス Web の 20 年以上の経験を経て、クライアントとサーバーの両方が通信を開始し、データを自由に交換できる、リアルタイムの双方向接続を備えた Web アプリケーションがようやく完成しました。
これは、クライアントが常に通信を開始する典型的な Web 応答パラダイムとはまったく対照的です。さらに、すべて標準ポート 80 で実行されるオープン Web スタック (HTML、CSS、および JS) に基づいています。

于 2015-06-07T12:05:23.527 に答える