2. Another thing we learnt the hard way is, a lot of JS charting libraries are not meant for plotting streaming data for long period of time. We for example found that, most d3js based charting libraries start to balloon in memory usage if left running for > 1 hour or so.
3. Large executables.
It is still a nice platform to develop on! But if you are stuck with performance problems or something, coding your way out of it is way harder (unless you are willing to get your hands dirty with atom-shell code itself).
As to executables, I think the big issue is that people keep on packaging some variant of Node-Webkit into these sorts of programs. What we need is something like the JVM for Node-Webkit: install once, and then apps only have to ship the application code (like Java apps don't ship with a JVM most of the time).
I think Firefox and Chrome have things, but we need that be unified (and I'm not sure if they're too sandboxed for local apps)
Firefox had things (XULRunner, and later running it via Firefox via WebRT). I have no idea about Chrome.
Experience learned during the XULRunner era is that Mozilla doesn't really want to be a platform, so they don't care very much about API changes. This means that using a shared runtime means apps will randomly break as the runtime is upgraded. Alternatively, you can attempt to keep multiple versions of the runtime around (.Net-style); but since releases are every 6 weeks and downloadable applications don't tend to have that kind of release cadence, you end up with essentially one copy per app anyway.
If the platform actually acts like they want to be a platform (the way Qt does, with supported stable releases spanning years as an app gets developed), that might work?
> What we need is something like the JVM for Node-Webkit: install once, and then apps only have to ship the application code (like Java apps don't ship with a JVM most of the time).
You mean like... a browser? I mean why re-invent the wheel when it's right there. Web standards are already available or are being made to access more OS-specific stuff (like file access, desktop notifications, background processes, offline modes), etc.
Is there anything really wrong with system tray integration being simplistic? I don't need anything more than what atom-shell offers 99% of the time, and if I did, I'd probably be doing it in something other than atom-shell.
I'll look out for memory issues with graphics related javascript libraries though, I was going to use them a lot in an upcoming project.
So, in our preliminary analysis we found out bunch of things:
1. Some charting libraries do not discard a infinitely growing time series data. For example, if you are only displaying 20 data points in graph, holding older data points do not make sense. Obviously this had nothing to do limitation of webkit platform but library under question being sloppy.
2. In few cases, we noticed all those charting tool tips and popovers in case of time series data cause bunch of leaks. Disabling tooltips etc helped reducing memory growth, but did not completely eliminate it.
3. There are indeed some browser bugs, it could be what `/u/wbkang ` is saying or something else. I didn't spend lot of time investigating. Here is a sample app I put together that reproduces the leak in Chrome - https://github.com/gnufied/tryc3 you got to let it run for awhile though (like > 20 mins) .
Not sure if you will see my message, but we ended up using chart.js via Qtwebkit bridge. We got rid of bunch of fluff like labels etc though (and reduced how often charts are refreshed). Even though chart.js is canvas based, its performance is not optimal if you let it run for > 40 mins or so.
Previously, node-webkit looked like a great contender for a universally shippable desktop UI system, but it actually falls on several platforms due to invalid presumptions about locally available dynamically linked libraries [1]. It would be great to see an up-front document about portability promises.
Is it possible to use other languages to drive the rendering via a linked API? Thrust [2] did a good start on defining an API for using the UI components from multiple languages, but it still relies on TCP sockets -- as far as I can tell, there's no way to make my application load assets from "bundle://" and redirect that to custom handler code while forbidding other network access, and the use of a local TCP socket to communicate between the UI and the main application means there's also major reason to be concerned about CSRF attacks on localhost. We should be able to build desktop UIs without these problems. Is atom-shell pushing forward on any of these issues, and if so is there any documentation on how?
Atom Shell still has the libudev problem, you have to ship your own. You definitely can load assets from protocol URLs like bundle:// (though tbh there's really no need to since you have file:// and can look up paths relative to your app).
i recently installed some node-webkit on ubuntu 14.04. They work fine. Dynamically linked to .so isn't a big hassel. Its just small work-around. Such library changes do happen in desktop world. But i agree, a better handling to link dynamic libraries is missing in the scene at the moment.
We're currently using Atom Shell to build the Slack Windows application and everything going really well; the lead developer of Atom Shell is really talented / responsive to issues. We've been open-sourcing interesting pieces of the app to help the community get started building their own production-level Atom Shell apps as well:
Tools like atom-shell and thrust[1] may not integrate into the OS as smoothly as Qt/etc but they do show a lot of promise for web tooling. e.g. shader authoring tools, motion/animation editors, WebAudio API editors, etc.
I don't think feelings are a reliable guide for technical decisions.
In all three cases (Atom Shell, Qt, and JavaFX), one is using a toolkit that's not native to any of the host platforms (unless one is using Qt and targeting a system based on KDE or Qt Embedded). So none of the advantages of using the host platforms' native UI are applicable. One can't avoid distributing the toolkit with the application in any of these cases. So if one is going to develop with that set of tradeoffs, I think it's best to use Atom Shell or some other solution based on the web platform, since many programmers know it -- many more than for Qt or JavaFX.
Qt with QML can use JavaScript, therefor it is possible for developers who are used to the web platform to use it without having to relearn everything, AND it is far more lightweight than Atom Shell.
Sure it is. It is the official replacement for Swing and uses an architecture similar to WPF/XAML.
It is being targeted to everywhere Swing and LWUIT were. It is also being ported to iOS and Android by the community.
Volkswagen is currently researching to replace their Java 1.4 infotainment systems with Java 8 Embedded with JavaFX for the UI. As of Java ONE 2014 presentation.
Nice! I have been looking for an easy way to build a reliable desktop app for some scientific computing code that I've written, so I've been exploring various options, including using node and the Qt libraries.
Feels like a bit of a maze at the moment, so I'm not entirely sure which way to go, but I like the look of Atom Shell. I'd love to hear a bit more about your experiences using it. The discussion on HN about a recent blog post comparing various HTML+CSS+JS solutions to building desktop apps was definitely insightful [1].
I'm also looking at using something like Atom Shell as a way for me to build a project that would allow me to kickstart my JS learning curve.
Sure, we built the prototype with Python, Django, and a web interface. The idea being a user could run it and then just browse to localhost:<some port> and use the web UI for it.
We quickly realized the app was going to be 99% Javascript anyway so using something like atom-shell started to make a lot of sense.
We originally were targeting just OSX and Linux desktops, but using atom-shell opens up a path to Windows desktops much more easily for us.
The app needs to display a large of amount of changing data from the local machine and atom-shell + ReactJS, so far, is handling it just fine.
@ibdknox ported Light Table from node-webkit to atom-shell a few weeks ago (https://github.com/LightTable/LightTable/tree/atom-shell). I haven't looked at it myself, but I heard some noises from him about easier deployment and smoother UI (possibly from better handling of the webkit and libuv event loops).
I been using node-webkit + THREE.js for an app, and really enjoying it. This looks interesting, but are there any major differences between in and node-webkit that would interest me in switching? There doesn't seem to be a comparison section in the readme.
THREE.js... is that related to node-webkit, or it's just what you're using to do unrelated 3D stuff? (are you using three.js to draw window chrome, for example)
afaik, node-webkit has some features that Atom Shell doesn't like window transparency, but because node-webkit heavily patches Chromium itself, it typically lags further behind in Chrome (Atom Shell is currently at Chrome 39, whereas node-webkit just hit 38, and was previously stuck at Chrome 30).
I initially started using node-webkit a couple of weeks ago but I decided to have a look atom-shell last week.
I miss how thorough, relative to atom-shell, the docs are for node-webkit, but atom-shell does seem more mature and thoughtful in the way things have been implemented. Nide-webkit's iframe changes are a bit ugly, but atom-shell's webview element is nice and clean, plus it looks as though Mozilla want to standardise something similar.
Has anyone seen issues with the separate browser and application processes? I haven't had any yet but I feel that I might run into issues soon.
Why? You're already running an x86 "interpreter" (aka native code) as root, which is arguably even more dangerous than Javascript because of unsafe memory access.
Does something similar exist for iOS and Android apps? In other words, could someone opine on what's the best way to create mobile apps that are wrappers around web apps.
Is the common approach to create a native app with embedded browser or is there some other way?
we've been using https://github.com/MobileChromeApps/mobile-chrome-apps for a while, pretty awesome. It's basically Cordova + some chrome APIs + embedded CrossWalk, meaning it ships the embedded (latest) chrome as part of your app.
Having done a fair bit of Titanium development, I wouldn't classify it as a solution for the parent's query. Yes, it is executing JavaScript via the OS's JS engine, but it is drawing native widgets, and jumping between the JS framework and the native side can be slow.
PhoneGap (Cordova) is a much better solution, I think.
is mozilla missing out on the scene of desktop app? what's next after xulrunner?
Also, i have a legacy app written with xpcom like components. Is atom shell a right platform if i decide to re-write the old xulrunner based application with new platform such as atom-shell, node-webkit or qt may be?
Are there any licensing issue with atom-shell for desktop apps?
what about support for other architecture than x86. I saw some support node-webkit for armv7. Anyone have experience with desktop app running on arm based os such as ubuntu arm.
It seems like a very nice kit, but I think I'd rather just use the native WebView that comes with the OS. Once you embed the browser engine, everything else is easy and you have a lot more flexibility with what can be done natively.
It depends what you're building. Sometimes it is useful to target one specific browser engine because there are too many discrepancies among browsers. With an atom-shell you only need to target Chromium, and then only one version. When the Chromium version changes in atom-shell you can retest everything before any of your customers see it.
Also, some of the native web views are woefully behind the times when it comes to implementing the latest HTML5 goodies (IE is notorious for it, of course, even now, but Safari is far from innocent in this respect).
1. Limited integration with desktop environment. Have a look at System tray integration for example, https://github.com/atom/atom-shell/blob/master/docs/api/tray... in many cases it is just too simplistic.
2. Another thing we learnt the hard way is, a lot of JS charting libraries are not meant for plotting streaming data for long period of time. We for example found that, most d3js based charting libraries start to balloon in memory usage if left running for > 1 hour or so.
3. Large executables.
It is still a nice platform to develop on! But if you are stuck with performance problems or something, coding your way out of it is way harder (unless you are willing to get your hands dirty with atom-shell code itself).
EDIT: So we ended up using Qt. in fact, a lot of JS libraries can be used in Qt via QML, for example - https://github.com/jwintz/qchart.js/tree/master.