Recently stumbled upon node-webkit, an open-source from Intel Open Source Technology Center, which is deliciously “simple”: combine a standalone webkit (Chromium) build and node.js into a runtime.
Webkit/Chromium brings a high-performance HTML5 environment with JavaScript JITting compiler, WebGL, Audio, hardware accelerated Canvas, camera access, etc.
Node.js brings high-performance access to the local machine resources, so that HTML5 apps can break out of the browser and get access to the file system, databases, server sockets, etc. Just like any other regular application. Check the wiki for more details.
Could it be a game changer?
You get many of the capability of managed frameworks ala .Net / Java with the deployment convenience of a native application.
Node.js asynchronous design means it will just run circles around anything else in a variety of I/O scenarios, and the JavaScript V8 engine can duke it out not just with Java & .Net JITters, but also many native compilers.
- The runtime is available for Windows, OSX and Linux, so you’re instantly cross-platform.
- Bundling Chromium means you’re no longer dependent on the browser available on the target machine, its updates… or lack of.
- You just deploy an exe with a few (optional) companion DLLs (which you can just place alongside the exe).
- No registry hacks needed: the apps are portable and can run just fine from an USB stick f.i.
- Application options are controlled by a simple json manifest
Bundling an HTML5 SmartMobileStudio App
I couldn’t resist the temptation to bundle WarTrail, my entry to the recent PGD Challenge as a node-webkit app. The node-webkit runtime stands at about 13 MB in an installer, which is a lot lighter than .Net or Java runtimes, and not so heavy compared to some native frameworks I won’t name whose executables start at 8-9 MB.
If you have a lot of resources and data, it becomes a quite acceptable overhead (f.i. media for WarTrail stands at nearly 17 MB compressed, which is light by modern game standards).
You can download the resulting installer (30 MB, built with node-webkit 0.3.4 & InnoSetup). The app app starts instantly and runs at high speed. Memory usage remains quite reasonable given the media resources involved.
For those that want to try it in Linux or OSX, grab the node-webkit precompiled binaries there (scroll down to “Downloads”), the get WarTrail.zip (17 MB), rename it to “WarTrail.nw” (sorry, server doesn’t recognize .nw extension), and feel free to report back on the bundling capabilities of node-webkit on those two systems.
So there you have it, with node-webkit, a SmartPascal app can look like a native app, behave like one, and access resources like one.
Looks very interesting. Just a note however, your link to download the installer is invalid.
@Robert
Oops, fixed now. Thanks.
Yes, looks very promising and cool!
But, ask some indelicate question: when will support nodejs in the Smart,
and in general, the project alive or not?
Just about to start with it, but there were doubts.
Eric, kindly, give at least some information either about Smart mobile studio!
Even though JavaScript is cool and super flexible, the fundamental problem is that IDE’s for it are all inadequate.
You can create class definitions on the fly, evaluate script on the fly, and it’s not uncommon to dynamically load new and unknown code via http. Add to that the lack of a proper typing system, and the lack of a unified gui widget set, and you’ll understand why there are no IDE’s that let you develop large applications as fast as with something like Delphi.
I’ve done my share of hardcore javascript development, and i still do it on a daily basis, because there is no real alternative for client-side web stuff. Delphi still produces higher quality apps in less time.
There are environments that can help you out a bit for special cases, but in general, as soon as your js code reaches a certain level of complexity, most IDE’s turn into sluggish versions of notepad.exe with syntax highlighting slapped on top of it.
@Sergionn: An update of Smart Mobile Studio is just around the corner. And an updated roadmap right after that.
Since our main developer has been unable to work for the last three months, we have had some issues with the development progress and public activities (new letters, blogs, social media etc). The main developer is now back and we have reorganized the project to avoid such situations in the future. Over the next months we will provide some nice updates, and we will publish several how-to articles in our blog.
@Wouter: Have you tried Smart Mobile Studio yet? The whole idea with Smart is to accommodate the issues you raise…
@Jørn E. Angeltveit
Thanks for your reply, wait that you have prepared in update!
In the context of node-webkit, it should already work, there are just no typed imports / ready-made external classes for that (so you invoke node from you would in JS, through variants and without strong typing). Though that may change soon.
The accident has been a major setback, but portions of the compiler & RTL kept evolving and there is a big pile of new things for the release notes.
A new beta is planned for very soon (hopefully before the end of newt week maybe sonner) to make available all that has changed.
Indeed, in the typicaly “JavaScript is the asm of the internet”, asm is a keyword, as it’s true in many ways.
These days more and more environments target HTML5+JS, with the aim of only needing to look at JS in situations where you would look at asm in Delphi code.
What is the main difference between node-webkit and PhoneGap, if I understand well, they are for the same goal?
They are for building “native HTML5” applications where core logic is written in JavaScript (e.g. using jQuery Mobile) or with something which spits out JavaScript as SMS.
What interests me, what is best approach to develop hybrid application, so that the core logic (aka server) is written in Pascal (and compiled with Delphi or FPC) and the UI part (aka client) is build as “native HTML5”?
Currently node-webkit only does desktop platforms (though mobile ones are planned at a later stage), while PhoneGap only does mobile platforms (the desktop phonegaps out there are for testing and debugging mostly).
Node.js was designed to cover all server-side, UI-less aspects, from serving http requests to connecting to database, read/write files etc.
In node-webkit, all the UI aspect, and some of the hardware aspects (such as camera) are handled by HTML5, where node-webkit guarantees you have an up-to-date environment that supports modern HTML5 extensions in a deterministic way (no need to have FireFox-specific callbacks, sorry-can’t-do-because-you-are-using-IE, etc.).
PhoneGap on the other hands aims to supplement mobile browsers with access to file, camera, compass, etc. so it’s much more restricted in scope and targeted squarely at plugging mobile apps needs. Also PhoneGap doesn’t come with a browser, you’re using the built-in browser of the mobile platform (ie. it’s lighter, but you are stuck with what’s available).
Hello Eric,
This new process of writing Delphi code is truly revolutionary 🙂 And I am very gladly surprised you have already shown an easily installable installer with node-webkit and inno install.
I have tested some of my own Delphi code: I will probably demo “triangulator” soon, a 2D triangulation lib and demo initially developed in by me in Delphi. Triangulation is quite processor-intensive so a good benchmark for SMS.
I have some remarks and questions:
– some Delphi keywords are not (yet) in DWS, for instance inc(integer) and dec(integer). It is not too difficult to rewrite the code but it would be a pre to have these keywords in DWS too.
– I found that scope and inheritance works different between Delphi and DWS. IE in one unit, I can access private fields of a class in a descendant class in Delphi, but not in DWS. Also not too difficult to rewrite, not too much of a problem.
– The “design” pane of SMS is rather bare-bones still, and even tho I found a “properties” pane, there is no “events” pane still. I did find out they can be implemented but right now this means delving down to grunt code work.
– There is no full “VCL-like” component library yet in SMS.
Besides these hindrances, I do think SMS holds a huge promise, and I will certainly work with it in the future!
(Idle?) wish-list:
TVirtualStringTree look-alike in SMS.
If time permits, I will also make “smart” versions of NativeXml and NativeJpg.
Kind regards, Nils Haeck
The new SMS version is just around the corner, I hope it’ll get out soon as there are many, many language improvements since the last release!
These should already work.
This has been fixed/changed: classic units (with an interface/implementation) now follow the same rules as Delphi, mixed mode units (with interface & implementation combined) follow the script rules (ie. private/protected are strict).
Other Delphi-compatibility features are being introduced, f.i. safecall/stdcall/cdecl qualifiers now only trigger a strict-level hint instead of being syntax errors.
Some things won’t ever be 100% delphi compatible (like pointers stuff), but the backward-compatibility gap is being reduced whenever reasonnable.
Yeah, this part of the IDE is still WIP there.
Ad interim, the new lambda syntax can greatly reduce the amount of verbosity.
That should be interesting! Hoping to see your new code! 😉
I have been developing a very large node.js game server for the past 10 months. I am getting a great tooling experience in WebStorm from JetBrains. Probably now my favorite IDE. Just FYI