Atom Shell: Cross-platform desktop application shell
github.com
github.com
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.
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) .
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 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)
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?
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.
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...
Summed up my thoughts here: http://mattdesl.svbtle.com/motion-graphics
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.
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.
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...
(If you want to look at alternatives)
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.
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.
https://github.com/atom/atom-shell/blob/master/docs/developm...
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.
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.
PhoneGap (Cordova) is a much better solution, I think.
> 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...
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, 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).