Node.js Frameworks Comparison | Hacker News Reader

Node.js Frameworks Comparison

ocdevel.com

47 pointsjohnx123-up16 comments

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.

Great to hear of your success with SocketStream!

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!

Owen

I do use AngularJS on my client side, it works extremely well with Express on the server side.

I really liked how the article mentions Express isn't a framework and doesn't try to get in your way, this is exactly why I chose it!

Cached version: http://webcache.googleusercontent.com/search?q=cache:PKds6Tk...

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.

It's down. I hope this blog doesn't run on Node.js

No, it runs on drupal.

That explains it all.

To be fair, using varnish and proper cache modules with drupal, you can make drupal very immune to this sort of traffic.

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 ?

postgres or postgresql, not postgre. SCNR

Since you are so smart, why dont you answer the question ,french man?

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.

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.

Reply on news.ycombinator.com