Is there a good reason to avoid node.js for non-realtime web apps?

Question

I've seen a lot of talk about how awesome Node.js is for realtime web apps -- things that need sockets, Comet, AJAX-heavy communications, and so forth. I know that its event-driven, asynchronous, thread-driven model is also good for concurrency with low overhead.

I've also seen Node.js tutorials for more simple, 'traditional', non-realtime apps (e.g., the standard blog example, which seems to be the standard 'Hello World' for people learning app development). And I also know that node-static allows you to serve static assets.

My question is: is there any good reason to avoid Node.js for traditional web apps, like classifieds, forums, the aforementioned blog example, or the sort of CRUD apps you build for internal business applications? Just because it excels at all the funky realtime stuff, does that contraindicate it for more staid uses?

The only thing I can think of, off the bat, is the lack of mature libraries (although that's changing).

(The reason I'm asking is that I'm considering ditching PHP for Node.js, mostly to get over the impedance mismatch of switching between languages, but also so I can reuse validation code and whatnot. My superego admonishes me to choose the best tool for the job; however, I don't have a lot of time to learn fifteen languages and all their userland libraries just to have a comprehensive arsenal. It's also reassuring that Node.js might give me an easier optimisation path than PHP/Apache in the future when I have to start thinking about heavy traffic.)

[EDIT] Thanks for the answers so far, folks; I just want to see if anyone else will weigh in before I choose an answer. The answer from @Raynos kinda confirms what I'm thinking, and the links from the commenters provided good food for thought, but I want to see if anyone else has any Node-specific answers, like 'DON'T USE NODE FOR PROBLEM X'. (Besides high-CPU tasks; I know that already :-)

Answer 1

is there any good reason to avoid Node.js for traditional web apps

Yes, if you have N years in web platform X then clearly you can developer an application in platform X faster.

If you want to do Y and platform X has a pre-made solution Y that does X then do so.

All the generic reasons of why you should use one platform over another.

the sort of CRUD apps you build for internal business applications?

Yes there are other platform that let you write a generic application faster, ruby on rails comes to mind.

However, that said. I have experience with node and can't claim I would choose another platform over node unless it does a massive amount of features out of the box for me.

Basically it's a simple question of

Does a tool exists that does all of this for me? No, then pick the most convenient platform to write the tool.

There are no solid reasons why node.js is an inconvenient platform (other then "i hate javascript")

Answer 2

After working with node for a few weeks, I'd say yes, its very cool. But not necessarily something you'd want to use to replace your run-of-the-mill web apps with... nor, imo, is it intended to be.

Remember, node is its own server. This introduces complexities if you want to run more than just your one node.js application. ie, if you have more than one site/domain hosted on a machine. Its not like a LAMP stack, where you can have a dozen PHP applications for a half dozen different domains running off the same server (on port 80, at least). There are frameworks for node that probably make it possible, but thats adding complexity that you just dont need if you stuck to traditional web platforms. (You can, of course, also set up proxies by putting a web server in front of node, but that sort of defeats the benefit of using node).

imo, Node is perfect for working in conjunction with a traditional web server. The way I have things organized now is to serve up the static html/js/images via apache, and handle the 'real time' data needs by long polling to the node application.

Answer 3

A good reason to have seconds thoughts about node are not technical - it's great and amazing at what it does.

They are business and specifically human capital, i.e. programmers who know it, how much they cost and their availability. It's not that hard to learn, but as with any newer technology the number of people who know it well (or want to) is a subest of the larger pools of workers.

Answer 4

This is a very good question, that we must ask, in order too advance the state of the art.

I was very curious to know (like Paul d'Aoust) where the limitations of Node.JS exist. Sadly, many answers are FULL of subjective bias and temporarily relevant rationale.

I asked myself: CAN WE FILTER OUT SUBJECTIVE BIAS AND GET DOWN TO SOLID ANSWERS TO THIS RELEVANT QUESTION?

The remaining points seem to be:

1. NodeJS is not as mature as Traditional Frameworks. As Paul d'Aoust suggests, this is only a temporarily relevant reason, not for full avoidance - but instead review and due diligence. Doing our homework as web professionals is expected, and it is our job to determine the best-fit of the technology to the organization, their needs, their future, the team (and not us). Maturity is a need for clarification and a judgement for appetite for risk, but not avoidance.

2. NodeJS as a Proxy Server. A wise suggestion, of prior discussion, that is worth review and consideration. It is the notion of using Node in correlation with existing technologies as a front-end interface proxy design pattern. But also, it is not a reason to AVOID using node, but instead a reason to avoid using it as a full replacement. Instead opting for a corollary approach.

3. Debugging Node. In conversation with core Node developers at Joyent there is much complication surrounding debuggability and tracing back the root cause of problems resulting from the core (based on single thread execution and inability to see into past threads). This is worth consideration and evaluation - but (again) likely not aversion for common usage only edge-cases that may push the envelope. Maybe your specific needs would fall into this category and maybe they will not.

4. Human Resources. This is the best reason to AVOID using JS on this page, and in my humble opinion it is a stark and inconvenient truth. It begs the question: does your company have the right talented professionals on hand to see the project through full life cycle? If not, there is no question that you need to avoid NodeJS. Or instead consider A) locating the correct talent, or B) Educating existing talent.

Complaints: My observation of the complaints on JavaScript is that, many result more from User Error than they do from consistent failings of the language. We have debunked many claims against "The Hate JavaScript Diatribe" and we will continue to debunk many more. Such problems as - documentation is not good enough, it is not sexy enough, but people don't like it, it is cancer, it is the devil, or it is too "typo-prone" (-CRichardson), are subjective and biased complaints that need to be weeded out for accurate corporate decision making.

In the end, the correct answer may be - there are no good reasons to AVOID NodeJS. Maybe this is why it is experiencing rapid growth, adoption, and contribution. But for all of us perhaps the answer here is to continue to evaluate, research, and understand NodeJS better - and look for concrete aversions. In the pursuit of being open to understanding exactly where Node.JS is immature - we find exactly where we need to make it better. And that is a blessing.

Good question. I for one remain curious for someone to bring up a better reason to avoid NodeJS - than these.

Answer 5

Is there any benefit of using node over X for non-realtime applications:

• Scaling: Node has good performance but other platforms do too; PHP, Ruby, Python and Java all scale. You can find BIG names with millions of users are using them.
• One language for frontend and backend: It's a joke, just like Java's "Write once run anywhere"
• Hot and sexy: The only valid point. But no one cares that your website is using edgy tech!

Benefit of using X over Node for non-realtime applications:

• Best Practice: Because Node is new it has fewer best practices than other platforms, specially for CRUD web applications.
• Javascript Language: People don't like Javascript. While Node.js is hot, Javascript is not. This is why people created Coffeescript to avoid writing Javascript even for the client side.
• Developing Speed: The old and boring frameworks including and not limited to Rails and Django are well tested and improved over many years for CRUD websites. While you can implement similar applications in Node, it's just easier to do in your grandpa's framework.
• Stability: Node's web frameworks are getting better at a faster pace. It means they are changing and will have more API incompatibility in the near future.
• Libraries and tools: The older technologies with more users have more libraries and tools.

My answer definitely won't be valid in 2015. In 2014, skip Node for non-realtime web applications but keep an eye on it.

Every web framework has a strong point. You'll be happy while you are using it for that point. Non-realtime web applications are not Node's web frameworks strong point.

Answer 6

Node.js is very popular platform and it has a lot of interesting features blah blah blah, but usage of a tool is a personal preference. I gave Node.js a four times and I wasn't happy with it. Here are my reasons. Please keep in mind that some of those reasons are outdated, or simply personal :P

• I preferred different language/syntax (I like Python, Scala, my favourite language is Prolog so yeah).
• Quality of documentation for frameworks and libraries that I used is not as good for Java, Scala, Python libraries.
• Designers of the nodejs are quite obsessed with callbacks instead of event model, observer or futures.
• There is ready sollutions for what I want to do in Ruby, Python, Java developed back in 2005, I just need to edit config file.

Answer 7

HTTP is stateless, so there is actually no such thing as a non-realtime web app and therefore no reason you can't use node for everything.

That said, node is better suited for a particular type of application architecture. PHP is html files containing a bit of code. Node is code optionally containing a bit of html.

This means that if your app is standard html forms without any client side script, PHP will be easier. Node does have templating tools, but obviously not as mature as something like PHP.

If you have a lot of client side scripts and save the data with ajax, you end up with a static html client calling functions on the server. This is exactly what node is good at. While not the way CRUD apps are usually built, you can produce something pretty nice with the right framework.