
Is Node.js declining already? - bemmu
http://www.quora.com/Is-Node-js-declining-already/answer/David-MacDonald-40?srid=hzBO&share=1
======
Lazare
Node.js (ie server-side Javascript) will live and die with client-side
Javascript.

Right now we seem to be in a client-side JS boom. New frameworks are being
written, adoption is up, React and friends are getting tons of buzz, build
tools like webpack or transpilers like babel are making developer lives
easier, NPM is seeing tons of traffic (much of it supporting client-side
development, either directly or indirectly), we're starting to routinely
prerender SPAs on the server, etc., And it all runs on node.js. (Good luck
writing a serious React app without some node.js processes running at some
point.)

So I'd say we've yet to see peak node.js; it's still increasing in usage, and
will likely do so for some time.

Now, some people made some wild claims about node.js being the BEST EVER
SERVER FRAMEWORK, with super amazing webscale performance. That was nonsense
and lies. Node.js was never going going to sweep the world and be the One True
Framework for writing servers in, and that's becoming increasingly apparent.
It's not a terrible choice, but then, neither is Rails. Or C#. Or Python. Or
hell, PHP. And people are going to keep writing servers in all of those
languages and frameworks.

If you listen to the hype, we went from Node.js being the BEST FOR PERFORMANCE
to, I dunno, golang or something. And going from being the BEST to not even
being talked about probably feels like a real decline. In the real world,
Node.js went from a new and little used niche technology, to a slightly less
new and very broadly used niche technology. That's not a decline at all.

~~~
bradleyland
Great comment, and worth noting that many technologies go through this cycle.
Those old enough to remember might note that once upon a time, Java was going
to "change the world". Anyone who got their start in technology after 2000
really cannot appreciate how head over heels the tech world was over Java.
Fast forward to today and the concept seems inconceivable. Java, a game
changer? Oh yeah, majorly.

If you stick around long enough, you see this play out over and over again.
You learn not to get too worried over a lull in attention paid to your tools
of choice.

------
bryanlarsen
It's not the cool new thing anymore, but it's definitely not going to go away.
Its killer feature is that the same code can run on the client and the server.
Not a big deal for most apps, but very important for some.

Also, ES6 & ES7 make callback-heavy Javascript so much more pleasant to
program in. That addresses Node's main pain point.

~~~
falcolas
> Its killer feature is that the same code can run on the client and the
> server.

In the deploys I've worked with, this is never actually done. How many Node.js
developers actually ship the exact same code to both locations?

~~~
morgante
We do. It's great—we can have a fast first-page load time while bootstrapping
additional client-side functionality and all subsequent pageloads are
ridiculously fast.

This way, we are making our web server "just another client."

~~~
k__
Any directions with this?

~~~
morgante
We use the Rendr library, which is built on Backbone:
[https://github.com/rendrjs/rendr](https://github.com/rendrjs/rendr)

------
joeyspn
In short, NO... Here's the proof:

[https://www.google.com/trends/explore#q=nodejs](https://www.google.com/trends/explore#q=nodejs)

~~~
arbuge
PHP, on the other hand, seems to have been in a decline which has finally
levelled out.

[https://www.google.com/trends/explore#q=nodejs%2C%20php&cmpt...](https://www.google.com/trends/explore#q=nodejs%2C%20php&cmpt=q&tz=)

Note that this is on the same scale as node, which is no longer visible
hugging the x-axis...

~~~
joeyspn
Well, not really a fair comparison... Javascript is also going down...

[https://www.google.com/trends/explore#q=php%2C%20javascript&...](https://www.google.com/trends/explore#q=php%2C%20javascript&cmpt=q&tz=)

But like node, laravel is also _on fire_...

[https://www.google.com/trends/explore#q=nodejs%2C%20laravel](https://www.google.com/trends/explore#q=nodejs%2C%20laravel)

------
leeleelee
I like to use python, flask, gunicorn, and nginx for back end apis.

Now that I've been doing so much front end javascript programming, I'm looking
into Node just because I'm way less efficient at writing python and more
efficient at writing javascript nowadays.

At least that's my personal decision criteria.

------
aikah
Nodejs is an excellent tool for front-end integration testing and asset
pipelines that depend on js(LESS,coffeescript,babel and co). On the other, on
the server, you can read many stories of startup that started with NodeJs and
ended up with Go.

NodeJs doesn't have any concurrency capability. Sure you can fork, but then
you need a message queue for interprocess communication. And frankly while
javascript's getting better, some people are a bit sick of dynamically typed
languages and prefer static typed languages.

How many people can go read a large JS source file and make sense of what is
happening quickly? not a lot, in comparison, Go is easy to read,there is no
"ninja trick" or metaprogramming stunts that makes code unreadable.

~~~
LocalPCGuy
> How many people can go read a large JS source file and make sense of what is
> happening quickly? not a lot, in comparison, Go is easy to read,there is no
> "ninja trick" or metaprogramming stunts that makes code unreadable.

If written correctly, neither of those questions should be an issue.

1) JS devs shouldn't have "large" JavaScript source files, like most good
programs, they should be broken into small, concise pieces.

2) JS devs shouldn't use "ninja tricks" or other BS, they should write for the
next person that reads the code, again, like any language.

Yes, a lot of people still write bad JavaScript, but that is on them, not the
language. It is pretty simple to write bery readable JavaScript if you so
choose.

~~~
WorldWideWayne
The language and the environment are certainly at fault to a high degree due
to the lack of standards.

1) Breaking JS up into small files actually makes it less readable because
then you have to guess at the context that the JS is running in. Without
static typing, it's impossible to reason about certain blocks of code without
going to find blocks of code that exist in other files and so on...

2) JS devs have to use ninja tricks because without a strong standard library
they have to keep reinventing the wheels that should have been included.

There is _no standard_ for how to write readable Javascript and there is too
much flexibility. Isaacs, of Node.js fame, writes horribly unreadable code IMO
due to the fact that he does not use semi-colons and he tends to put
punctuation on the left. However, he swears by the fact that it's more
readable...to him.

------
ourmandave
My favorite line is the last line.

 _A week is a long time in JavaScript._

------
mixmastamyk
Could someone unpack and explain this answer snippet a bit?

    
    
        I personally do not believe that Node is a viable platform for building
        multi-user server logic. Node is great for asynchronicity, but that
        shouldn't be confused with concurrency* which is really what you want in
        those scenarios (I can write a list of things Node doesn't do well for
        building safe backend systems, but that's one example).
    
        The Node platform is very good for single-user applications (games, web
        apps, command line tools, "browserified" apps, Node+browser containers),
        but I think a lot of people will come to regret using it for bigger
        back-ends.
    

A company I work with occasionally is building a backend and client system in
node+mongo, and I wonder if it is a good idea. The backend will be an app
catalog of sorts, while the client will run these apps, which will animate
stuff in a browser.

I've read lots of warnings about mongo, and now this. I'm torn about these
choices, I've tried and liked them, but am a bit out of my element as
primarily a python/c developer.

~~~
ddebernardy
These articles on Node unpack the point to some extent:

\-
[http://stackoverflow.com/q/22644328/417194](http://stackoverflow.com/q/22644328/417194)

\- [http://www.future-processing.pl/blog/on-problems-with-
thread...](http://www.future-processing.pl/blog/on-problems-with-threads-in-
node-js/)

\-
[http://web.archive.org/web/20120911094357/http://dev.hasenj....](http://web.archive.org/web/20120911094357/http://dev.hasenj.org/post/31042963934/nodejs-
hate)

\-
[https://news.ycombinator.com/item?id=4495101](https://news.ycombinator.com/item?id=4495101)

------
jeswin
Node.JS's future is intricately tied to JavaScript the language itself and IMO
we are still in the early days of Node.JS. The success of a language isn't
about excelling individually at expressiveness, type-safety, widespread
distribution, performance, tooling or ease-of-use; but about finding that
sweet spot. JS is that compromise.

I'll just list the strengths of Node and JS in general, in no particular
order:

\- JavaScript was called "Java"Script for marketing. But the funny thing is
that it has become the true "Write Once, Run Anywhere" alternative to Java.
Including phones without installing additional software. And projects like
React Native will take JS outside the browser into native apps.

\- JS has a monopoly in the browser. To build any web-app, you/team need to
know JavaScript anyway. Having to use only one language is an advantage for
many companies. For larger IT companies, this also dramatically cuts down
their training expenses.

\- Very active community, perhaps the most active of any language ecosystem.
What's remarkable is that the key people in standards and implementation
bodies aren't operating on mailing lists alone, but work closely with product
teams in their own companies and interact with the rest of the (very large)
community through forums and social media. This has resulted in excellent
prioritization of features and an active feedback loop. Also, peaking at a
time when collaborating coding (GitHub) matured helped. (1)

\- NPM and Packages. There's a package for everything. We often hear people
complaining about hundreds of npm packages downloaded per install. That's also
the strength of NPM. Packages range from monolithic to tiny 20-line functions.
The fine grained granularity of packages makes it a simple, anytime-revocable
decision.

\- JS is a very expressive language like most dynamic languages are, but the
years of performance wars by browser vendors have given it a significant lead.

\- Tooling is excellent. There even plenty of academic-style research going
on, like FaceBook's Flow.

\- You could compile other languages down to JS. You can compile Doom to JS
and play it inside a browser. (However, JS will retain that native-support
advantage.)

\- ECMAScript 2015 fixes the big issues with JS. We can treat it like an
entirely new language, and in time we can forget the good parts/bad parts
discussion.

\- JS isn't trying to shoehorn performance into its expressive style. If
you're using JS for performance critical work, you will be forced to use data-
structures specifically designed for performance. If you need to operate at
native-code levels of performance, you'd have to write code differently from
the usual expressive and dynamic style. That's a fine compromise, it doesn't
have to tread over the neither-here-nor-there territory. Also, pragmatic
parallelism is coming ([https://blog.mozilla.org/javascript/2015/02/26/the-
path-to-p...](https://blog.mozilla.org/javascript/2015/02/26/the-path-to-
parallel-javascript/)).

And perhaps the most important one: Wikipedia took off because it made
collaboratively editing documents easy and doable with just the browser. If it
required downloading and installing additional tools, it may have never
achieved the same success. Now, the future will have more people who know
programming than ever before. Like writing articles, they might build apps
together. The true USP of JS isn't that it runs everywhere, but that browser
vendors have shipped billions of debuggers.

(1) Not saying other languages don't have vibrant, active communities.

------
ziles88
You see waves of technology adoption based a lot on language barriers. We're
seeing this with Larval right now in India/SE-Asia, we've seen it with VB6,
then .NET into Russia/South-America, and we're just starting to see node.js
picking up in China.

People forget, documentation needs to be written, interpreted, then passed
down through different channels, like programming communities, schools, person
2 person. This can take 4 years+. As soon as English speakers have mastered
it, China is just starting to for example.

Node is here to stay, and it's already at a point with decent enterprise
adoption, meaning it's going to take a lot of money and time to reverse the
trend.

------
swang
Remember when rails was a fad and no one was going to use it after the hype
died down and nodejs became king? Oh those "hipsters"!!!

------
JDDunn9
Worth noting this was not the most voted answer. [http://www.quora.com/Is-
Node-js-declining-already](http://www.quora.com/Is-Node-js-declining-already)

------
spoiledtechie
Its nice to see the rise and inevitable fall of languages. It just shows how
its good to use the fundamental pr stable languages over the hip ones. The
hips ones cause you to pick up, put down, rinse and repeat. The fundamentals
only build on top of experience. So I am happy to build up rather than rinse
and repeat just because I already have to keep up with the technology space.

~~~
cprogrammer1101
Absolutely. I sat out the Ruby/Rails hype cycle and am none the worse for it.
Life is too short to waste time learning ephemeral tech like Ruby, Node.js, or
MongoDB. When considering whether to learn a new language or platform, I ask
myself, how long have people been using this, and how long will people likely
continue to use it? As a result, I know C, Common Lisp/Elisp, UNIX/POSIX, and
a relational database or two very, very well. I suspect I'd be much less happy
if I had instead spent time learning how to build single-threaded JavaScript
web apps that rely, in 2015, on cooperative multitasking, let alone doing so
with other hipster programmers who actually think it's a good idea.

~~~
freyr
I never bothered learning a newfangled, flavor-of-the-week language like C. As
a result, I'm an expert in COBOL and Fortran. I suspect I'm much happier not
knowing C.

~~~
cprogrammer1101
You know, you're right; there's no such thing as an ephemeral language or
platform. Why, look at all new projects started every day in QBasic, Tcl, or
Turbo Pascal.

I'm sure people will be building stuff with Ruby forty years from now.

