Hello World,
It all started with a simple idea: I wanted to, so that I could write something like in the header of the script
include( "path/to/someLibrary.js" );
and below use objects declared in the script
someLibrary.js . So the library appeared
Helios Kernel .
')
This library defines the
include () function, tracks dependencies between files, and ensures that the required sources are initialized before the code using them is called.
As a result, each script looks like this:
All scripts, the path to which is passed as a parameter for
include () , must have the same structure, that is, their code must be inside the
init () function, and they can have their own dependencies declared via
include () . Helios Kernel enables the required scripts, and initializes them in the correct order.
Update : It will probably be appropriate to explain here how this library differs from a dozen other libraries for downloading scripts. Helios Kernel provides the same approach to defining dependencies between modules as used in many other programming languages ​​and is usually available out of the box there - this is the ability to determine dependencies of a module in the header of the module itself. That is, now, if you need to load a module, you don’t need 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 a module, and the Helios Kernel library itself loads 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 some 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 the necessary scripts (along with all dependencies) in runtime. It looks like this:
These two functions (
kernel.require () and
kernel.release () ) inform the library that a script was needed (or that a script is no longer required). The library itself decides that when it is necessary to load and unload — if, for example, a script is used in another place, it will not be unloaded on request of
kernel.release () .
In addition, Helios Kernel is able to handle all sorts of strange situations. For example: the
kernel.require () function has a third optional parameter (in addition to the script path that needs to be loaded, and the callback that needs to be called when this script is loaded). This third parameter is another callback, which is called in case of an error when loading the script (if, for example, there were problems with the network, or a cyclic dependency was discovered). The path of the script that failed to load is passed as the only argument when calling this callback.
The Helios Kernel library also has a handy function
getStatistics () , which provides detailed information about the status of loaded scripts. This function can be used to inform the user about the boot process using any indicator in the interface.
See the documentation for more details (290 kb):
helios-kernel-0.9-guide.pdfDownload the library here (8 kb):
helios-kernel-0.9.tar.gzThe home page of the project is here:
home.gna.org/helios/kernel (although, it says about the same thing, only briefly in English).
Prehistory
Two years ago I posted this note here:
Helios Javascript Framework . In it, I told that I am planning to make a whole web application development framework, and showed
me a demo with a glamor calculator . This simple demo contains quite a lot of code - in fact, the widget library is implemented there. But for wide use these developments were of little use. I wanted to see how it would work as quickly as possible, so everything was written in haste, and I even scored on the code documentation. However, the documentation is not needed there: it was what is called 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 run on top of the main library, resolving dependencies between scripts. Therefore, the Helios Kernel library has such a “pretentious” name - I hope I have enough time and will to add and once to release the whole framework, with libs and widgets.
In that demo with a calculator, there was also a Helios Kernel, which provided basic functionality for the
include () function and loaded the necessary dependencies. But that kernel was also terrible and primitive, as was the widget library. In general, I decided that the experiment with the framework is successful, and I need to come to grips with it. And he began to write the core, but thoughtfully, for people and with the documentation.
For me, this project is something of an antipode to what I do for work. There is no budget, customer with your wishes, deadlines and restrictions. Sometimes I haven’t been working on the project for months, and sometimes I figured the opposite with ducks all the time. A couple of times it was like this that I had an idea that everything can be done completely differently, and then it will work better / faster, and I did it - I copied everything from scratch. And this went on until I brought the Helios Kernel into some “perfect” state (in my opinion). Well, you can see the result above.
Now I will think what to code next. I hope my next report will be earlier than in two years :-)