Is Node.js declining already? | Hacker News Reader

Is Node.js declining already?

quora.com

63 pointsbemmu57 comments

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.

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.

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.

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

It's a feature in search of a problem. Nobody is rushing to replicate this, because it's difficult to leverage. There are few languages that do not have a way to parse json and are all easier to maintain.

> It's a feature in search of a problem

I very much disagree. Using react and webpack I can render my views on the client and the server using the same code and using react-router I can even share the routing code unmodified on both ends. Having a fully powered SPA that cleanly falls back to server rendering for crawlers and no-script clients is pretty sweet, in my experience.

This has been my experience. To the extant that I'm trying to embed Javascript everywhere now. Many server-side operations are deterministic and only need to be executed on the server because it's a trusted environment. They can be executed "optimistically" on the client if you have the same information and a compatible runtime. It makes everything feel snappier and enables a practical programming model. A single state transition function for each "action" performs the immediate client update and triggers validated server persistence in parallel. Without a ubiquitous execution environment that's like four/five times as hard.

Pre-rendering SPAs on the server is rather nice and there's several frameworks which cover the hard parts for you, but there's also no great downside to using node.js for just that and writing the rest of the backend in some other language.

This is pretty much where I'm at. I've always rolled my eyes a bit at node.js, but a current client is using it to render SPAs and I don't think I mind that at all. For my own stuff I'd do the heavy lifting in Rails or on the JVM (depending on my needs), but I am truly sold on React/Webpack for that.

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

I haven't seen it either.

I think node running JavaScript and having NPM were much more "killer features"

I mean, 99% of PHP-devs already knew JavaScript and NPM give you something like RubyGems without the need to learn Ruby.

We do. We have one app where that ability is a key part of its design. I'm sure there are others.

On a different app I was working on yesterday, I was adding a feature. That feature was much easier to do on the server, so I moved a bunch of code from the client to the server. Less than an hour's work in Node, it would have taken several days in any other framework.

With React.js this pattern has become much more prominent and simple, with pretty obvious benefits being shown with little effort.

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

Any directions with this?

We use the Rendr library, which is built on Backbone: https://github.com/rendrjs/rendr

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

In practice this (almost) never happens. The popularity of NodeJS has much more to do with asynchronous I/O, and having a package manager that is working very well for the community.

what the clueless developer says: it's concurrent

what the clueless eng manager says: the same code can run on the server and client. no more front end hiring hell!

The ability to deploy the same code to front end and back, for me anyway, works out quite well. With browserify, I can write common utilities and require the code using the commonJS module system. It's pretty seamless. Doesn't change the skill set necessary for front end development in any way though.

> That addresses Node's main pain point.

You mean being single threaded?

Node's event driven design is also called "co-operative multi-threading", and is more efficient than OS threading. It is annoying that you have to use multiple processes or Web Workers to use more than one core, but that is far from being the main pain point.

A), that does not allow parallelism, only concurrency. B), that is a description of all single threaded systems. "Event driven design" is euphemism for "bolted on async primitives to a single threaded language." Multi threading is a super-set of "event driven design", and a much more scalable one.

Node is largely a reaction to advances in event multiplexing like kqueue and epoll. It was intended to be a scripting language bolted on top of a single-threaded concurrency model. This design-decision corresponds to the before unseen degree of callback hell that is Node's primary pain point.

Who would ever design a language to be concurrent but not parallel? Seems like a work of masochism.

It was intended for low latency services that mostly wait on I/O. These services don't compute enough to need parallelism. Especially when you can just fork another process or FFI to a C library with proper threading if you need it. It is necessary that they be concurrent but parallelism introduces a LOT of complexity beyond that.

>Node's event driven design is also called "co-operative multi-threading"

I think you mean multi-tasking, not multi-threading. And isn't cooperative multi-tasking the Windows 3.1 model on DOS? Not sure how cooperative multitasking is better than OS threading.

And am I mistaken, or is Node.js the same thing as Windows programming model from 1990 repackaged in Javascript? Windows programs have single message loop, and Windows events and you write callbacks that handle those particular events, like when a mouse clicks, when it moves, etc.

It's a common paradigm for UI programming. This is the basic backdrop of JS in the browser as well.

It's a hell of a restriction for everything but UI programming, though.

Well the call back hell which is a consequence of the event loop paradigm which is in turn due to being single threaded. But callbacks aren't a big deal with the intro of native Promises in ES6. And a lot of people (me included) find the event driven paradigm very useful for simple REST backends serving mobile apps.

I feel like if you make an effort to avoid callback hell, you can prevent it fairly easily. I don't know if I'm not writing complicated enough code, or everyone else is just bad at JavaScript.

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

In most cases that's not even completely true. Try to run in the browser anything with a node require... That's why we have to use ugly hacks like browserify :/ (not meant to bash browserify, it's really useful. The ugly thing is having to bundle 10s of thousands of javascript lines of multiple packages in a single file)

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

https://www.google.com/trends/explore#q=nodejs

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

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

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

https://www.google.com/trends/explore#q=php%2C%20javascript&...

But like node, laravel is also on fire...

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

But is that a lagging indicator? Peak manpower for a successful project comes well after a project starts. Node.js was hip a couple of years ago, and lots of projects got started using it, so it wouldn't be surprising if lots of people are being exposed to Node because they've been added to these projects. In the HN echo chamber, hip projects have moved on to Go micro-services. Outside the HN echo chamber, Rails is still hip.

Wow, I did not realize the difference in search volume of PHP vs nodejs.

Thing is that node can be searched by "node" "nodejs" "node.js" thus the results will always be skewed by a single term like "PHP".

When you think about it, PHP is not as high as you would expect in comparison.

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.

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.

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

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.

It is Node.js's concurrency capabilities that are one of it's core strengths. There are very few other frameworks that can handle tens of thousands of simultaneous requests as well as Node can. In other framework that's tens of thousands of threads; in Node you can have tens of thousands of requests all blocked on I/O using a single thread.

That's absolutely not a specificity of Node.js. You can handle tens of thousands of simultaneous requests as well, and sometimes even better, in Go, Erlang, Stackless Python, Python 2 with Tornado or gevent, Python 3 with asyncio, Haskell, Java with vert.x or Quasar, nginx with Lua, and many other examples. Node.js is an interesting and useful solution to some problems, but please stop the repeating this unfounded marketing claim.

My favorite line is the last line.

A week is a long time in JavaScript.

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.

These articles on Node unpack the point to some extent:

- http://stackoverflow.com/q/22644328/417194

- http://www.future-processing.pl/blog/on-problems-with-thread...

- http://web.archive.org/web/20120911094357/http://dev.hasenj....

- https://news.ycombinator.com/item?id=4495101

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

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.

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.

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"!!!

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

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.

Node.js is not a language. Node.js may be declining, but Javascript is not going anywhere anytime soon.

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.

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.

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.

The Ruby/Rails hype cycle started like ten years ago. Rails is one of the most widely used web app frameworks in the market. Ruby's been around for twenty-odd years and has gone from being a niche scripting language to one that's used to power an outrageous amount of big applications. It's not a pissing contest by any means, but calling Ruby and Rails a hype cycle is just inaccurate.

Eh I disagree learning new languages can make you think in different ways. I know Ruby, Shell, C, Javascript and some OCaml and Haskell, each have taught me something that I apply to others.

Ruby doesn't teach you anything if you already know Lisp + CLOS or Smalltalk.

Reply on news.ycombinator.com