Application development for node-webkit

Question

Hello everyone, share your experience in developing desktop Web applications with node-webkit. I would like to hear the opinions of people who actually made applications on it for subsequent distribution.

How suitable is this platform for development and release today? What pros/cons/problems can you highlight?

Do you provide obfuscation of JS code (including server code) or some other code protection? In particular, are you using v8-snapshot creation ?

Share your experience, very interesting.

Answer 1

Two applications went into production: one , two . Both programs work with devices through a COM port. In the first case, I didn’t pack the shell in the webkit node, but used the local web server, where the main logic was located and it dynamically generated the GUI in html and there are a couple more Ajax scripts. This is due to the fact that initially I planned to do everything in the browser, and only then I found out about the webkit and used it. So to speak, a test of the pen - does it make sense to switch to a web GUI.
The second option went a slightly different way: separated the logic of the program and the GUI, respectively, all the logic of the GUI in JS with menus, drag and drop and other goodies, all the logic of working with the device in a separate application with a web socket server.
I must say that websockets are quite a convenient mechanism for interacting with the browser. GUI attached a node-webkit to the executable, I haven’t applied protection yet, but I plan to. So that there is at least something, because it is still unpacked in TEMP and everything lies / remains open there. Ideally, I would like to make a slightly different mechanism of work: so that it is not unpacked to disk, but immediately used from memory. But it doesn't matter who needs it - it will simply dump the process's memory and pull out everything that it needs. The delay time on the localhost is on average 1-2 ms, which is very good. The only peculiarity: the web socket server must be made with several streams to receive data, otherwise the packets are lost with a continuous stream from the browser. That is, in a cycle from the browser, messages go to the server, and due to the nature of the data, all messages must be processed in turn in one thread: just writing three numbers into a variable (i.e. no resource consumption), so all the same, most of the messages do not reach. Therefore, I just made a queue for JS and a message about receiving from the server.
In general, at the moment I can say for sure that the experience is generally positive, the GUI changes and redesigns very easily, regardless of complexity. Again, glitches/bugs in the GUI do not crash the entire application and user data.