
The State of Desktop Applications in Node.js - callum85
https://nodesource.com/blog/node-desktop-applications
======
doublerebel
There are a number of ways to make desktop apps with JS. TideKit/TideSDK uses
V8 IIRC. On Linux, Gnome has the GJS API. Tint and Quaxe are two more
promising newcomers. All of these use a JS engine to create native platform UI
controls. So for anyone who thinks JS is limited to webviews, you missed the
boat. Thousands and thousands of native apps are already created and shipped
on a JS core.

The async nature of UI and I/O makes JS a perfect fit, so I expect this trend
to only continue and the tools to improve. It's so much faster and more
efficient to create using JS than "native" languages, it's a no-brainer for
any business who has a dev with this experience.

------
mid-kid
The web wasn't made to be used as a desktop app replacement, and it will never
be. Quit trying to make it that way, and start using a widget toolkit like you
should. Hell, if you love html/js so much, there's a big chance you won't
dislike QML. The web is for sharing content, not for games, text editors, and
all that stuff. I see google trying to blur the lines between that, but why is
it necessary? Just because people are too lazy to adapt themselves to the
platform they're writing for, and allow them to create slow, shitty "web
apps"?

~~~
Iftheshoefits
The hype around HTML/JS as a substitute or replacement for native development
has little to do with developer laziness and more to do with commoditizing
software development labor.

Native is _hard_ relative to (the nearly thoughtless) slapping together of JS
and CSS frameworks to "build" an "app." It requires paying people more and
taking more time to develop.

~~~
smacktoward
You make it sound like there's no benefit to programmers to consolidating
around a single platform. But there are several:

\- It removes the risk of spending time and money learning what turns out to
be the "wrong" (i.e. an unsuccessful) platform

\- It avoids splitting the effort of tooling vendors, library authors, etc.
across many different platforms, reducing the amount of redundant effort spent
reimplementing things in platform Y that already exist in platform X and
freeing them up to work on unique ideas instead

\- It brings the largest possible number of people underneath one umbrella,
which makes that community more economically attractive and therefore
increases the number and quality of tools and services they have access to

Not that it's all sunshine and roses, of course, but it's not without
advantages.

~~~
Iftheshoefits
All of your points apply to webdev. They just take a different form, and
frequently are masked by mistaking the ease with which trivial apps can be
developed by mixing a few canned frameworks together for reduced complexity.

------
snide
We ended up building Mac and Windows apps for
[http://www.webhook.com](http://www.webhook.com) built on a Node / Chromium
shells. Essentially we're a Wordpress competitor, but Node powered, and wanted
to provide a simple one-click install for people that didn't know how to work
their command line or how to install Node properly. This solution ended up
working great. It basically allowed us to build a non-destructive sandbox dev
environment for them that had a UI experience similar to the CMS itself.
Better yet, the app points to hosted JS and CSS files so really there's never
a need to "update" the app. When we have feature or bug changes, we just push
out new files and everything just works.

This kind of stuff isn't for all apps, but for our use case it was almost too
good to be true. We built everything out in about two to three weeks. I don't
know how long it would have taken for us to do something similar with true
Desktop tooling.

Here's a video of the end result in case anyone in interested...

[https://vimeo.com/108922566](https://vimeo.com/108922566)

~~~
callum85
This is great. Did you use node-webkit?

------
one-more-minute
The post mentions Light Table as a node-webkit user, so I'll mention that
we're actually in the process of moving to atom-shell [1]. After having some
issues with NW we found that atom-shell gave us a more suitable architecture
and some nice desktop integration features for only a few days work.

The multi-process model is definitely more complex and probably not for
everyone, but it's working really well for us so far.

[1]
[https://github.com/LightTable/LightTable/pull/1756](https://github.com/LightTable/LightTable/pull/1756)

------
pjmlp
2014, still catching up with the desktop.

If one really really wants to use JavaScript, at least make use of QML or
Nashorn/JavaFX.

~~~
woah
Just for the delicious pain of Java development?

~~~
pjmlp
Java development is pure pleasure when compared with web development.

~~~
mateuszf
Usually said by Java developer not understanding JavaScript.

~~~
penprog
You see, I barely need to "understand" Java to use it and get decent and
performant code but I need to be a javascript expert to be able to do anything
not horrible.

Please stop trying to act like the state of web and javascript is good because
it's shit. Web development is basically a bunch of people suffering from
stockholm syndrome.

~~~
jekrb
Really? I feel js gives way more freedom and is much more forgiving to writing
in your own particular style. I've had the exact opposite experience with
Java. I write JavaScript all the time for work and hobby and it's always
rewarding.

Also, I'm in college for computer science and the school will only teach Java
courses. It's dreadful and maddening. Classical inheritance is complete shit.
Compiler error messages suck. The language itself is just too bloated for me
to want use. Whatever I can write in Java I can do in a fraction of the time
with js with much more modular and maintainable code.

I think java interfaces are a clear sign of stockholm syndrome, as every time
I asked the professor why they are necessary I never got an answer other than
"to hide part of your code from the outside world", "to use as a blueprint for
your classes", or my personal favorite "Because in Java you write interfaces."
I tried shifting my question to "Why _don 't_ I have to write an interface in
js?" That one never got answered. Maybe someone here who is crafty with Java
could explain and justify for me the reason for writing what feels like more
code for no obvious benefit.

Also, sorry if Java is your thing and I sound like I'm bashing it. It's just
been really frustrating for me compared to literally every other language I've
used, especially since my degree depends solely on the language.

~~~
penprog
java interfaces are one of the main reasons people like java (and as other
people have said, it's reimplementation in other more modern languages shows
how popular and useful they are). They promote code reuse and allow protected
variation. Your professors bad explanations aren't a reason to dislike
interfaces.

Also how have you not, in a java class, written code that uses polymorphism?
That would be the easiest way to understand how useful interfaces are.

~~~
jekrb
But I reuse code all the time with js, following DOT and DRY principles, just
fine without an interface. Especially with tools like browserify, where I can
basically manage my code as partials independent from each other. Also, I have
had to write java code that uses polymorphism. I still find polymorphism
_easier_ in javascript. That being said, I think classes and polymorphism is
kinda of all just nonsense.

My preferred method of "inheritance" really is just extending an object. Which
js is great at. And there's multiple ways to do this, with multiple kinds of
prototypes. For something quick an easy I can make a prototype and just pass
that through object.create() and now I have a new object that has all the
properties of what I would loosely consider to be a "parent". It's more
cloning than it is inheritance, and I can completely override properties
however I want, while the original properties stay unchanged.

IMO polymorphism and interfaces in Java seem more like hurdles and added
complexity compared to object extension and cloning in JavaScript. _.extend
paired with browserify also makes for extremely modular code that I haven't
seen any Java code compare too.

~~~
woah
I agree. An interface in JS is a unit test.

I think that a lot of "classical" programmers simply don't understand how
important modules are to JS development.

This is why you get these posts about "how can you manage 1,000,000 LOC in
JS!!?", when they don't understand that you never have 1,000,000 in JS, you
have a bunch of small, unit tested modules.

~~~
pjmlp
Because in the real boys club (aka enterprise) no one writes unit tests unless
they are imposed on them.

------
rrdharan
This article doesn't accurately convey the state of Chrome Applications.
There's actually a much richer way to build apps that have a more native look
and feel, including their own branded top-level window with fewer of the
limitations the author cites.

[https://developer.chrome.com/apps/about_apps](https://developer.chrome.com/apps/about_apps)

~~~
evv
The article's title is "The State of Desktop Applications in Node.js", and
chrome applications do not let you run node.js on the local machine. If you
can't run your own userland code on the machine and talk to hardware, then you
can hardly call it a desktop app.

Google wants to keep you locked in their sandbox.

~~~
juliangregorian
I don't know, they seem to tout interfacing with network and hardware pretty
heavily.

------
Rauchg
Check out thrust as well:
[https://github.com/breach/thrust](https://github.com/breach/thrust)

multi-platform and easily bindable to any language

~~~
rdtsc
That looks promising. It is used for Breach but are there any other users?

------
callum85
Last time I tried building a 'blank' node-webkit app for OS X (using
[https://github.com/Dica-Developer/generator-node-
webkit](https://github.com/Dica-Developer/generator-node-webkit)), the
resulting .app came to ~100MB.

Does anyone know the base size for an atom-shell app?

~~~
FooBarWidget
Seriously, does anybody nowadays care about a 100 MB desktop app? I developed
my first app in 1997 with Delphi and it was only 200 KB, so from that
perspective I always cringe when I see that an app I've developed is multiple
MB. But in all seriousness, do users actually care? Every time I download an
OS X app, it's _at least_ 50 MB, but I find that even I don't care anymore
because downloading 50 MB nowadays only takes 10 seconds, and my machine has
more than enough RAM to load all the bundled libraries. We are in an age where
people deploy VM images and Docker containers that are many hundred megabytes,
and it seems people are happy that way.

The alternative is _not_ making apps self-contained, but instead to make them
rely on shared libraries. This is much more efficient, but apart from a few
neckbeards who cry "bloat" it seems that most people care more about avoiding
dependency hell and ease of use, even if that means large packages due to
library duplication.

~~~
callum85
I would agree with you if you were talking about 20MB. I think that would be
my threshold for not caring about how big an app is, i.e. even if it's
something really basic like a countdown timer app I would be OK with it being
up to 20MB, because as you say, connections are fast and space is cheap. But
100MB? I don't know.

~~~
jiggy2011
You could install more than 1000 apps on a moderate SSD at 100MB each. How
many apps does the average person have installed?

~~~
callum85
It's nothing to do with how much space it will take up. The problem is that,
as a user, I would be very suspicious of a 100MB countdown timer app. I would
think that either it's got some kind of adware in it, or just that it's
incompetently designed.

~~~
Carrok
>as a user, I would be very suspicious of a 100MB countdown timer app

You mean as a developer. Your average 'user' does not know or care how big an
app 'should' be.

~~~
callum85
I disagree. App file sizes are displayed in app stores because many users care
about them.

A significant number of users would notice an app being dramatically larger
than it ought to be. I've seen a _lot_ of reviews like "why the hell this app
over 100mb??!!1". There is a huge spectrum of technical competence between "I
don't have any sense of what a megabyte is" and "Developer".

------
zzzcpan
Related question: what are the other ways to build a desktop application on
Linux that works on Linux, Windows and OSX on slow machines, like intel atom,
and doesn't require anything from the user?

~~~
pavlov
Qt is great for this. It's used by lots of desktop applications, from small
open source tools to large commercial content creation apps like Maya.

[http://qt-project.org/](http://qt-project.org/)

It does have a substantial learning curve. The traditional desktop stuff is
all C++. The new mobile stuff is easier to develop, with a nice declarative UI
system and JavaScript, but it's not applicable if you want native-feeling
desktop widgets.

------
mnkypete
There is also a quick way to start a new application with Atom:
[https://github.com/atom/atom-shell-starter](https://github.com/atom/atom-
shell-starter)

------
echoless
I've played around with both node-webkit and atom-shell, and I prefer atom-
shell over node-webkit, due to some minor inconveniences with node-webkit.

* When an error occurs in node-webkit, it loads an error page instead of simply logging it to the console like normal web pages. Even after fixing the error and hitting reload or navigating back, the page doesn't go away. You need to manually enter the url(copy/paste doesn't work).

* I don't know if this is something that was my fault or the app's, but when I made a call to a sqlite3 database using the node-pure-sqlite3 gem, it would take around 3 seconds to execute. With atom-shell it would take less than a second.

* The developer console is a separate window from the application in node-webkit. I prefer having a single window hold both the app and dev console during development(which atom shell-allows).

~~~
ep103
completely clueless programmer checking in. How is atom's performance? The one
app I tried that used it was always slow and cludgy...

~~~
echoless
For DOM performance, they are pretty much identical. Both use Chrome(each uses
a different version though, usually atom-shell uses more recent versions).

For performance of node.js calls, I haven't run any benchmarks, so I cannot
help you there. However subjectively, both felt about the same to me(except in
the node-sqlite-purejs case).

------
teleclimber
If you are targeting Mac only and don't depend on Node an alternative would be
MacGap:

[http://macgapproject.github.io/](http://macgapproject.github.io/)

The packaged app is tiny compared to a chromium+Node shell app.

------
benjismith
I've been using node-webkit for the past 18 months or so, and it's been
absolutely delightful.

One thing this article gets slightly wrong is this sentence: "This means that
Node.js modules must exclusively use functions and classes provided by Node.js
or modules from npm, as the DOM is off limits."

This might be technically true, but there's an easy enough workaround:

1) Use a script tag to include jQuery in the index.html page

2) Pass the jQuery object ($) as a dependency into a node module.

3) Profit.

I regularly modify the DOM from node context using this pattern.

------
tyrion
Is there some way to have a "Firefox shell" instead of a Chrome/Chromium
shell?

~~~
jamii
[https://developer.mozilla.org/en-
US/docs/Mozilla/Projects/XU...](https://developer.mozilla.org/en-
US/docs/Mozilla/Projects/XULRunner)

I'm not sure if it's still actively developed though.

------
abimaelmartell
~100 MB for a hello world...

------
edem
Try out the new StarUML beta. I was surprised to see that it uses node.

