5 ms·

The problem with Node.js is that it's very good at it's original purpose and terrible at everything else. Node.js is excellent for building network services. It

by maratd 15y ago

The problem with Node.js is that it's very good at it's original purpose and terrible at everything else. Node.js is excellent for building network services. It is terrible at general server-side computing. If you need a server that consumes websocket connections, it's great. If you need to build a CLI script that installs and upgrades various software packages, not so much. If you need a chat server, it's great. If you need to build a CMS, not so much. Node is great for building services. Not so much for software that consumes those services.

robbrown451 15y ago
I'm not sure why it is bad for building a CMS. Admittedly, node isn't all that mature so doing so might be a little lower level right now than doing the same with, say, Rails. But it has one huge advantage which is that any modern CMS is going to have a good chunk of client side code, and there are immense advantages to having the same language on the client and server.
- maratd 15y ago
  The majority of services out there are self-sufficient. Take a very simple http server. It needs to talk to the local filesystem and serve the content requested. The only thing in that equation that might block is the filesystem. Node provides you the tools to deal with that and more. Building an http server in node is enjoyable, easy, and the end result performs well. The majority of software like a CMS is not self-sufficient. It needs a database, a filesystem, it talks to the http server, it might talk to a dozen other services (generate thumbnails, upload some files to a CDN, scan for viruses in an upload, etc. etc.). You get the idea. Each external dependency is a blocking dependency. You need to handle it and it isn't easy. Node provides you the tools, but unlike in our first example, where the only thing that blocks is the filesystem, here you have dozens of services that block, with hundreds of pain points. Writing code becomes a chore that is very unpleasant. That's not the worst of it. If you miss a blocking operation and don't handle it properly in node, which is very easy, your entire server will go down. In a thread-based or multi-process server-side language mistakes are painful, but not fatal. In node, missing a blocking operation is fatal. The node guys get this. That's why they're busy trying to cook up a solution around this problem. But they don't talk about it or advertise it. As of right now, node is definitely not a general purpose solution. It is, however, an excellent solution where you don't have a lot of dependencies that block.
  - robbrown451 15y ago
    That makes sense, mostly, but I'm a bit confused as to what you mean by saying it is easy to "miss" a blocking operation such that it will take down your server. It seems pretty hard to have any operation be blocking in node. To my knowledge everything I can do in node is asynch (with exception of a few blocking file functions, but I don't use those as there are asynch versions which are recommended anyway) I'm also a bit puzzled by your statement that there are people working on the problem but not talking about it. Do you have some inside information? :) I do agree that it is a solvable problem, however.
    - justincormack 15y ago
      If you integrate to an external native library it might block.
    - maratd 15y ago
      > It seems pretty hard to have any operation be blocking in node. A blocking operation is essentially anything that takes a while to complete. It blocks everything, because node is focused on doing that one thing. Usually this happens with external services, where node requests something and then waits for a response. Those are easy to spot. But you can write code in any language that takes a while to do something. And it's very easy to do so and miss your mistake =) > I'm also a bit puzzled by your statement that there are people working on the problem but not talking about it. I don't mean it's a secret or something. They talk about it on Google Groups and in change logs. I'm saying that's something that should be on their front page of their website explaining things. Maybe have a nice little chart of dos and don'ts.
    - route66 15y ago
      > It seems pretty hard to have any operation be blocking in node ... To my knowledge everything I can do in node is asynch As soon as you code an endless loop in a function it blocks the server forever. Do a long calculation: it blocks for the time running. Node is no magic dust which turns everything it touches into asynch high speed code. Node is asynch only when it comes to operations that are external to your code. (network, file system) . One could even argue that CPU intensive code being external to node but running on the same server could block if it's not running on a different CPU altogether.
olegp 15y ago
I've found the traditional synchronous approach I am familiar with from Ringo (http://ringojs.org http://ringojs.org) a better fit for general purpose server side work, so I've made it possible on Node with the help of node-fibers. Common Node (https://github.com/olegp/common-node/ https://github.com/olegp/common-node/) gives you the best of both worlds: it's easy to develop in & debug just like Ringo yet has low memory usage and is easy to integrate with existing Node libraries. Here's a very simple CMS I wrote in it: https://github.com/olegp/mcms https://github.com/olegp/mcms Here's a canonical blog example that also shows the use of the synchronous Mongo driver: https://github.com/olegp/notes https://github.com/olegp/notes
- maratd 15y ago
  > I've made it possible on Node with the help of node-fibers Cheating! It's not in core. Yes, it largely solves the problem at hand, but we're not talking about node + fibers or even the node + features they're currently working on. We're talking about node. Node doesn't have fibers. Although I wish it did! Fibers really don't belong in the user-space ...
  - olegp 15y ago
    They work in user-space and are portable, so I don't see the problem. Also, even if one opposes the idea of co-routines due to the problem of not knowing which function will yield, there's no denying that they provide one of the best current solutions to the flow control issues with a clean upgrade path to generators when those become available in V8 in 18 months or so.
enjo 15y ago
Yep...and if you use it for that it's brilliant. My latest project runs Python/Pyramid and MongoDB for the more traditional computational stuff. We have a notification architecture running through node.js/socket.io sending real-time events down to the browser. It works beautifully. All of that COULD have been implemented within the Pyramid layer (or Twisted..or whatever), but it would have been much more difficult and time-consuming to do.
- maratd 15y ago
  I'm doing something similar, only with PHP + MySQL for the more traditional stuff. Node.js runs a websocket server + http + fastcgi. Browsers connect as clients. PHP connects as a client too when it needs to. Node.js facilitates the back and forth. I could have done it in PHP, but it would have been an absolute nightmare.
- kuviaq 15y ago
  You can run pyramid through gevent wsgi and use gevent-websockets to get the same functionality. Highly performant, no callback soup, and all one stack.
democracy 15y ago
Thanks dude, that's probably the best introduction to Node, I would put it to Node's front page ,really.
oleg008 15y ago
bullshit

by maratd 15y ago

robbrown451 15y ago

I'm not sure why it is bad for building a CMS. Admittedly, node isn't all that mature so doing so might be a little lower level right now than doing the same with, say, Rails. But it has one huge advantage which is that any modern CMS is going to have a good chunk of client side code, and there are immense advantages to having the same language on the client and server.

maratd 15y ago
The majority of services out there are self-sufficient. Take a very simple http server. It needs to talk to the local filesystem and serve the content requested. The only thing in that equation that might block is the filesystem. Node provides you the tools to deal with that and more. Building an http server in node is enjoyable, easy, and the end result performs well. The majority of software like a CMS is not self-sufficient. It needs a database, a filesystem, it talks to the http server, it might talk to a dozen other services (generate thumbnails, upload some files to a CDN, scan for viruses in an upload, etc. etc.). You get the idea. Each external dependency is a blocking dependency. You need to handle it and it isn't easy. Node provides you the tools, but unlike in our first example, where the only thing that blocks is the filesystem, here you have dozens of services that block, with hundreds of pain points. Writing code becomes a chore that is very unpleasant. That's not the worst of it. If you miss a blocking operation and don't handle it properly in node, which is very easy, your entire server will go down. In a thread-based or multi-process server-side language mistakes are painful, but not fatal. In node, missing a blocking operation is fatal. The node guys get this. That's why they're busy trying to cook up a solution around this problem. But they don't talk about it or advertise it. As of right now, node is definitely not a general purpose solution. It is, however, an excellent solution where you don't have a lot of dependencies that block.
- robbrown451 15y ago
  That makes sense, mostly, but I'm a bit confused as to what you mean by saying it is easy to "miss" a blocking operation such that it will take down your server. It seems pretty hard to have any operation be blocking in node. To my knowledge everything I can do in node is asynch (with exception of a few blocking file functions, but I don't use those as there are asynch versions which are recommended anyway) I'm also a bit puzzled by your statement that there are people working on the problem but not talking about it. Do you have some inside information? :) I do agree that it is a solvable problem, however.
  - justincormack 15y ago
    If you integrate to an external native library it might block.
  - maratd 15y ago
    > It seems pretty hard to have any operation be blocking in node. A blocking operation is essentially anything that takes a while to complete. It blocks everything, because node is focused on doing that one thing. Usually this happens with external services, where node requests something and then waits for a response. Those are easy to spot. But you can write code in any language that takes a while to do something. And it's very easy to do so and miss your mistake =) > I'm also a bit puzzled by your statement that there are people working on the problem but not talking about it. I don't mean it's a secret or something. They talk about it on Google Groups and in change logs. I'm saying that's something that should be on their front page of their website explaining things. Maybe have a nice little chart of dos and don'ts.
  - route66 15y ago
    > It seems pretty hard to have any operation be blocking in node ... To my knowledge everything I can do in node is asynch As soon as you code an endless loop in a function it blocks the server forever. Do a long calculation: it blocks for the time running. Node is no magic dust which turns everything it touches into asynch high speed code. Node is asynch only when it comes to operations that are external to your code. (network, file system) . One could even argue that CPU intensive code being external to node but running on the same server could block if it's not running on a different CPU altogether.

olegp 15y ago

I've found the traditional synchronous approach I am familiar with from Ringo (http://ringojs.org http://ringojs.org) a better fit for general purpose server side work, so I've made it possible on Node with the help of node-fibers. Common Node (https://github.com/olegp/common-node/ https://github.com/olegp/common-node/) gives you the best of both worlds: it's easy to develop in & debug just like Ringo yet has low memory usage and is easy to integrate with existing Node libraries. Here's a very simple CMS I wrote in it: https://github.com/olegp/mcms https://github.com/olegp/mcms Here's a canonical blog example that also shows the use of the synchronous Mongo driver: https://github.com/olegp/notes https://github.com/olegp/notes

maratd 15y ago
> I've made it possible on Node with the help of node-fibers Cheating! It's not in core. Yes, it largely solves the problem at hand, but we're not talking about node + fibers or even the node + features they're currently working on. We're talking about node. Node doesn't have fibers. Although I wish it did! Fibers really don't belong in the user-space ...
- olegp 15y ago
  They work in user-space and are portable, so I don't see the problem. Also, even if one opposes the idea of co-routines due to the problem of not knowing which function will yield, there's no denying that they provide one of the best current solutions to the flow control issues with a clean upgrade path to generators when those become available in V8 in 18 months or so.

enjo 15y ago

Yep...and if you use it for that it's brilliant. My latest project runs Python/Pyramid and MongoDB for the more traditional computational stuff. We have a notification architecture running through node.js/socket.io sending real-time events down to the browser. It works beautifully. All of that COULD have been implemented within the Pyramid layer (or Twisted..or whatever), but it would have been much more difficult and time-consuming to do.

maratd 15y ago
I'm doing something similar, only with PHP + MySQL for the more traditional stuff. Node.js runs a websocket server + http + fastcgi. Browsers connect as clients. PHP connects as a client too when it needs to. Node.js facilitates the back and forth. I could have done it in PHP, but it would have been an absolute nightmare.
kuviaq 15y ago
You can run pyramid through gevent wsgi and use gevent-websockets to get the same functionality. Highly performant, no callback soup, and all one stack.

democracy 15y ago

Thanks dude, that's probably the best introduction to Node, I would put it to Node's front page ,really.

oleg008 15y ago

bullshit