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.
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.