Now that TideSDK is effectively dead, I've been looking into alternative 'wrappers' to run HTML/CSS/JS applications as stand-alone desktop applications. The three viable options I have run across so far, are NW.js (formerly node-webkit), brackets-shell, and Electron (formerly atom-shell).
The problem is that there does not appear to be a sufficiently complete comparison between the three in terms of feature set, compatibility, etc. I'm hoping to turn this into a more-or-less canonical thread on the (objective) differences between the three, in particular regarding:
Platform support; operating systems, dependencies, etc.
Language feature support, as far as HTML5, CSS3 and JavaScript are concerned. Think things like "does HTML5 video work, and if yes, what codecs are available?"
Non-standard extra features, such as tray icons, popup notifications, and OS-rendered menu bars.
Extensibility; eg. ability to 'plug in' native code, talk to Node.js, and so on.
Architecture; in particular the architectural differences that affect daily usage as a developer.
Debugging; included development tools, compatibility with commonly used tools like node-inspector, etc.
... and so on.
What are the objective, technical differences that matter when making a choice between them as an application developer?
I did similar research about two months ago, and in the end I went with node-webkit. The biggest upside on node-webkit is node.js and npm. The package management of npm is really nice, and node has well done filesystem access.
Brackets-shell looked interesting, but other than a nice IDE I didn't really get what made this one as good or better than the rest. They are very clear that "The brackets-shell is only maintained for use by the Brackets project ", that screams run away to me.
https://github.com/adobe/brackets-shell#overview
Atom-shell seems to be recently active, but it seems much like brackets in that they are really writing and editor/IDE that just happens to be attached to a webkit runtime. It also is built on top of node.js. This one has the downside of being difficult to search for stuff online without being reminded of your middle school chemistry.
I really don't want an new editor, and most programmers have their favorite already. For the actual application development, they pretty much work the same, and should, since they all use webkit. You basically write 90-95% of it like a website, and then deal with the native parts, and some config.
These things are true for all three of them
platforms - runs on Windows, Mac, and Linux
language support - HTML5, CSS3 and Javascript : since they run javascript you can download and run nearly any library/framework that you want.
The big caveat on webkit is codec support. Typically you will have problems with non-free video codecs, unless you rebuild the dll/so to support them. For example the shipped node-webkit won't play mp4 video.
I've been playing with Atom-Shell over the last few days, and I am loving it so far.
The best part about it is that it's backed by GitHub.. which should allow you to settle into the platform for the long term, especially if it gains a large following. It's also made possible by direct Node.js improvements courtesy of a contract with StrongLoop, who is a major Node.js contributor (they claim to employ more Node.js core developers than any other company, even Joyent).
I've also found it rather comfortable to get started. It took me about a day to learn the structure and get my first proof of concept running. Very cool.
Bullet Points:
Platform support: Windows, Linux, Mac OSX (More Info Here)
Language feature support: HTML5, CSS3, JS via Chromium - so far, zero issues, but I have not tested video specifically.
Native Features: Native App Menus, Task Tray Support, Global Hotkeys, Protocol Handler Support (that I've seen so far)
Extensibility: Excellent Node.js integration, both the client and server can "require" Node.js modules and natives. I've also successfully tested Bower libraries (incl jQuery) without issue.
Architecture: Covered in the other points, but in general its very smooth.
Update (11/25/14): I've not yet found use case for Atom-Shell in any official capacity, but I have used it to build a few small apps for my own use, the most complex being an app that pulls my time logs from my PM software and creates Paypal invoices.
My opinion of the platform remains positive. It's pretty awesome.
On my time invoicing app I successfully brought in Bootstrap 3's Dashboard Example Template and a few node modules (bluebird, Paypal SDK, Teamwork PM Client) to create a mildly complex app. It took me a few days and does its job well.
I really cannot think of anything negative to say about Atom-Shell, its solid, stable, fast, and easy to code for. I hope this helps someone.
Besides fully support Web standards, NW.js supports a list of non-standard features for native app development including:
Protect JS source code by compiling them into machine code: https://github.com/nwjs/nw.js/wiki/Protect-JavaScript-source-code-with-v8-snapshot
Jailed devtools: https://github.com/nwjs/nw.js/wiki/Devtools-jail-feature
Additional security model with which you can do more in DOM: https://github.com/nwjs/nw.js/wiki/Security https://github.com/nwjs/nw.js/wiki/Changes-to-DOM
enhanced file dialog: https://github.com/nwjs/nw.js/wiki/File-dialogs
kiosk mode: https://github.com/nwjs/nw.js/wiki/The-Kiosk-mode
supports for a growing list of chrome.* API, include chrome.webRequest so you can intercept HTTP requests from DOM: https://github.com/nwjs/nw.js/issues/518
support for rich notifications, print preview, many more chrome.* APIs, Chrome Apps and other Chromium features starting from 0.13.0-alpha0
There is much more to see in the wiki including Menu, Tray, etc.
I've been working with brackets-shell for some time now, here are some of my findings:
brackets-shell is primarily developed as a shell under the brackets IDE project, but the project can run any web application. You just need to point it to your own html page. Clint Berry wrote an excellent tutorial about doing just this: http://clintberry.com/2013/html5-desktop-apps-with-brackets-shell/
The project is backed by Adobe and has a lot of activity
Documentation could be better
platform support They support Windows, Mac and Linux. An installer package can also be created. I only tested it on Win and Mac, it works great.
feature support html5, css3, js. Html5 video does not work out of the box, but is very easy to enable (by default the ffmpegsumo.dll is not copied into the installer, if you change the script to copy it it will work).
native features menu bar, 'open file with', file system access. I am not using any of these, as all I need is the communication with the node process.
extensibility a nodejs is built in, and you can communicate with node from your web application. In this way, you can use node to access the filesystem etc.
architecture The project is well set up, keeping a nice separation between the shell project and your own web app running inside it. In your own application, a global appshell object is available which gives you access to the brackets functionality (filesystem access, communication with node process, ...).
One thing to note (if you care), is that the Electron officially does not support Windows Vista. Vista's market share is about halfway between OSX 10.9 and 10.10 (both of which are fully supported by Electron). Vista is also still supported by Microsoft until 2017.
NW.js works fine in Vista, as well as OSX 10.9+. NW.js works on Ubuntu, Debian, Zorin, Manjaro, Arch, and most other Debian based Linux OS's. Electron has refused PR's to fix Ubuntu specific bugs on their platform which is concerning.
NW.js works in XP too. Currently 18% of the market is still on XP. So if you're desktop application is more general purpose or wants to have access to the late adopters still on XP, you're probably better off with NW.js (0.14.7) as Electron only supports Win 7 and up.
If you use NW.js 0.12.3 you can also support OSX 10.6+ and very old versions of Debian based Linux OS's like Ubuntu, and Win XP+. It is recommended that you do special builds just for those legacy systems though and use the newer versions of NW.js for newer OS's.
I am new to PPAPI development and have downloaded the already examples from here
However, even after coming across the documentation,
I am not able to build the project.
I have Microsoft Visual Studio 2010, Windows OS and Chrome:30.0.1599.65
I understand that once a dll is created, using the regsvr32 command will register the plugin, although getting the dll, even with available code, seems tough for me. Any help for building the dll is appreciated.
You will want to start here to download the and set up the SDK: https://developers.google.com/native-client/sdk/download
This page will take you through how to build and run the examples: https://developer.chrome.com/native-client/sdk/examples
This page goes over how to actually create your own plugin: https://developer.chrome.com/native-client/devguide/tutorial/tutorial-part1
And then you should read this entire section to code and structure your application: https://developer.chrome.com/native-client/devguide/coding/application-structure
If you need any third party libraries be sure to check here: https://chromium.googlesource.com/webports
Edit: Forgot to mention that you will want to use the same version of the pepper api as the version of chrome you're running (in this case pepper_30). Also, you have to use the NaCl toolchain (one of either glibc, newlib, or pnacl); you can't use the Visual C/C++ toolchains. I recommend trying pnacl now that it is available, as that is by far the most cross platform version, but if you run into trouble, you'll probably want to use the newlib toolchain as it has better support.
I keep reading conflicting answers to this question, and I can't find a definitive answer in an official Google document.
By suppressing the blacklist I can enable hardware acceleration for almost every rendering feature under chrome://gpu-internals/ but not the 2D Canvas. My system is service pack 3, fully updated. DirectX 9. All drivers for the onboard video (Intel GMA3100) are completely up to date. The chip is quite capable, and I even flashed my mobo BIOS to the latest version as a last ditch effort. I'm thinking that Google just isn't supporting HW accel. for the 2D Canvas under Windows XP.
The problem is that Chrome developers have disabled Canvas HW Accel for XP, it calls Direct3DCreate9Ex from d3d9.dll which is DirectX 9L available only on Vista+, but it is possible to wrap D3D9Ex on Windows XP via WineD3D Direct3D to OpenGL wrapper. (special thanks to WineHQ/Crossover)
Then we need to disable blacklist and disable sandbox in launch options. (Special thanks to BlackWingCat)
I have already managed to force HW accel for Chromium-based browsers for Windows XP/2003. And it works somehow.
System requirements:
CPU with SSE3 feature support, OpenGL 3.0 hardware/software support.
In fact I use video card from "green" company :)
Installation:
1. Copy and paste d3d9.dll, wined3d.dll, libwine.dll into chrome folder where you have chrome.exe, for example "C:\Program Files\Google\Chrome\Application"
2. Copy and replace d3dcompiler_47.dll and libwine.dll into your Chrome folder where chrome.dll is, for example C:\Program Files\Google\Chrome\Application\49.0.2623.112.
3. Add launch parameters "--ignore-gpu-blacklist --no-sandbox --disable-infobars" to your Chrome shortcut. (without quotes)
4. Run Chrome with your modified shortcut
If you experience issues with Chrome after this hack you can just remove launch options from Chrome shortcut it will disable this hack.
Download:
ChromeHW_accel_XP.zip (tested with backported Chrome 50.0.2661.102 beta-m, Opera 37, Chrome 49)
Known issues:
1. Address bar flickers quickly when you type.
2. HTML5 video doesn't work correctly (you need to force to use Flash Player)
Actually, I can report that Opera 36/37 (chromium based) is a way more stable with this hw accel hack.
UPDATE:
New Chromium builds use libGLESv2.dll version 1.2.0.2448. I'm no expert in VB, but it seems as if the new version doesn't need the mod...
HOWEVER -
The new Chromium builds that use this new libGLESv2.dll always crash (And then restart automatically in safe mode) if you try to enable the overriding of GPU blacklist in flags.
If someone can check this out and report back it would be much appreciated (Could this have something to do possibly with the added support for DirectX 11?)
Update patch is released, anyone interested can check
ANSWER To use this and any new features in 11.2, the swf-version needs to be turned all the way up to 15.
My setup:
FlashBuilder 4.6 Build instructions include "-swf-version=13"
Flex SDK version 4.6.0 (build 23201) playerglobal.swc (current one from
Adobe's page,
http://www.adobe.com/support/flashplayer/downloads.html, said to be
11.2 as well)
Standalone debugger projector (11.2.202.228)
Browser flash player plugin (11.2.202.228)
So by my reckoning, I'm up to date in everywhere I should be, to be able to use MouseEvent.RIGHT_CLICK (Adobe Documentation:
http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/events/MouseEvent.html#RIGHT_CLICK) but, if I do
I understand that right-click was initially supposed to be AIR only, but that's supposedly changed, which is supported by the fact that it's in the website documentation and in the class definition for MouseEvent,
I want to play around with a few right-click stuff in Flash, but it seems like something's definitely not working correctly. Anyone got an insight as to what's wrong?
I'm a bit confused by some of the comments, so in case it's me poorly explaining what's going on, so here's an example of my code running and compiled, with source attached,
http://www.tymonrovers.com/seaders/asdf.html
SWF Version in build instructions need to be up at 15... as detailed http://helpx.adobe.com/flash-player/release-note/release-notes-developer-flash-player.html#main_authoring_flash_player
Damnit! I know it looks obvious now, but I do think they should probably detail that in the docs as well, they've got the specific versions of the SDKS for AIR and Flash, but not the swf version info, which while it might sound overkill, would certainly solve irritations like this when you forget that one little bit of a tweak you need to do for new features. Ah well, all working now. :/
-swf-version=15
Is it possible that an adobe air application that runs fine with an older installed AIR runtime stops working or works buggy if it is installed on a system that has a newer version of the runtime installed?
I know by concept this should not be the case - but how is it really?
Yes, this is the case in some applications.
For example, the updater classes broke in my application LinkFinderPro when they released AIR 2.7.
I haven't seen it anywhere else, really, but I had to mention this case.
I don't know if there is some official statement from Adobe about this but I can talk to you from my own experience:
As far as I know, Adobe runtimes, both the Flash Player and Air, have always been retrocompatible and have not had issues like the ones you describe.