Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Rails 4 Live Streaming is a Big Deal

blog.phusion.nl

Post reply on HN
Print view View original

1–10 of 60 posts

Re: Why Rails 4 Live Streaming is a Big Deal

#3

Post by amix »

Rails is turning into a framework that includes everything, including the kitchen sink. Personally, I prefer to use the best tool for the job and node.js seems to be a much saner choice when doing realtime communication, since everything in node.js is non-blocking. There are so many ways to shoot yourself in the foot if you develop large realtime systems in Ruby (or any other language that includes a lot of blocking libraries).

Re: Why Rails 4 Live Streaming is a Big Deal

#4

Post by FooBarWidget »

parfe wrote: post #2

> Several days ago Rails introduced Live Streaming: the ability to send partial responses to the client immediately. Would this be analogous to what PHP does if you being writing a response without output buffering?

Yes you can do the same in PHP by disabling output buffering. You're limited by the web server's concurrency model however. Apache's mod_php only works on the prefork MPM so your concurrency is limited by the number of Apache processes you can spawn (which can be quite bloated because you run the PHP interpreter inside Apache). Another less commonly used but still notable setup is PHP via FastCGI (e.g. when using PHP through Nginx). Here you are limited by the number of PHP-FastCGI processes you spawn.

Re: Why Rails 4 Live Streaming is a Big Deal

#7

Post by jherdman »

amix wrote: post #3

Rails is turning into a framework that includes everything, including the kitchen sink. Personally, I prefer to use the best tool for the job and node.js seems to be a much saner choice when doing realtime communication, since everything in node.js is non-blocking. There are so many ways to shoot yourself in the foot if you develop large realtime systems in Ruby (or any other language that includes a lot of blocking…

I think this is a bit of an overreaction given that Rails has always been a "batteries included" framework. The fact that Rails allows for socket-like behaviour now is not a tipping point, but simply a nice little feature that may prove useful to some.

When Rails starts including a messaging stack, job server, and more, then I'd be right behind you in your complaint.

Re: Why Rails 4 Live Streaming is a Big Deal

#9

Post by cageface »

amix wrote: post #3

Rails is turning into a framework that includes everything, including the kitchen sink. Personally, I prefer to use the best tool for the job and node.js seems to be a much saner choice when doing realtime communication, since everything in node.js is non-blocking. There are so many ways to shoot yourself in the foot if you develop large realtime systems in Ruby (or any other language that includes a lot of blocking…

I think the problem is that Rails was designed to solve the web problems of 2005 and a lot has changed since then.

The shift to single-page, JS-driven applications and large numbers of dynamic updates requires a different set of design priorities and the performance characteristics of Ruby itself are more problematic in this environment.

In many cases it makes more sense to use something like Go or Node or Erlang that was designed to handle these kinds of loads from the ground up.

Post reply on HN