
Ask HN: Why Node.js and for which type of App? - ph0o
Hi guys,<p>i&#x27;m a computer scientist student and previously read a lot about Node.js. But, to be honest, i have not really a feeling for what i can use a node.js App. Is it a desktop application where i can use html to render the views and the communication between view an backend works i.e. with a RestAPI? Or is it for pure web applications?<p>Thanks a lot for your inputs.<p>edit: started yesterday with the node.js tutorial from Visual Studio Code and was just curious what type of app i can build with it
======
Rezo
Node.js is typically used for servicing web applications, but it has found
some other surprising uses as well. There's a fairly sizable robotics (check
out Johnny-Five) and drone community around it as well. The programming editor
Atom by Github is also a "traditional" desktop app with Node.js at the core.

In my opinion, Node's biggest advantage today is the absolutely massive module
ecosystem that has sprung up around it in record time. It's already the
biggest, as well as the fastest growing according to
[http://www.modulecounts.com/](http://www.modulecounts.com/) You can find a
package for almost everything imaginable, and your typical Node app is made up
of dozens of these modules. So take a look at
[https://www.npmjs.com/](https://www.npmjs.com/), and try searching for
whatever field interests you.

~~~
peeyek
> The programming editor Atom by Github is also a "traditional" desktop app
> with Node.js at the core.

Nope, Atom it's based on electron[0] itself which use io.js and Chromium as a
core.

[0] [https://github.com/atom/electron](https://github.com/atom/electron)

~~~
bdcravens
It started using Node.js; it switched to io.js in February. I think for the
purposes of "What's the use-case for node.js?" node.js and io.js should be
considered the same.

------
ignoramous
NodeJs' non-blocking IO makes it a great choice for near real-time
communication, like streaming editors, messaging, reacting to high freq events
(like metrics). See: [http://socket.io](http://socket.io),
[http://en.m.wikipedia.org/wiki/Surespot](http://en.m.wikipedia.org/wiki/Surespot)
and [https://github.com/etsy/statsd](https://github.com/etsy/statsd)

It is also great when you want to prototype a REST backend, and get it up and
running in no time. The simplicity of javascript along with nodejs' module
ecosystem make it a breeze (Ruby equivalent would be Sinatra).

What nodejs isn't good at is, parallelism. Concurrency is handled for you for
free by the underlying libuv eventing framework. Pseudo-parallelism is
achieved using 'clusters' but communication between node processes is costlier
than in other languages that support parallelism out of the box.

Read
[https://news.ycombinator.com/item?id=4305486](https://news.ycombinator.com/item?id=4305486)
for aphyr's excellent commentary on clojure vs nodejs (you can also find Ryan
Dahl defending nodejs in a few cases there)

------
santiagobasulto
TL;DR: Apps that perform high I/O.

For example, if your app is just getting data from a database and returning it
to the user, 90% of your time will be spent:

* Receiving the user's request (Network, IO)

* Fetching something from the DB (Network, IO)

* Returning the data (Network, IO)

That's a good scenario for an event based system like Node.js.

Try not to use node.js if you're CPU-bound: rendering images or PDF,
processing sound, etc. If you do need to do something like that and you still
want to use node.js you should use a processing queue.

~~~
ph0o
Thanks!

So, you would use node.js just as a service to process data on the server side
and not as a application for the desktop (with a gui)?

~~~
sova
Typically Node.js is for high I/O web applications. Thanks to the wonderful
asynchronicity of javascript (callbacks "let me know when this is ready/done")
it's really wonderful for browser-based programs.

However, there is growing discussion about using Node.js for desktop
applications. Please see [https://nodesource.com/blog/node-desktop-
applications](https://nodesource.com/blog/node-desktop-applications)

~~~
fleitz
Node also works well for desktop apps because it's got the run loop.

Desktop apps are insanely high frequency IO apps, basically, its an Input
Queue reading the mouse / keyboard / touch screen and a run loop, which is
exactly what node is, except node originally envisioned the input queue being
web requests. And most desktop apps are single threaded on the UI.

------
thomasfoster96
Node.js itself is Google's V8 JavaScript engine (the one in Google Chrome)
coupled with a heap of asynchronous non-blocking APIs for IO (http, file
system, etc). In that sense, you'd usually use it as a web server (using the
builtin http module), although you can pretty much use Node.js just as you'd
use any scripting language.

npm[0], Node.js's package manager, is also pretty useful. There's a package to
do most things.

Yes, there's some projects that let you create desktop applications using
Node.js - what they're doing is using an embedded version of Chrome and
pairing it with Node.js. You can then use HTML and CSS to create a user-
interface that you can then manipulate with JavaScript. You end up with a
fairly bloated distributable application, but the JavaScript code runs on Mac,
Windows and Linux.

NodeSchool[1] seems to be the recommended learning resource for Node.js. I've
never really used it, but it looks pretty good.

[0] [https://www.npmjs.com/](https://www.npmjs.com/) [1]
[http://nodeschool.io/](http://nodeschool.io/)

------
vlad
Why learn Node.js:

The three most important reasons to use Node.js: it uses JavaScript which you
might want to learn already, and second, it has a big ecosystem of modules and
frameworks, including by companies like Microsoft and Google, and third, there
is more JavaScript code on GitHub than any other language, if you're looking
into contributing to open source projects or learning from them.

What you can do with Node.js:

JavaScript was already important as the language of the web browsers. As soon
as JavaScript was split off from the web browsers thanks to the Node.js
project, people have been writing web servers as well as command-line tools
with it. It's also used to create interactive cross-platform native mobile
apps and chrome/firefox extensions.

As a bonus, the asynchronous nature of JavaScript and its ubiquity in web
browsers as well as web servers has lead to the creation of a wealth of
official and unofficial standards and implementations of libraries for
creating real-time chat and systems.

If you can do most everything in one language, why not?

Edit: someone already wrote a more technical overview, if you would like one:

[https://news.ycombinator.com/item?id=9830207](https://news.ycombinator.com/item?id=9830207)

~~~
hliyan
Don't forget non-blocking I/O.

~~~
vlad
Thanks, I updated the answer.

I left that out because some commenters mentioned that as the leading feature.
But for somebody who's asking what Node.js is used for, I don't think being
asynchronous is as important a reason as the fact you're writing JavaScript
with great tooling, frameworks, and modules.

As far as coding day-to-day, there are other languages that have better
semantics around writing asynchronous code. And it rarely makes a difference
for first-time developers until they actually build something and try to
scale, and at that point would need to read articles about doing that with
Node.js just like they would with Ruby/Rails, Clojure, Go, etc.

------
crucio
I've been use node.js for the server part of my browser multiplayer game. It's
been a great decision due to the amount of shared code I have between the
client and server.

For example, I share the physics code which is responsible for controlling the
simulation that runs on both the server (authoritative) and clients (for
predictions).

I no longer have to switch languages which also saves a lot of time!

~~~
veb
This sounds pretty interesting, is it open source? Can I check out a demo?

------
allendoerfer
Node.js in itself is a wrapper around V8, the JavaScript engine of Google
Chrome. It is used to execute JavaScript on the server for example to
implement REST APIs. I would consider Node.js if you implement actual webbased
software because you could take advantage of a shared codebase. If you want to
display content on the internet there are more comfortable alternatives you
could use.

What you are probably looking for is Node-Webkit. It is a toolkit to basically
pack a stand alone application with a browser and node.js to create a desktop
application.

I personally would recommend to use QT or GTK or some Windows framework if you
want to learn how to program a desktop application. No need to deal with the
performance problems of web technology and then ship a whole browser with your
app if you have to learn something new anyway. In my opinion you should use
Node-Webkit only if you know why you use it or if you do not know how to use
anything else.

~~~
ph0o
Hi there, thanks for your response.

I programmed some Desktop Apps with Java and C#. And during some hackathons i
used python+flask+nginx to implement a Web-Applications with a RestAPI on the
backend.

I was just curious for which type of application i can use node.js (since i
didn't use javascript on the backend at all). Usually i used PHP, C# or Pyhton
for the backend..

Is MS Windows 10 using node.js for their applications (since its possible to
develop Node.js apps in Visual Studio Code)?

~~~
allendoerfer
I do not think, that node.js is involved in the JavaScript apps for Windows.
In your place I would test node.js the next time you do something like you did
with Flask. If you now C#, I would not recommend to waste time to implement a
node-based Windows GUI app.

~~~
ph0o
i will try it! :) thanks!

------
exizt88
I found Node.js to be quite difficult to work with, mostly due to nature of
Javascript. Module ecosystem is vast, but each one has an API written in a
different style. Combine that with no type-checking and lack of robust IDE
auto-completion (Webstorm is quite disappointing at the moment) - and you get
a frustrating experience. Oh, and also add asynchronicity into the mix.

Making restful APIs is quite fun with it, though.

~~~
ph0o
As mentioned, i tried Visual Studio Code on OSX. works like a charm.. i would
give it a try!

------
falcolas
Node is a tool for running Javascript on the server. Your desire to use it
will stem entirely upon your desire to write javascript to perform server side
tasks.

There are many languages and environments for running code on the server, so I
personally have problems finding a niche where Javascript is the obviously
better choice for these tasks. In my experience with it so far, it's "fast
enough" for IO bound tasks (routing, serving CRUD applications), but if you'd
like to perform any form of computation on inputs, you'd probably be better
served by a different language ecosystem.

~~~
j13z
> Node is a tool for running Javascript on the server. Your desire to use it
> will stem entirely upon your desire to write javascript to perform server
> side tasks.

Now that's often what people think of Node.js, but that's not really why
Node.js is interesting. It's _not_ just _" JavaScript on the browser"_.

Instead, you should think of Node.js more like a JavaScript binding to
`libuv`, which is the C library that provides the event-driven I/O core (event
loop / queue). (An example for a `libuv` binding in another language, Lua
would be `luv` [1].)

Reasons why JavaScript was picked for Node.js: 1) It already dealt with events
due to its usage in browsers and 2) a fast existing JIT runtime, V8.

To answer the original question: You might want to use Node.js _if your
problem is a good fit for the Reactor pattern_ [2]. For example, scalable
network services that "mediate" between a lot of (async) I/O. Not number
crunching. Nginx uses the same core concept (Reactor).

[1]: [https://github.com/luvit/luv](https://github.com/luvit/luv)

[2]:
[https://en.wikipedia.org/wiki/Reactor_pattern](https://en.wikipedia.org/wiki/Reactor_pattern)

~~~
falcolas
Node is far from the first or only implementation of the reactor pattern in
programming languages. There are many other, frequently more mature
implementations which exist in most languages.

> Reasons why JavaScript was picked for Node.js: 1) It already dealt with
> events due to its usage in browsers and 2) a fast existing JIT runtime, V8.

Well, no, the original creator of Node just wanted non-blocking IO (which the
frameworks he was using did not support), and (I'm editorializing a bit here)
in the grand engineering tradition of re-inventing the wheel, he decided to
use Javascript with v8 to create a whole new platform, instead of using an
existing platform.

------
mainguy
Generally Node has been targeted at server side projects to date (i.e.
building web APIs/etc). Stand it up register a listener on a port, and start
servicing requests.

~~~
JoeAltmaier
Curious: isn't Node single-threaded? How can it scale on a server i.e. on a
beefy server with 64 hyperthreads, now can Node capitalize on the available
horsepower?

~~~
frantzmiccoli
Previously you could launched multiple instance of your program. Today you can
use [https://nodejs.org/api/cluster.html](https://nodejs.org/api/cluster.html)
and leverage all those sweet cores on your server. You can multiprocess but
not multithread.

------
arsalanb
Reading all the comments here makes me wonder — Can Python (say, Flask) not be
used for real-time communication (SocketIO, etc..) ? What is the difference
between that and node.js ?

I am still figuring out a lot of things about Python, and this is something I
found very intriguing. What would the differences between an IM app written in
Python using Flask and it's nodeJS clone be, to a user?

~~~
rithi
It could be [1]. IMO, it sounds more like something slapped on top of Flask.
You will find similar packages for Django, Pyramid and so on. Tornado feels
natural in this sense as it aims to be asynchronous right off the bat.

See also, aiohttp [2] which seems very promising (Python 3.3+). As an aside,
I've never seriously considered Python 3 till now after taking a look at
aiohttp.

[1] [https://flask-socketio.readthedocs.org/en/latest/](https://flask-
socketio.readthedocs.org/en/latest/) [2]
[http://aiohttp.readthedocs.org/en/stable/web.html](http://aiohttp.readthedocs.org/en/stable/web.html)

------
vegancap
You can use it for a lot of different application types. It's typically used
for web as most web developers already know some Javascript. It's also very
lightweight, portable and has a lot of great features that other web languages
either don't or don't do as nicely as Node. Asynchronicity for example.

People have also used it for desktop applications, with a few desktop UI
library wrappers. Githubs text editor 'Atom' for example.

Node also has a great set of API's for interacting with the system and network
utilities, so there's a lot of great tools for networking and automation.

Finally, because Javascript is so lightweight, we're seeing it play a key role
in the 'Internet of Things'. Some micro-controllers are even written in JS
(see Tessel).

So don't feel as though it's for one thing or another, just have fun with it
and explore the language and its potential!

~~~
regecks
I am not sure it can be called 'very lightweight'. The runtime itself has a
large disk footprint, my node_modules is often 100s of MB, and the memory
usage is quite heavy too (idle Ghost.org blog takes around ~100MB RSS).

Some of the APIs are not very portable either, such as fs.watch. Many npm
libraries implicitly depend on Linux or OS X.

It's convenient though, sure.

------
mattkrea
Having used Node.js recently for a high volume service my feeling is it is
best for lots of network communication.. but _not_ long running or CPU/disk
intensive operations. So, we're slowly transitioning to a Go backend with a
slim Node.js layer to form the very friendly API while we use some RPC between
the Node and Go. In this, Node.js is amazing and--I would guess--hard to beat.

EDIT: Clarify with "CPU/disk intensive operations"

~~~
index117
I'm curious about why you say nodejs is not good for long running processes? I
currently have a nodejs process running 24/7 pulling a MP3 broadcast stream
and haven't had any real difficulties with it, outside anything I would expect
with any other language. Granted, the process itself isn't doing anything
extreme, just watching certain data in the stream. I'm just curious if there
is something serious I haven't encountered yet.

------
scarecrowbob
One popular use that I'm not seeing a lot of other folks talk about here is
using node to create build tools for web development.

Gulp and Grunt have been very popular as a way of, for instance, watching
files and then minifying CSS an JS assets automatically while creating web
pages in systems like WordPress that don't have built-in asset pipelines.

------
popee
Node on desktop is still in early stage, there are some projects but node
shines on server side, not only for web/http (mega simple), but also any other
application protocols or lower. It's not hard to make socket and do whatever
you want + async = win.

On the other hand it's javascript, so :-)

------
antoniuschan99
It can be used as a traditional web app or even for microservices. I think the
power comes from its asynchronous nature, the ability to write JavaScript
backend, and the community and tooling. Anything else?

------
SimeVidas
Node.js is a good option if you’re a front-end web developer who wants to add
server-side functionality to a relatively small site.

------
Kaali
Node.js is in an interesting position. There is a lot of libraries and new
ones are coming out at breakneck speeds. It's also a way for frontend
developers to transition to backend tasks. And it gets a lot of mindshare at
the moment, with MongoDB and microservices.

But in my opinion a lot of Node.js ecosystem is a lot of mismarketed features.
Many developers doing backend services with Node.js actually think that it's
the fastest thing available, even though multiple benchmarks, e.g.
techempower, shows that it really isn't. And even more people seem to think
that it is a way to do simple parallellism, so they won't have to understand
threads and locking, which are really complicated stuff. But as many have said
here, Node.js does not support threads, or parallelism without running
multiple different processes. Which can be fine if you don't have any shared
state between your processes. And with no parallelism in process, it is quite
easy to actually block the event loop by running anything that is CPU and not
IO bound. This can be a loop that is too long, too much math, or even parsing
a JSON string without using streams. All of these can block the event loop,
which means that no requests are going through that process while one request
is parsin a JSON.

And even though there is a lot of libraries and frameworks for it. The quality
is often really, really bad. As in invalid MD5 algorithm bad, etc. But there
are also some gems such as Bluebird for promises, which makes the callback
hell more easier to handle.

You will also face immature debug support, profiling and static analysis. You
barely get any refactoring help from your tools, even though IntelliJ IDEA
does quite a good job with basic refactoring and debugging. And you will have
to spend time with handling odd bugs with no logs showing up on crash, or
stuck processes when something has gone really wrong in the code, with no way
of knowing (if you don't have DTrace) where the code is stuck.

But there are stuff Node.js seems to excel at. It is really quick for creating
a simple REST service, feedback loop is really quick as the services restart
almost immediately (at least when you don't use all the latest ES6
transpilers). And if you want to create isomorphic applications, where the
server can render a Javascript site on behalf of the browser for the first
request, or even successive requests for mobile use, there is no better
platform than Node.js. And if you know that you will not do anything that is
CPU bound, just IO bound stuff, you can still use any library available. Where
for example in Java or Python, you would have to find specific libraries that
support your chosen async IO framework.

I would use Node.js between a backend server done in a more robust ecosystem
such as JVM, and the browser. Where Node.js gets the data from the backend and
does it's magic with isomorphic React for the client.

------
zgardner
Don't use Node.

