Node-webkit version 0.4.1 innovations

Three days ago (February 1), Roger Wang announced the release of a new version of the node-webkit engine - a powerful combination of WebKit and Node.js created in the bowels of the Intel Open Source Technology Center, which allows you to create cross-platform graphical applications using web development in HTML, CSS and Javascript

The new version has the number 0.4.1 ; on its basis it is not difficult to compose and run, for example, this window:



Almost seven weeks have passed since the day (December 18), when I reviewed one of the previous versions (0.3.6)this engine. You can easily notice that during this time, not only the last, but also the penultimate figure of the version managed to change. Now I will tell you what changes in node-webkit have occurred, this change reflects.

First of all, it is necessary to mention the release plan for node-webkit for 2013 published on January 18 . It is planned that a new large version of node-webkit (with a change in the penultimate digit of the version) will appear every two months (for example, 0.5.0 will be released two months after 0.4.0), and new major improvements will appear with each such release ( e.g. at 0.5.0expected to print pages); in addition, each such version will be based on fresh (at the time of its release) versions of Node.js and Chromium. Smaller versions (such as 0.4.1) will begin to appear more often, but contain only smaller improvements and bug fixes.

I must say right away that the transition from 0.4.0 to 0.4.1 was accompanied by the correction of more than half a dozen rather unpleasant bugs, of which one was serious (the program crashed when trying to connect and use the plugin). I even involuntarily wondered if it should not be cautious in the future to refrain (as from unstable) from using those versions whose numbers end in ".0".

Here is the list of other innovations of version 0.4.1(compared to 0.3.6):

• An application running on the node-webkit engine can now set any value for the “ User-Agent ” header in the HTTP request to remote sites. For this purpose, it is enough to change the value of the " user-agent " field in the application manifest . Inside this value, you can use some keywords that will automatically be replaced by the version or name of the application, the version of node-webkit or WebKit, information about the operating system and processor capacity (similar to those available in popular browsers). If the value of the " User-Agent " header is not changed, then it indicates the version of Chromium on whichnode-webkit is built.
   
• The means of remote control of the computer have been seriously expanded: trusted remote pages opened in node-webkit provide access to the Node engine in accordance with a certain white list. This list of trusted sites is indicated in the application manifest as the value of the field with the name " node-remote " that I invented. The list is compiled completely according to the same rules as the list of local sites (which you can access the browser directly without a proxy) -in other words, it contains a comma-separated list (or a semicolon) of a number of patterns, which can be site names (for example, “example.com”, “* example.com”, “* .example.com”, “* example. com: 99 "," https: //x.*.example.com: 99 "), or domain suffixes (" .example.com "," .com "," http: //.example.com "), or IP addresses (“127.0.1”, “[0: 0 :: 1]”, “[:: 1]”, “http: // [:: 1]: 99”), or IP ranges ( “192.168.1.1/16”, “fefe: 13 :: abc / 33”), or simply the keyword “"(Corresponding to the list" 127.0.0.1, :: 1, localhost "). Now you can keep some of the source code of the application on your site (both scripts and interfaces), and it will work on the computer on the user through the Node API. One possible solution to the software update problem.
   
• An HTTP authentication dialog has appeared in case a remote site asks for a name and password.
   
• The document.cookie API for local pages is supported .
   
• The " chromium-args " field (for simulating Chromium command line arguments: for example, "--enable-webaudio-input" for experimenting with the getUserMedia API) and the " js-flags " field (for setting V8 parameters: for example, appeared in the application manifest "--harmony_proxies --harmony_collections" to access part of the Harmony JavaScript features).
   
• The API “ require (" nw.gui ". Window.open () " has been replenished with a new field "new-instance" , through which you can start a new instance of the Node process and WebKit in a new window.
   
• The same Window object has a zoom property (and an event of the same name), reflecting the intra-browser increase in the site. In some cases, this is easier than changing the font-size for the body .
   
• You can follow hyperlinks with non-browser protocol names (for example, “ mailto: ” or “ area: // ”), and they will be fed to handlers registered in the operating system.
   
• The process.mainModule property will begin to point to the main script registered in the "node-main" field in the application manifest .

As you can see, almost a dozen useful innovations have been accumulated - and each of them will please someone , because it simplifies the life of developers.