JavaScript は、フロントエンドで最も人気があり、広く使用されている言語の 1 つです。バックエンドで広く使用されていないのは不思議ですか?
7 に答える
Google の V8 エンジンのおかげで、より広く使用されるようになっています。Node.jsを見てください。以前はパフォーマンスが低かったため、その有効性が制限されていたと思います。
Node.js を使用すると、マルチスレッドのカスタム Web サービスをあっという間に、ほぼ OOP 方式で作成できます。バックエンドの Javascript が実行され始めたばかりであることがわかると思います。
それを妨げている唯一のことは、他の人が言っているように、きちんとパッケージ化され、標準化された (少なくとも Linux 用の) ドロップイン ソリューションがないことだと思います。このソリューションは、主要なホスティング会社によって採用され、製品提供の一部として追加される必要があります。そうなると、バックエンド サーバー スペースに爆発的に拡大することがわかると思います。
Microsoft は、1998 年以来、 ASP製品とともに、「Javascript」(AKA JScript) を使用してバックエンド システムをプログラムする機能を提供してきました。JScript を使用して ASP.NET アプリケーションを開発することもできます。だから、何も新しいことではありません。ASP または ASP.NET アプリケーションで広く使用されていない理由は、VBScript が "既定" であり、C# が経験豊富な専門家に好まれる言語であるためだと思います。しかし、多くの場合、開発者を企業開発用の 1 つの言語に制限する会社のポリシーを除いて、あなたを止めるものは何もありません。JScript が企業体によってあまり使用されない理由の 1 つは、「もはや積極的に開発されていないように見える」ことです。実際、Microsoft は実際に「販売したことはありません」「JScript を開発者に。または、少なくとも C# や VBScript ほどではありません。だから、それが妨げになったのかもしれません。
JavaScript が人気があり、フロント エンドで広く使用されているのは、必ずしもそれが優れた言語だからというわけではありません。クライアント側コード用に JavaScript を作成するという決定を下す人は誰もいません。すべてのブラウザがサポートしているため、単に必要です。バックエンドでは、他の言語 (Java、PHP、Python、Ruby など) は JavaScript にはない利点を提供します。
編集: 2022 年に、この回答に対して評判を得て、再検討するようになりました。もちろん、12 年後、JavaScript はサーバー側で一般的に使用されていますが、多くの場合、JavaScript は使用されるのではなく、コンパイルの対象となっています。このエンジンはNode.jsです。TypeScriptやPureScriptなどの言語とともに、優れたパフォーマンスと合理的な開発者のエルゴノミクスも実現できます。
私はこれについて専門家ではありませんが、Douglas Crockford は "Javascript: The Good Parts" の中で、JS がブラウザで普及したのは本質的に偶然であり、メリットがあったからではないと述べています。
「Javascript は、悪い部分がたくさんある言語です。存在しない状態から、驚くほど短期間で世界的に採用されるまでになりました。実験室で試して磨くことができる間隔は一度もありませんでした... Java アプレットが失敗したとき、Javascript はデフォルトで「Web の言語」になりました。JavasScript の人気は、プログラミング言語としての品質とはほぼ完全に無関係です。」
ブラウザーが異なれば実装も異なります。標準のインタープリターを使用する言語の場合よりも、何が正しいかを言うのは困難です。
Crockford の本で説明されているように、node.js には優れた機能があり、node.js はサーバー側の開発に優れていることを証明するかもしれません。しかし、これまでのところ、人々が選択できるところでは、ほとんどが他の言語を選択しています。
簡単な答え: はるかに優れた代替手段があるためです。
長い答え: それは完全に解釈されているため (IE6 のようにうまく解釈されないこともよくあります)、環境が提供するもの以外に標準の I/O メカニズムを提供せず、文法が緩いためコードの検証が困難になり、多くの人がプロトタイプを見つけます。クラスベースの OO よりも、ベースの OO を扱うのがはるかに困難です。
歴史の偶然としか言いようがない。Javascript はクライアント側言語として Netscape で生まれ、移行することはありませんでした。
今日の主要なサーバーサイド Web 言語と比較すると、最も明白な違いは、Javascript にはバッテリーが含まれていないことだと思います。標準ライブラリはありません。
これを、Web プログラミングをはるかに快適にする素晴らしい標準ライブラリを備えた Python、PHP、Ruby などと比較してください。
サーバー上では、特定の言語を使用する義務はありません。また、JavaScript は非常に自由な形式であるため、コードの保守が非常に困難になります。
そのため、ほとんどの人が他のものを選択します。
その答えは、クライアント側にとって良いことがサーバー側にとって常に良いとは限らないということかもしれません。たとえば、Javascript (一般的には ECMAScript .. ActionScript も) は非常に緩くて寛容な言語であり、多くのことを回避できます。クライアント側では、これはしばしば許容されるだけでなく、望ましいものでもあります。ユーザー エクスペリエンスを向上させるために、UI をできるだけスムーズで寛容なものにしたい場合がよくあります。
ただし、サーバー側では、通常は別の話です。そのため、サーバー側を支配する言語は、より強力に型付けされ、厳格であると私は信じています。
スケールの問題もあります。クライアント側の UI アプリケーションの一般的に小さなコードベースで機能することは、サーバー側では常に機能するとは限りません。サーバー側は、クライアント側では実際には大きな懸念事項ではない多くの問題に対処する必要があります。たとえば、パフォーマンス、パッケージング、スケーラビリティ - これらは (通常) クライアント コードよりもサーバー コードにとってはるかに重要であるため、サーバー側の作業に JS を選択しない理由は理解できます。