Atom Shell: Cross-platform desktop application shell(github.com)
github.com
Atom Shell: Cross-platform desktop application shell
https://github.com/atom/atom-shell
20 comments
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)
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?
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.
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.
[deleted]
[deleted]
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.
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.
What in particular was the d3js memory issue from? Any specifics you can share?
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) .
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) .
Can you share which JS charting library you ended up using?
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.
Could be related to this? https://code.google.com/p/chromium/issues/detail?id=378527 I got burnt by this once.
[deleted]
How portable is this, exactly?
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?
[1] https://github.com/rogerwang/node-webkit/wiki/The-solution-o...
[2] https://github.com/breach/thrust
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?
[1] https://github.com/rogerwang/node-webkit/wiki/The-solution-o...
[2] https://github.com/breach/thrust
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.
It's as portable as its chrome dependency.
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:
https://github.com/atom/atom-shell-starter
https://github.com/paulcbetts/grunt-build-atom-shell
https://github.com/atom/atom-shell-starter
https://github.com/paulcbetts/grunt-build-atom-shell
Previous discussion of atom-shell and other similar software here: https://news.ycombinator.com/item?id=8729791
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.
Summed up my thoughts here: http://mattdesl.svbtle.com/motion-graphics
[1] - https://github.com/breach/thrust
Summed up my thoughts here: http://mattdesl.svbtle.com/motion-graphics
[1] - https://github.com/breach/thrust
It just feels wrong. Better go with Qt/QML or JavaFX/Nashorn.
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.
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.
Qt and JavaFX are extensible and can plug into the native APIs.
HTML is a document format trying to be a platform, without any mechanism to plug into native APIs.
I have done web development contracts since the cgi days and would never use it for native applications.
HTML is a document format trying to be a platform, without any mechanism to plug into native APIs.
I have done web development contracts since the cgi days and would never use it for native applications.
Is JavaFX suitable for desktop apps? I had the impression it was aimed at Flash/Silverlight type work.
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.
https://oracleus.activeevents.com/2014/connect/sessionDetail...
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.
https://oracleus.activeevents.com/2014/connect/sessionDetail...
I think an equivalent product that runs on Nashorn instead of Node would solve 90% of their problems.
Looks like
https://github.com/appjs/appjs
and
https://github.com/sihorton/appjs-deskshell/
(If you want to look at alternatives)
(If you want to look at alternatives)
Make sure you also check out the starter app!
https://github.com/atom/atom-shell-starter
https://github.com/atom/atom-shell-starter
We've been busy developing a product with atom-shell that will be released next year. Works great, no complaints so far anyway!
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.
[1] https://news.ycombinator.com/item?id=8729791
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.
[1] https://news.ycombinator.com/item?id=8729791
Would you mind sharing the sweet spots that have caused atom-shell to be a good fit for your application?
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.
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.
So are you still shipping Python/Django as an executable with atom-shell? Or is this purely client-side javascript?
Just atom-shell, it ended up being easier all around and no compelling reason to keep Python in the mix for this particular app.
It is possible to include python with this? That is interesting
Mapbox built their latest map design studio on Atom Shell: https://www.mapbox.com/mapbox-studio/
How does this compare to Node-webkit?
@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).
In a nutshell, not a lot of difference, but you interact with node slightly differently, newer version of v8.
https://github.com/atom/atom-shell/blob/master/docs/developm...
https://github.com/atom/atom-shell/blob/master/docs/developm...
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)
It's for unrelated 3D stuff :) node-webkit is just there as our desktop shell.
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.
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.
Interesting!
FYI atom-shell seems to work better with node v0.11 than node-webkit if you're trying to build little admin/maintenance utilities that need sudo.
node-webkit gets in the way of the sudo working.
FYI atom-shell seems to work better with node v0.11 than node-webkit if you're trying to build little admin/maintenance utilities that need sudo.
node-webkit gets in the way of the sudo working.
The idea of running a Javascript interpreter as root is more than somewhat worrying...
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.
Why does node-webkit interfere with sudo?
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?
Phonegap,Apache Cordova? I mean it's no different from a webview inside a native app.
> Is the common approach to create a native app with embedded browser or is there some other way?
Obviously to use clientside webtechs you need a browser of some kind.
Ironically Windows supported this html apps through hta apps since 1999,and still does.
Simply rename an .html file .hta,and you have an app...
> Is the common approach to create a native app with embedded browser or is there some other way?
Obviously to use clientside webtechs you need a browser of some kind.
Ironically Windows supported this html apps through hta apps since 1999,and still does.
Simply rename an .html file .hta,and you have an app...
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.
Check out Apache Cordova http://cordova.apache.org/
Take a look at Phonegap or Titanium.
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.
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?
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?
Cool, but why reinvent the wheel rather than use Brackets Shell, Node Webkit, CEF or QtWebKit?
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.
Indeed.
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).
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.