Hacker News Reader

Comment by davidw | Hacker News Reader

No, Rails isn't great for web socket kinds of things, but if it were me, I'd just use something else for that, and Rails for the main site. It's still one of the best things out there for quickly iterating, and yet still maintaining some structure and discipline, from what I've seen.

View on HN

Same here, i see it this way: use the right tool, for the right job. Sometimes it's Ruby/Rails, sometimes it's Node, somtimes it's something else.

> No, Rails isn't great for web socket kinds of things

You're doing the "best tool for the job" thing. But if Rails is not a good tool for the job of web socket programming... then ya kinda have to wonder why they're rolling a web socket thing into Rails core, no?

What I've done a few times in the past is had a Rails server for the main app, and a node-based socket.io server for the websockets. All the socket.io server does is listen to a redis server and emit events to the right listeners.

Agreed. I was fine with Railsconf focus last year of being "rock solid". Rails is still the best at what it does thanks to its community.

However, Rails 5 is moving to a direction that goes against the abstractions and platform it runs on. If I don't care about this, now I have even more code and dependencies in my Rails apps. On the other hand, if that is becoming the sanctioned way of building apps, I would rather do it elsewhere. To me it is a lose-lose situation.

I'm pretty sure "ActionCable" will be optional, as for example "ActiveResource" were

You could also use hosted solutions such as Pusher, Pubnub or Fanout which plays really well with frameworks

Reply on news.ycombinator.com