Helios Kernel (convenient include in Javascript)

    Hello World,

    It all started with a simple idea: I wanted so that I could write something like that in the header of the script

    include( "path/to/someLibrary.js" );
    

    and below use the objects declared in the script someLibrary.js . So the Helios Kernel library appeared .



    This library defines the include () function , monitors the dependencies between files, and ensures that the required sources are initialized before the code that uses them is called.

    As a result, each script looks something like this:

    // инклудим требуемые скрипты
    include( "path/to/someLibrary.js" );
    include( "path/to/someOtherLibrary.js" );
    function init() {
        // эта функция - инициализатор нашего скрипта, здесь можно
        // использовать объекты, объявленные в скриптах, которые мы заинклудили
        someLibrary.doSomething();
        var mySomething = new someLibrary.Something();
        someOtherLibrary.doSomethingElse();
    }
    

    All scripts, the path to which is passed as a parameter to include () , must have the same structure, that is, their code must be inside the init () function , and they can have their dependencies declared via include () . Helios Kernel connects the required scripts and initializes them in the desired order.


    Update: Here it will probably be appropriate to explain how this library differs from a dozen other libraries for downloading scripts. Helios Kernel provides the same approach to the definition of dependencies between modules, which is used in many other programming languages ​​and is usually available out of the box there - this is the ability to define module dependencies in the header of the module itself. That is, now, if you need to load some module, you don’t have to worry about preloading other modules that it needs to work. Specifying module dependencies is a task for the author of the module, and not for its users. The user simply reports that he needs some kind of module, and the Helios Kernel library itself downloads the necessary dependencies and initializes them in the appropriate order.


    I tried to make this library as simple as possible (in terms of functionality). It also contains several useful pieces that naturally complement it.

    The library declares two more useful functions: kernel.require () and kernel.release () , which can be used to dynamically load and unload necessary scripts (along with all the dependencies) in runtime. It looks something like this:

    // пользователь нажимает какую-нибудь кнопку
    // и в контроллере приложения вызывается обработчик
    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 );
    }
    

    These two functions ( kernel.require () and kernel.release () ) inform the library that some script was needed (or that some script is no longer required). The library itself decides that when it is necessary to load and unload - if, for example, some script is also used in another place, it will not be unloaded at the request of kernel.release () .

    In addition, Helios Kernel can cope with all sorts of strange situations. For example: the kernel.require () functionthere is a third optional parameter (in addition to the path of the script that needs to be loaded, and the callback that needs to be called when this script loads). This third parameter is another callback that is called in case of an error loading the script (if, for example, there were problems with the network, or a cyclic dependency was found). The path of the script that could not be loaded is passed as the only argument when calling this callback.

    The Helios Kernel library also has a convenient getStatistics () function that reports detailed information about the status of loaded scripts. This function can be used to inform the user about the loading process using some indicator in the interface.

    Everything is described in more detail in the documentation (290 kb):helios-kernel-0.9-guide.pdf You can
    download the library here (8 kb): helios-kernel-0.9.tar.gz
    The project home page is here: home.gna.org/helios/kernel (although it says about the same thing , only briefly and in English).

    Background


    Two years ago I published this note: Helios Javascript Framework . In it, I talked about how I was planning to create a whole framework for developing web applications, and showed a demo with a glamorous calculator . This simple demo contains quite a lot of code - in fact, a widget library is implemented there. But for widespread use, these developments were of little use. I wanted to quickly see how it would work, so everything was written in haste, and I even scored on the documentation for the code. However, the documentation is not needed there: it was, as they say, proof of concept, and my first attempt to write a library for widgets (therefore, it is very terrible).

    As planned, the Helios Framework consists of a set of libraries that work on top of a main library that resolves dependencies between scripts. Therefore, the Helios Kernel library has such a “pathetic” name - I hope I have enough time and will to finish and once unleash the whole framework, with libs and widgets.

    In that demo with the calculator there was also its own Helios Kernel, which provided basic functionality for the include () function and loaded the necessary dependencies. But that kernel was just as awful and primitive as the widget library. In general, I decided that the experiment with the framework was successful, and I need to deal with it closely. And he began to write the kernel, but already thoughtfully, for people and with documentation.

    For me, this project is a bit of an antipode to what I do at work. There is no budget, customer with your wishes, deadlines and restrictions. Sometimes for months I didn’t work on a project, and sometimes on the contrary, I figured with ducks all the time. A couple of times it happened that I had the idea that everything could be altered in a completely different way, and then it would work better / faster, and I did so - I rewrote everything from scratch. And this continued until I brought Helios Kernel into some “ideal” state (in my opinion). Well, you can see the result above.

    Now I will think what to code further. I hope my next report will be sooner than in two years :-)

    Also popular now: