すべては単純なアイデアから始まりました。次のようなものを書きたいと思いました。
include( "path/to/someLibrary.js" );
以下では、スクリプトsomeLibrary.jsで宣言されたオブジェクトを使用します。 それで図書館が現れた
ヘリオスカーネル 。
このライブラリは、 include（）関数を定義し、ファイル間の依存関係を監視し、必要なソースがそれらを使用するコードが呼び出される前に初期化されるようにします。
その結果、各スクリプトは次のようになります。
// include( "path/to/someLibrary.js" ); include( "path/to/someOtherLibrary.js" ); function init() { // - , // , , someLibrary.doSomething(); var mySomething = new someLibrary.Something(); someOtherLibrary.doSomethingElse(); }
パスがinclude（）のパラメーターとして渡されるスクリプトはすべて同じ構造でなければなりません。つまり、コードはinit（）関数内にある必要があり、 include（）を介して依存関係を宣言できます。 Helios Kernelは必要なスクリプトを接続し、必要な順序で初期化します。
更新する ：ここでは、スクリプトをダウンロードするために、このライブラリが他の多数のライブラリとどのように異なるかを説明するのが適切でしょう。 Helios Kernelは、モジュール間の依存関係の定義に対して同じアプローチを提供します。これは、他の多くのプログラミング言語で使用され、通常はそのまま使用できます。これは、モジュール自体のヘッダーでモジュール依存関係を定義する機能です。 つまり、現在、あるモジュールをロードする必要がある場合、動作する必要がある他のモジュールをプリロードすることを心配する必要はありません。 モジュールの依存関係の指定は、モジュールの作成者のタスクであり、ユーザーのタスクではありません。 ユーザーは、何らかの種類のモジュールが必要であると報告するだけで、Helios Kernelライブラリ自体が必要な依存関係をダウンロードし、適切な順序で初期化します。
このライブラリをできる限りシンプルにしようとしました（機能面）。 また、自然にそれを補完するいくつかの有用な部分が含まれています。
ライブラリは、実行時に必要なスクリプト（すべての依存関係とともに）を動的にロードおよびアンロードするために使用できるkernel.require（）およびkernel.release（）の 2つのより便利な関数を宣言します。 次のようになります。
// - // AppController.prototype.doSomethingHandler = function() { // this.magicLibraryTicket = kernel.require( "path/to/magicLibrary.js", function() { // , // magicLibrary.doSomething(); } ); }
// , , // AppController.prototype.stopSomethingHandler = function() { // magicLibrary.stopDoingSomething(); // , kernel.release( this.magicLibraryTicket ); }
これらの2つの関数（ kernel.require（）およびkernel.release（） ）は、ある種のスクリプトが必要であること（または、ある種のスクリプトが不要になったこと）をライブラリに通知します。 ライブラリ自体は、ロードとアンロードが必要な場合、たとえば、あるスクリプトが別の場所でも使用されている場合、 kernel.release（）の要求でアンロードされないことを決定します。
さらに、Helios Kernelはあらゆる種類の奇妙な状況に対処できます。 たとえば、 kernel.require（）関数には、3番目のオプションパラメータがあります（ロードする必要があるスクリプトのパスと、このスクリプトのロード時に呼び出す必要があるコールバックに加えて）。 この3番目のパラメーターは、スクリプトの読み込みエラーの場合に呼び出される別のコールバックです（たとえば、ネットワークに問題がある場合、または循環依存関係が見つかった場合）。 ロードできなかったスクリプトのパスは、このコールバックを呼び出すときに唯一の引数として渡されます。
Helios Kernelライブラリには便利な関数getStatistics（）もあり、ロードされたスクリプトのステータスに関する詳細情報を報告します。 この関数を使用して、インターフェイスのインジケーターを使用して、読み込みプロセスをユーザーに通知できます。
すべての詳細については、ドキュメント（290 kb）で説明しています： helios-kernel-0.9-guide.pdf
ここからライブラリをダウンロードできます（8 kb）： helios-kernel-0.9.tar.gz
プロジェクトのホームページは、 home.gna.org / helios / kernelにあります （ただし、同じことについては英語で簡単に説明しています）。
背景
2年前、私はこのメモを公開しました： Helios Javascript Framework 。 その中で、Webアプリケーションを開発するためのフレームワーク全体をどのように作成するかについて話し、魅力的な計算機を使ったデモを示しました。 この単純なデモには非常に多くのコードが含まれています。実際、そこにはウィジェットライブラリが実装されています。 しかし、広く使用される場合、これらの開発はほとんど役に立ちませんでした。 私はそれがどのように機能するかをすぐに見たかったので、すべてが急いで書かれており、コードのドキュメントでスコアを付けました。 ただし、ドキュメントはここでは必要ありません。彼らが言うように、それは概念実証であり、ウィジェット用のライブラリを作成する最初の試みでした（したがって、非常にひどいです）。
計画どおり、Heliosフレームワークは、スクリプト間の依存関係を解決するメインライブラリの上で動作する一連のライブラリで構成されています。 したがって、Helios Kernelライブラリにはそのような「哀れな」名前があります。ライブラリとウィジェットを使用して、フレームワーク全体を終了し、一度解き放つ十分な時間と意志があることを願っています。
計算機を使用したそのデモには、独自のHelios Kernelもあり、これはinclude（）関数の基本機能を提供し、必要な依存関係をロードしました。 しかし、そのカーネルはウィジェットライブラリと同じくらいひどく原始的でした。 一般に、フレームワークを使用した実験は成功したと判断したため、密接に対処する必要があります。 そして、彼はカーネルを書き始めましたが、すでに思慮深く、人々のために、ドキュメントと共に。
私にとって、このプロジェクトは、私が仕事で行うことに対するちょっとした対抗策です。 予算、希望のある顧客、期限、制限はありません。 時には何ヶ月もプロジェクトに取り組みませんでしたが、時には逆にアヒルといつも考えました。 数回、すべてが完全に異なる方法で変更できるという考えがあり、それがより良く/より速く動作するという考えがありました、そして私はそうしました-すべてをゼロから書き直しました。 そして、私がHelios Kernelを「完璧な」状態にするまで続けました（私の意見では）。 さて、あなたは上記の結果を見ることができます。
今、私はさらにコーディングするものを考えます。 私の次のレポートが2年よりも早くなることを願っています:-)