The last point the op makes is that you don't need a nodejs framework if you're using backbone/angular/ember. I've consistently used Socketstream combined with Ember in my for-fun projects, and it's extremely easy to build use. Combine that with the massive fun I'm having pushing events to the client from node and watching ember observers adjust accordingly, wonderful things can happen.
On topic - Socketstream is actively being developed and is pretty damn awesome (not to mention easy to pick up). Meteor and TowerJS turned me away when I saw the amount of rigidity in their implementations, whereas SS allows you to plug modules in and out of the framework with ease.
While there is still lots to do, I am happy with the way the latest version (0.4) is progressing and very excited about the new support for Node Streams.
As you mention, SocketStream is indeed under active development, but most of that is currently going on in this experimental repo (https://github.com/socketstream/socketstream-0.4) and offline.
I hope to get a stable 0.4 release out early next year, along with full documentation, tutorials and more. Stay tuned!
Nice article, and really stresses the tradeoff between flexibility/control and development time. Being control freaks, we use plain old Express at tldr.io , it's true that you need to tie everything yourself but in the long-run I think we actually save time by knowing exactly what we do and why we do it.
Core Drupal caching can handle a lot (my blog has handled the top spot in HN a couple times with only that without issue), and adding Varnish alone can scale it to huge traffic levels. The GP comment is just FUD.
What I don't understand is why people don't get ready to take the hit; use a cached static version, use varnish, get more instances; just don't let it go down.
Does Node really scales better than other solutions with blocking operation ? ( read/write files, read/write from synchronous dbs ,etc... ) , i understand it works quite well with queue messaging or async databases ,etc ...
But is it really better when one uses it for "classic" CRUD websites that display webpages and get their infos from , a postgres database ?
For your typical CRUD app, you won't notice a big difference. Rails/PHP/Java/ASP.net should deliver similar performance. If you're using Windows, Rails will slow down significantly unless you're using the latest JRuby 1.7/Java 7 release. The biggest "no-no" for a node app is proxying it behind a threaded webserver like Apache.
The blocking in node.js happens at the C++ level. Your JavaScript thread is still free to process other requests while your initial request waits for a response from the database.
However, without a memcache or redis layer in front of postgres I suspect the database machine will run out of resources way before the web server machine does.
On topic - Socketstream is actively being developed and is pretty damn awesome (not to mention easy to pick up). Meteor and TowerJS turned me away when I saw the amount of rigidity in their implementations, whereas SS allows you to plug modules in and out of the framework with ease.