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

  • 1
    @default.kramer: Thanks for the link, I really enjoyed it!
    – Zach
    Commented Nov 2, 2011 at 0:34
  • 1
    wow! Rather opinionated chap, eh? In the follow-up article, he seems to be saying that, for high-I/O and low-CPU applications, evented and threaded systems are roughly on par, and that the problem lies with novice programmers who don't know when to give up on events and spawn a new thread. But the ignorance of the programmer doesn't mean the tool is bad, does it? I do agree that using an environment whose forté is event loops for CPU-intensive tasks is a bit weird, but is it evil? Commented Nov 2, 2011 at 18:53
  • 1
    His hatred of JavaScript seems to be an important issue too, which I fear might be partly responsible for the energy behind his argument. Commented Nov 2, 2011 at 18:57
  • @Paul - You should probably take it with a grain of salt. I don't know much about Node.js; I just thought it was humorous. (like most of his writing) Commented Nov 2, 2011 at 19:28
  • @default.kramer thanks for the reminder; I tend to take people's opinions as gospel. His major valid criticism seems to be that you shouldn't use Node.js for CPU-intensive tasks. I'm confused about his criticism of worker processes; is there any big problem with creating separate workers for specific tasks? Commented Nov 2, 2011 at 20:54

7 Answers 7


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

  • So you think that pragmatic principles like familiarity, availability of libraries, etc, are strong arguments for a certain platform, eh? Those are good thoughts, and they're definitely things I'm considering. (I'm surprised you're advocating for out-of-the-box solutions; I thought you were a roll-your-own kinda guy!) Commented Nov 2, 2011 at 19:00
  • @Pauld'Aoust I am a roll-your-own kinda guy. However I get nothing done and I don't have deadlines.
    – Raynos
    Commented Nov 2, 2011 at 19:32
  • heh, thanks for the caveat. I do remember your comments on the node.js chat about using other people's model libraries (Backbone.js, etc) and realising that I was spending too much time learning Backbone.js and not enough time just taking advantage of (and learning) JavaScript's prototypical inheritance mechanism. Good advice; I feel much more relaxed now. Commented Nov 2, 2011 at 20:05
  • 4
    -1 vague. 1)Just because you have N years experience in X - does not mean you should avoid Node.JS. Are you proposing willful ignorance based on experience? And what are the "Generic reasons"? 2) 'other applications that let you write a generic application faster' - is purely subjective. 3) 'other *than "*I hate *JavaScript' - is also subjective and not a valid reason to avoid a flourishing technology. *spelling.
    – Jack Stone
    Commented Jan 8, 2014 at 17:08
  • @ClintNash some of your reasons are no different from his. "Human Resources" vs "N years experience" are the exact same. "NodeJS is not as mature as Traditional Frameworks" vs "Yes there are other platform that let you write a generic application faster, ruby on rails comes to mind." are also the same. Not only are they the same, but yours are no more measurable (objective) than his.
    – aaaaaa
    Commented Dec 17, 2016 at 19:50

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.

  • +1 ease-of-use in setting up multiple hosts is definitely worth consideration. Commented Aug 27, 2012 at 16:41
  • It's pretty simple to put node apps behind an Apache httpd or nginx server and routing requests with that app's URI signature to the node port (or ports).
    – TomG
    Commented Jan 8, 2014 at 14:42
  • +1 - the notion of node.js as a server-side proxy ('in conjunction with traditional web server') gained traction earlier this year and is worth looking into - especially if you have a large traditional architecture to manage. It is a design pattern that seems to make sense for the enterprise. But, it is worth noting - this is not a reason to AVOID Node.js but a reason to use it for specific purpose.
    – Jack Stone
    Commented Jan 8, 2014 at 17:13
  • 4
    -1 - Putting a proxy (like nginx) in front of node is a perfect use case and is actually a lot more secure and performant in some cases than not having one at all. It doesn't defeat any benefits of node. I tend to run my node apps on unix domain sockets, and then have nginx act as a gatekeeper. Commented Jan 8, 2014 at 21:57

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.

  • so you think there's not really much against using Node in place of more traditional app stacks; the issues are more to do with real-world concerns? Commented Aug 27, 2012 at 16:42
  • +1. Human Resources - and the unwillingness of some to learn JavaScript - is an inconvenient truth. This answer states it well. But, avoiding Node "because people Hate JavaScript" is not the logical progression either. Where would we be technically if we avoided every innovation - that someone else hated? Nowhere. The challenge with node is A) Getting new talent, or B) Educating traditional talent into new talent. To that point - we are seeing JavaScript code schools pop-up everywhere since John Resig's foresight in founding Khan Academy. In short, this is the way of things. +1. Well stated.
    – Jack Stone
    Commented Jan 8, 2014 at 17:39

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.


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.


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.

  • 2
    -1. I agree this answer will not be valid in 2015. But that is also reasoning for downvote.In essence - the decisions of today ARE the decisions for tomorrow. It nullifies the 8 bullet points above - if we can see that they are only temporarily relevant. 1)Scaling - Walmart Mobile scales, not a reason to avoid Node. 2) Isomorphic JS is no joke. Not a reason. 3) Server Sexyness? Most users know only ux. 4) Best practice is subjective, 5) Not Hot? -subjective 6) Easier? -subjective. 7) Stability is a temporarily relevant point. 8) NPM projected to pass Maven in 2014. No reasons here. Downvote.
    – Jack Stone
    Commented Jan 8, 2014 at 17:33

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.
  • 2
    -1 - Subjective points. "Preferred Syntax", "Documentation not as good", "Obsessive Callbacks", and "Already Done in my language" - are all vague and subjective. We've heard these before. They are debunked. No reason to avoid Node.JS here. Downvote.
    – Jack Stone
    Commented Jan 8, 2014 at 17:45
  • 1
    All of the points are my personal preference which I stated openly. Also how do you debunk personal preference? Commented Jan 9, 2014 at 10:37

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.

  • Point taken about HTTP being stateless and realtime-ish; however, I'm more interested in the pragmatic concerns about the typical definition of realtime: high volumes of low-weight requests. It seems a bit overkill to spin up a new PHP instance just to spew out three or four lines of JSON sometimes. Am I correct, or am I just suffering from parrot syndrome? Commented Nov 2, 2011 at 20:02
  • If you aren't loading PHP you are loading javascript, and there are various sorts of caching involved, so the difference there won't be enough to worry about. The big difference is in coding style and therefore maintainability - both platforms can output either HTML or JSON, but PHP was designed for people used to editing static html files, while node was designed for people used to modern javascript programming. Commented Nov 2, 2011 at 23:06
  • I know that I do have to load up an interpreter some time, but I see a benefit to having one instance of the interpreter running all the time (for low-CPU apps, of course) as in Node.js rather than having interpreters spin up and terminate with every request, as in PHP. Commented Nov 4, 2011 at 19:27
  • Yes, and I'd also expect js to have better performance at an individual request level given the amount of competition in that space recently. However, I think that is a relatively minor part of the difference - With node you have direct control and exactly the amount of code needed to serve the request, while any template based system that assumes you are serving pages will add unnecessary overhead and complexity in other scenarios. Commented Nov 7, 2011 at 0:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.