4 ms·

> one of the main draws to Node is the huge community and wealth of awesome modules. Socket.io, Now.js, cradle, redis Really? In my experience, all but the mos

> one of the main draws to Node is the huge community and wealth of awesome modules. Socket.io, Now.js, cradle, redis Really? In my experience, all but the most mature modules are hardly beta-quality and in constant flux. Find a good module for your job? Too bad it only runs on 0.4. Find another to get around that; oops, too bad your version of gcc needs to be patched and re-built. The language and its entire package ecosystem is so immature, I'm blown away people trust it in production at all. "So fix it and submit a Pull Request," you say? That doesn't help me when I'm trying to deliver on a deadline. I love contributing, but I often have more pressing things on my plate.

zzaman 14y ago
In my 6ish months of programming in Nodejs full-time, I have yet to run into a library that only runs on 0.4 only or requires my version of gcc to be patched and re-built. Which Node libraries were you trying to use?
blantonl 14y ago
I'm using cluster, crypto, express, memcached, mysql, and mysql-pool in production and they have worked flawlessly for a node deployment that serves a pretty busy JSON API (200-300 reqs a sec on average).
- mbthomas 14y ago
  As a counterpoint, I built a relatively large system using Node (this was a couple months ago, to be clear) and had issues with several modules. mysql: cannot handle binary blob columns (this is just now being fixed in an alpha version of the library). mysql: very slow parsing of large responses. aws*: many half built / half broken libraries -- nothing that met our modest needs. request: (http request library) found several issues. Node.JS has a great community that is writing many great modules, no doubt. But the community is very young and almost by definition many of the modules are immature. This can be very enjoyable from an engineering perspective (you get to write and hack on things that you would not otherwise), but can also slow down the process of building things since you do end up having to reinvent the wheel at times.
  - blantonl 14y ago
    In our case, it isn't a large system. Our node production environment serves up a smallish set of API/Ajax requests that are heavily used. With that, we've been able to eliminate more than a few Web servers that otherwise had to load the entire Apache/PHP stack just to serve a small 20-100 byte request. With your response in mind - I don't see Node being mature enough (yet) to solely support an end-to-end large scale Web property. But, for serving up API content from Memcache/MySQL - it is blazing fast with minimal footprint. On our stack - we run Node right on our existing Apache Web servers (behind haproxy).

zzaman 14y ago

In my 6ish months of programming in Nodejs full-time, I have yet to run into a library that only runs on 0.4 only or requires my version of gcc to be patched and re-built. Which Node libraries were you trying to use?

blantonl 14y ago

I'm using cluster, crypto, express, memcached, mysql, and mysql-pool in production and they have worked flawlessly for a node deployment that serves a pretty busy JSON API (200-300 reqs a sec on average).

mbthomas 14y ago
As a counterpoint, I built a relatively large system using Node (this was a couple months ago, to be clear) and had issues with several modules. mysql: cannot handle binary blob columns (this is just now being fixed in an alpha version of the library). mysql: very slow parsing of large responses. aws*: many half built / half broken libraries -- nothing that met our modest needs. request: (http request library) found several issues. Node.JS has a great community that is writing many great modules, no doubt. But the community is very young and almost by definition many of the modules are immature. This can be very enjoyable from an engineering perspective (you get to write and hack on things that you would not otherwise), but can also slow down the process of building things since you do end up having to reinvent the wheel at times.
- blantonl 14y ago
  In our case, it isn't a large system. Our node production environment serves up a smallish set of API/Ajax requests that are heavily used. With that, we've been able to eliminate more than a few Web servers that otherwise had to load the entire Apache/PHP stack just to serve a small 20-100 byte request. With your response in mind - I don't see Node being mature enough (yet) to solely support an end-to-end large scale Web property. But, for serving up API content from Memcache/MySQL - it is blazing fast with minimal footprint. On our stack - we run Node right on our existing Apache Web servers (behind haproxy).