Ask HN: Would you still bet on Node.js? | Hacker News Reader

Ask HN: Would you still bet on Node.js?

10 pointstangue21 comments

The buzz is fading, and I'm wondering if anyone on HN has feedback to share about running Node in production. Would you still use it today ?

View on HN

Not since I like using relational databases - MongoDB is the datastore of choice in nodeland and everything else is a secondary concern. Node's asyncronicity means very little to me since it is trivial to run a pool of fcgi server processes behind nginx and get parallelism that way. It's also hard to avoid "callback hell" consisting of anonymous functions nested X levels deep in what in another scripting language would have been nothing more than a few statements after each other. I heard "promises" could solve that but then I gave up because I don't want to use something that complicated just to implement basic control flow.

I think Node definitely is the right tool for a lot of use cases, but for 99% of all web sites, it's not the right choice.

I use MongoDB, but decided to stick with Python for similar reasons. The callback hell is an atrocity and Clojure pretty neatly demonstrates why it's 100% unnecessary.

I've never had any difficulties using Node with MySQL.

It's ok if you like running raw queries. But there's no decent orm you can use to abstract away the sql. node-orm does exist, but is currently very much alpha quality and does not offer nearly as many features as other orms in other languages.

Well, I'm not too worried about that. ORMs just lead to slower code that is harder to maintain.

"Callback hell"? Just curious, have you looked into flow control libraries like async yet?

Nope. I know about their existence but reasoned that if you need third party libraries for something as simple as sane control, flow then Node probably isn't ready. :) I'm planning to investigate them when I get time because they seem very interesting from a technical standpoint.

Short answer: Yes.

Long answer:

I am currently using it in production and it works great. It performs admirably, and is easy to use. I use to aggregate data relevant to our business.

It's basically a service I've written that anybody can send data to (in a particular format) to indicate that something happened. They can then subscribe to that "bucket" of data they have sent to the "collector" and it will let the subscriber know every time that event has happened.

This is a classic example of what Node is excellent at doing. Extremely low-latency IO handling that involves little-to-no computation.

It REALLY is that simple. Don't use Node for an application that is going to be a massive team effort (because sharing JavaScript code is a nightmare), and don't use it for an application that requires a good-deal of computation (something that you would use threads for in other languages/environments that isn't IO-handling).

The problem is that using Node (and all other things) requires a value judgement. Exactly how massive is too massive? And exactly how much computation is too much? The computation question gets a bit tricky to, because if it's computation that is extremely complicated but won't be executed all that often then Node may still be the right tool for the job.

The hype around Node is fading, because people "In the know", now have a clear understanding of what Node is good at and what it is bad at. The technical reasons why this is the case are not hard to grasp, but they take a while to explain and cannot be labelled as being "all-good" or "all-bad" (indeed Node's technical limitations have also given it some of its major strengths).

Using javascript as a main language for large projects is bad idea, let alone node.js. In browser environment at least you can use debugger, while on server side using any of available js interpreters/compilers is a black box just like rails/php/django etc.

Javascript is a scripting language and on server side it should be used like this.. scripting language, small and independent pieces of code, not a 100kloc+ "OOP" clusterfuck :)

You can use the browser's debugger to attach to a nodejs process:

https://github.com/dannycoates/node-inspector

that's very cool! not sure if it's production ready,

should my business depend on some weekend projects posted on github?

I second your comment, it's a very valid concern.

I wish my weekend projects had +100 forks and thousands of developers bookmarking it...

I'd suggest if that is your attitude towards github projects, perhaps any development involving open source projects isn't for you...?

Node's philosophy is exactly that: small and independent services that together make an application. If you want a huge monolithic codebase definitely avoid node.

The "script" in javascript doesn't make it any less of a programming language (it was a marketing play on Java), and in some ways it is more powerful than many others. Debugging is the same as debugging any other server-side language, and you're only worried about your application code; V8 is a very stable project, you're not going to find yourself debugging the interpreter.

I would, but it definitely depends what for. I use it with sequelizejs (MySQL) at the moment in a biggish web app and it works really well. We have a LOT of forms and complex validations, prefills, searches etc, which are a joy to do without having to write them in 2 languages because I want them on client and server. With supervisor and node-inspector, expressjs, passportjs, socket.io and so forth everything is just a joy.

This is already a part of the 'easy validations' but it comes in in a lot more places; being able to just shove the same code to client and server and have it run is really a win for me. Simplified, I have my own class libraries which are loaded both on client and server with most code the same and some different depending where I am, and without thinking I can just execute the same code everywhere; I even just send code via socket.io from server->client dynamically when it comes in handy and it's a better experience for the user.

I've written several tools which need to send data to "a server" of some kind. Writing trivial node.js servers is painless, and the event-based approach makes them scale really well.

For these ad-hoc kind of systems it is hard to think of anything as fast and simple to get started with. (Sure you could use Twisted, Sinatra, or some other framework, but node.js is very very simple to get started with which helps a lot.)

I'm using http-proxy to filter requests and act as a http firewall to internal services.. I'm using Node with Redis to monitor internal system. I'm using Node wit Faye to deliver realtime information. For expensive computation, there are many drivers in Node.js you can use to communicate. I think Node.js is a great tool for front-end.

Depends. I recently did a small project that node was a perfect fit for.

But for most larger things I like having threads, and an event based network loop. For that I'm a bit if a java guy and use netty.

Depends. It works for some kind of project, doesn't for others.

Event based I/O concurrency (regardless of programming language) is a #win.

Agree. I always multithreading patterns should apply for expensive computation programs in the backend, we don't need thread for I/O concurrency.

Reply on news.ycombinator.com