サーバー側の JavaScript の使用は一般的ですか? 他のサーバー側スクリプトとは対照的に、なぜそれを使用するのでしょうか? 他のサーバー側言語よりも優れている特定のユースケースはありますか?
また、それを試し始める方法について混乱しています。私は freeBSD を使用しています。サーバー側の JavaScript を実行するには、何をインストールする必要がありますか?
8098 次
5 に答える
53
こんなふうになります：
サーバーは高価ですが、ユーザーはブラウザーでの処理時間を無料で提供してくれます。したがって、サーバー側のコードは、複数のサーバーを実行する必要があるほど大きなサイトでは、クライアント側のコードに比べて比較的高価です。ただし、データの検証や取得など、クライアントに任せることができないものもあります。ユーザーの応答時間が短くなり、サーバー インフラストラクチャが少なくなるため、クライアントで実行したいと考えていますが、セキュリティとアクセシビリティの問題により、サーバー側のコードが必要になります。
一般的に起こることは、両方を行うことです。必要に応じてサーバー側のロジックを記述しますが、同じロジックを JavaScript で記述して、ユーザーへの応答を高速化し、状況によってはサーバーの余分な作業を少しでも節約できるようにします。これは、検証コードに特に効果的です。ブラウザーでの検証チェックに失敗すると、http 要求/応答のペア全体がサーバーに保存される可能性があります。
私たちは全員 (大部分) プログラマーなので、新しい問題をすぐに発見する必要があります。同じロジックの 2 つのセットを開発するための余分な作業だけでなく、それを維持するための作業、プラットフォームに起因する避けられないバグがうまく一致しないこと、および実装として導入されたバグが時間の経過とともにバラバラになることもあります。
サーバー側の JavaScript を入力します。アイデアは、一度コードを書くことができるので、サーバーとクライアントの両方で同じコードが実行されるということです。これにより、ほとんどの問題が解決されるように見えます。サーバーとクライアントの両方のロジックの完全なセットが一度に実行され、ドリフトや二重のメンテナンスはありません。また、開発者がサーバーとクライアントの両方の作業で 1 つの言語を知っているだけでよい場合にも便利です。
残念ながら、現実の世界ではうまくいきません。問題は 4 つあります。
- ページのサーバー ビューは、ページのクライアント ビューとは依然として大きく異なります。サーバーは、ブラウザから行うべきではない、データベースとの直接通信などを実行できる必要があります。ブラウザーは、サーバーと一致しない DOM の操作などを行う必要があります。
- クライアントの JavaScript エンジンを制御することはできません。つまり、サーバー コードとクライアント コードの間には重要な言語の違いが依然として存在します。
- 通常、データベースは Web サーバーよりも大きなボトルネックとなるため、コスト削減とパフォーマンスの向上は予想よりも少なくなります。
- ほぼ全員が JavaScript を少し知っていますが、多くの開発者は実際に JavaScript をよく知っていて理解しているわけではありません。
これらは完全に攻撃可能な技術的な問題ではありません: サーバーがサポートする言語を、ほとんどのブラウザーで十分にサポートされている JavaScript のサブセットに制限し、このサブセットとサーバー側の拡張機能を認識する IDE を提供し、ページ構造に関するいくつかのルールを作成します。 DOM の問題を最小限に抑え、クライアントに含める定型的な JavaScript を提供して、プラットフォームを使いやすくします。その結果、Aptana Studio/Jaxer、または最近では Node.js のようなものになり、これは非常に優れています。
しかし、完璧ではありません。私の意見では、これを本当に輝かせるには、落とし穴が多すぎて、互換性の問題がほとんどありません. 最終的に、開発者の時間に比べて追加のサーバーは依然として安価であり、ほとんどのプログラマーは JavaScript 以外のものを使用してはるかに生産性を高めることができます。
私が本当に見たいのは、部分的なサーバー側の JavaScript です。ページがリクエストされるか、フォームが送信されると、サーバー プラットフォームはJavaScript で検証をリクエストします。これはおそらく、残りの部分から完全に独立した Web サーバーへのプラグインとして行われますが、応答は選択したプラットフォームを使用して構築されます。
于 2009-03-27T20:16:26.330 に答える
7
ほとんど使用されていないサーバー側 Javascript の非常に優れた使用法は、データ検証用だと思います。これを使用すると、1 つの JavaScript ファイルを記述してフォームを検証し、クライアント側でチェックしてから、サーバー側で再度チェックすることができます。これは、クライアント側では何も信頼してはならないためです。検証ルールを DRY に保つことができます。とても便利です。
以下も参照してください。
于 2009-03-27T20:16:01.043 に答える
3
Javascriptは単なる言語です。これは単なる言語であるため、ブラウザ、サーバー、他のアプリケーションへの組み込み、スタンドアロン アプリケーションなど、好きな場所で使用できます。
そうは言っても、「サーバーサイドJavascript」で多くの新しい開発が行われていることを私は知りません
于 2009-03-27T20:17:59.353 に答える
3
Javascript は、self/scheme プロトタイプ スタイルのベースと C スタイルの構文を備えた完全に優れた言語です。いくつかの問題があります。Javascript の良い部分を参照してください。問題は、ほとんどの javascript プログラマーがひどいプログラマーであることです。
Google のあるチームは、Rhino on Rails を構築しました。これは Ruby on Rails のような MVC フレームワークであり、JavaScript で記述され、Java VM の JavaScript インタープリターである Rhino で実行されます。この場合、彼らは Java VM を使用する必要がありましたが、高速 (javascript は高速) で、ダック タイピングをサポートし、柔軟性のある言語を取得したいと考えていました。
もう 1 つの例は、CouchDB のようなものです。これは、json をトランスポート形式として使用し、javascript をクエリおよびインデックス言語として使用するドキュメント指向データベースです。彼らは、データベースを可能な限り Web ネイティブにしたいと考えていました。
Javascript は、文字列と dom (xml) の操作、サンドボックス化、ネットワーク化、拡張などに優れています。これらの種類の機能は、Web アプリケーションを開発するときによく行うことです。
とは言っても、私は実際にはサーバー側の JavaScript を開発していません。悪い考えではありませんが、あまり一般的ではありません。
于 2009-03-27T20:22:37.080 に答える
1
クライアントで JavaScript を使用するのは、JavaScript が存在するためであり、言語のリストから選択したからではありません。サーバー上の雑用にはそれを選択しません。
サーバー上で好きな言語を実行できます。実際、好きなだけ実行できます。
javascript は信頼性が高く使いやすいですが、サーバーでの一般的なタスクには労力がかかりすぎます。
于 2009-03-28T02:38:56.833 に答える