ライアン・ダールとのインタビュー。 パート1

このインタビューは、 ライグがケルンで読んだ直後の2010年7月8日にオレグ・ポドセチンとライアン・ダールによって行われました。 Olegは、ITコンサルティングのスペシャリストであるIonsquare Ltdを運営するJavaScriptの愛好家です。



OP：最初の質問は、実際には入門的な質問です。 Node.JSにどうやって行きましたか？ 以前にJavaScriptを使用したことがありますか？ JavaScriptの使用を開始したのはいつですか？ また、イベント駆動型ソフトウェアでも？



RD：契約に取り組み、Cでさまざまな小さなプロジェクトを行いました。通常はサーバー側のイベント駆動型ソフトウェアで、同じコードを何度も書いていることに気付きました。 Cは素晴らしい言語ですが、サーバーソフトウェアを通常プログラムするのと同じスタイルでスクリプトを記述できるものが欲しかったのです。



O.P。：クライアント側でJavaScriptを使用して何かしましたか？



RD：少し。 私はRuby on Railsで多くの仕事をしました。したがって、私はしばしばフロントエンドを扱いました。 それから、Ebbという小さなRuby Webサーバーを作成しました。これはMongrelよりも高速であるはずです。 このコードはNodeの出発点でした。



O.P。：Ebbは主にCで書かれていますか？ それで、あなたは最初にRubyでそれを書いて、それからCでそれを書き直しました、そして今あなたはJavaScriptでそれを書き直しましたか？



RD：そうです。 元々はRubyで、Cでした。しばらくの間、Webサーバーを作成するための小さなCライブラリを持つというアイデアで遊んでいましたが、Cではそのようなことをするのは困難です。 ある晴れた日、「JavaScriptはまさにこのアプリケーションに適した言語です」という幻想がやって来ました。 これは、V8がリリースされた直後に起こりました。



OP：私たちの周りには常に2つの言語があります：CとJavaScriptです。 JavaScriptを汎用プログラミング言語としてどう思いますか？



RD：JavaScriptには、他の動的言語とは大きく異なる特定の特性があります。つまり、スレッドについての考えがありません。 彼の並行性モデルは完全にイベント駆動型です。 これにより、RubyやPythonなどの他の汎用動的プログラミング言語とは少し異なります。 少なくとも特定のクラスの問題については、たとえばIRCサーバーを作成する場合など、JavaScriptの方がはるかに簡単にプログラムできることがわかりました。



O.P。：JavaScriptの将来をどう見ていますか？ JavaScriptはサーバーだけでなくデスクトップコンピューターでも一般的になっていると思いますか？



RD：JavaScriptは、すでにグラフィカルインターフェイスを構築することにより、多大な作業を行っています。 おなじみのブラウザのようなAPIを使用すると、JavaScriptもデスクトップアプリケーションに適した言語になります。



O.P。：JavaScriptは構造が不十分であるため、人々はJavaScriptコードをコピーして貼り付けるだけです...



RD：はい、モジュールインフラストラクチャの不足が邪魔です。 JavaScriptによって、人々はすべてをグローバル変数に保持します。 これはJavaScriptにとって真の災害ですが、最終的には、ベストプラクティスがこの種の問題を克服できます。



OP：はい、ECMAScript 4とECMAScript 5に関する議論を見ていますか？



RD：言語はシンプルでなければならないというCrockfordの意見に同意します。 JavaScriptの優れた点の1つは、そのシンプルさです。 彼は、これらのことや他のこと、特に入力/出力に関する方法について多くの概念を定義していません。 ECMAScript 4仕様はI / O APIを定義していませんが、さらに多くを定義しています。 彼女は多くの重大な変化を特定しました。 ただし、ECMAScript 5にはさらにいくつかの機能が必要です。



O.P。：どういう意味ですか？



RD：それは何と呼ばれていますか？ 破壊的な流用？ 右側に配列があり、左側に変数のリストがあり、このように定義できる場合。 それはいいだろう。



O.P。：Rhinoに含まれていますが、V8には含まれていません。



O.P。：それでは、ノードに移りましょう。 プロジェクトに関連してあなたがした中で最も難しいアーキテクチャ上の決定は何でしたか？



RD：私にとって最も難しいことがわかったのは...私の最初のアイデアは、純粋にノンブロッキングシステムになることであり、モジュールシステムやその他の領域で多くの方法でそれを放棄しなければなりませんでした。 ブラウザでは、scriptタグを介してJavaScriptをロードすることは非ブロッキング操作です。 OnLoadが呼び出されるまで、スクリプトがいつ完全に実行されるかは本当にわかりません。 ノードは最初は同様に機能しました。 多数のモジュールファイルをロードできますが、ロードされたイベントが生成されるまで、それらがすでに完全に解釈されたことを知りませんでした。 少し難しくなりました。 この操作の直後に「必要」を実行してそのコードの使用を開始することはできず、ダウンロードしたコードの使用を開始する前にコールバックを待つ必要がありました。



OP：Hello World！アプリケーションには別のインデントがありました。



RD：そうです。



.P。：しかし、JavaScriptが提供する利点の1つは、ブラウザーのようにどこでもJavaScriptを使用できることだと人々が言うので、これは面白いです。 サーバー上と同じデータ検証ロジックをブラウザーと同じように使用できますが、CommonJSモジュール仕様はブラウザーでは機能しないため、モジュールの非同期ロードを使用してライブラリーを作成しようとします。



RD：はい。そのため、アーキテクチャソリューションの選択の複雑さの観点から、Nodeをブラウザ環境のように見せたいと思いました。 たぶん彼は同じメソッドを使用していませんが、似たような名前のメソッドを作成すれば、同じ構造を簡単に移植できます。 Nodeはもともと完全にブラウザのようなものを実現しました。 最初のバージョンでは、彼はウィンドウオブジェクトを定義しました。 時間が経つにつれて、このAPIを削除しました。サーバー環境がブラウザー環境とまったく同じである必要はないことが判明したためです。 そこで、CommonJSモジュールシステムを選択しました。これは非常に合理的です。 CommonJSグループのメンバーはモジュールシステムに多くの注意を払っており、私のバージョンを考えるのにあまり時間をかけたくありませんでした。 はい、requireはブロッキング操作であり、Nodeでロックを使用するその他のマイナー操作がいくつかあります。 一般に、この実用的なアプローチ-非ブロッキング操作を99％の時間実行しますが、複数の同期操作を許可することはうまく機能します。 モジュールを同期的にロードするという事実は、おそらくサーバープログラムにとって重要ではありません。