Neutralinojs — что ты такое? Или UNIX way там, где не ждали

    Recently, I accidentally stumbled upon a simple advertising note "Neutralinojs - an alternative to Electron, which consumes less memory" , telling that there is such a cool thing as Neutralinojs. The note, as it should be, is very short and does not carry any useful information, except for the advertising slogan "Better than <something popular>!"


    Roughly understanding how Electron and NW.js work and not finding absolutely no mention of the principle of operation of this new and super-cool "miracle beast" in the article, I began research.


    Actually presenting the results of my micro-research!



    Since I consider any new technology as a possible tool, I immediately asked a few questions:


    • Why does it eat at times less memory?
    • What gives more buns?
    • Why should I use this miracle?

    Why don't we eat memory?


    Having rummaged in source codes and two rather informative pictures about architecture, I understood that this project works exactly according to the very UNIX Way, which is loved by all Linux users. The project's philosophy is simple: why invent a new bicycle if you can use it already ready?


    What are the disadvantages of Electron:


    • We carry with Chrome
    • We carry with us Node.js
    • We drag a layer with us so that the two previous ones work together

    Instead, everything is done like this:


    • We don't drag chrome
    • We do not drag Node.js
    • We only drag a layer between some kind of browser and some kind of OS.

    Let's see how exactly this is implemented.


    Architecture



    The whole project consists of 2 parts: server and client.


    The server starts immediately and is a real partisan in the rear of the OS. He can store data, open files, write to files, runcryptorsshell commands Actually, it does everything that can be needed, provides an API for the operating system and communicates via HTTP with the client . He also gives the client everything he needs to display on the screen. Pretty standard server functionality.


    For each operating system, a C ++ server was forked and modified by a file. Under the Mac have not yet found that the fork, so there is no support.


    Customers can be 3 types:


    • cloud - Any program that knows the port on which the server is running can execute commands.
    • browser- The server itself starts the process of a standard system browser with the desired URL. Here the server requires a special TOKEN, which itself inserts into the rendered HTML pages.
    • window- The server starts a special render process that simply displays the system WebView. Here you also need a token

    Here it should be noted that the server can work simultaneously with only one type of client, and you need to specify the type of client in the config using the field mode.


    As you can see, nothing superfluous. By itself, the application on this "framework" consists of the source code, which is obtained by the client as static, and the server itself, which can set either the browser or WebView to the desired URL. This is what true DRY means!


    What are the buns?


    Of the buns, of course, less memory consumption. Since neither Node.js nor Chrome is carrying with it, the data delivered to the client is very small in volume. Also, the developers insist that you do not need to download some incomprehensible builders, you do not need to spend time on compilation and all that.


    Actually, from the pros, that's all, now let's move on to the minuses.


    I just want to make a reservation that the project is very young, lives just over 5 months, but it already proudly carries version 1.1.0, so I think that I have the right to evaluate the product as already ready, and present it the same requirements as to the competitors.

    Sores NW.js


    Here we immediately have a fan of problems that gently migrated from NW.js.


    The first and most noticeable to the user is the delivery of the application. In order for the client to launch our program on his computer, he needs to have 2 main things: neutralino.exeand a folder app/. Inside the folder are stored all the settings (such as the server mode and window title) and, in index.htmlfact, given to the client. The easiest way is to give the user a zip-archive and tell which program to use, but users will still find out what to do wrong, how to do it and what to break.


    To solve this problem in the NW was created by the builder, who knew how to pack everything in exe, along with the ICO and archives. SFX archives were a less obvious solution, but antiviruses, in principle, look askance at them, so it is also not a very good option. The developers themselves are planning to make their own packer, but so far only rumors have been circulating about it.


    The second problem is the entry point. It is always index.html. You cannot do anything about it and even specify another file. All the scripts that the application needs should be loaded into this index.html. The problem is not very big, but it reduces the flexibility of the system at times.


    Some kind of browser


    It's still worse than NW.js or Electron. If in the latter we know for sure the version of the browser that will display our application, then in principle we cannot be sure that the OS will provide us with a WebView that can work with JS. That is, we return to the dashing zero and tinker in all possible ways to get to the very IE 8, which will be the standard WebView on Windows.


    This limits our application in terms of displaying and playing some media files, and this is the main function of applications developed on the principle of "Web for Desktop".


    API


    As the authors strive for minimalism, the API provided by the server does not differ in a variety of methods. I would even say no different forethought. All this nebuystvo described in the same meager documentation .


    The only one who can communicate with the system is the Neutralino server, then we must somehow communicate with it. The communication channel is one-way - HTTP. In fact, all that we are given to use in JS is just a wrapper around the server REST API.


    The whole API can be divided into 3 parts: working with Storage , strongly basic working with FS (read only, delete and create - no frills) and calling system windows and commands.


    And now let's go over the most API design available from JS.


    Let's start with callbacks. Since we have some kind of browser , then ES5, and accordingly Promise, will not work. And since developers don’t tolerate Node.js, they don’t want to use Node-like callbacks. Therefore, each method has 2 callbacks: one for the result and the other for error handling, the format of which, by the way, is not known.


    At the expense of the results: most of the commands, for example, working with OS, pass an object with a field stdout, inside of which there is a string , to a callback . As you already understood, reading large files and even less processing them in any Buffer-like object will fail. In system windows, the result is in a different format; an object with a field is used there file. The question "why, in principle, objects with one field are needed" remains unanswered.


    Now for Storage. In it there are such entities as bucket'y, which are saved as JSON-files next to the source code of the application. At the same time, in order to write data to some bucket, we have to transfer an object with the name of the bucket and its new content. To get the data, we pass only the string - the name of the bucket. No hint of similarity with the standard Storage interface , why do we make our bike ...


    Well, let's talk a little about OS integration. Recall that Electron and even NW offered the possibility of creating their own Context Menu, allowed to hide the window and even create an icon in the tray. This is just not all. And, given the architecture of the solution, never will be. Only the browser and only the REST API, only hardcore.


    What can I use?


    For a long time I thought that if you just need to transfer the registration form from the site to the desktop application, then you can use NW.js and not bathe. If you need something more complicated, something that requires integration with the system in graphic terms, then it is Electron. Yes, each has its own drawbacks, but these are at least some products on which you can make your application.


    But Netralinojs can also be used. For example, some chat will work quite well, only on the server you will need to configure CORS. Any small graphic generator of text configs will be quite good for yourself. For myself, I see this framework only as a platform for small GUI utilities that will need to be run infrequently and not for long. I think you can also remember from your professional activity at least one small product that could work on such a minimalistic platform.


    Conclusion


    The framework is actually very, very raw. His minimalism may be his strong point, but as soon as features are needed that go beyond the API, you will have to switch to either Electron or NW.js.


    I really hope that v1.1.0 is not the last, and that the developers still redo many flaws in the design of their API and provide more flexible options for setting up and behavior of the application. I also hope that they will still find a static server on the pros, which could be forked and used on a Mac.


    Well, and references, to make it more clear:


    Only registered users can participate in the survey. Sign in , please.

    Will you try?

    What have you used?

    NW.js dead?


    Also popular now: