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

Why critics of Rails have it all wrong (and Ruby's bright multicore future)

unlimitednovelty.com

Post reply on HN
Print view View original

121–127 of 127 posts

Re: Why critics of Rails have it all wrong (and Ruby's bright multicore future)

#121

Post by Styck »

dscrd wrote: post #113
bascule wrote: post #97

Earlier quoted context omitted.

The release notes for Django 1.4, for example, list support for both Time Zones and Selenium. Time Zones were added to Rails 2.1 in 2008. selenium-on-rails also debuted in 2008. Does it not seem strange to you that it took 4 years after Rails for Django to get these features?

Really, if you wanna complain about something that's in Rails and not in Django properly, talk about database migrations.

Not really a fair feature comparison. If db migration wasn't in Rails, ActiveRecord wouldn't work the way it does. You can't say the same about Django's ORM.

Re: Why critics of Rails have it all wrong (and Ruby's bright multicore future)

#122

Post by ZoFreX »

bascule wrote: post #77
ZoFreX wrote: post #13

I agree a lot with this but it contains its own absolutely huge non-sequitur: How on earth is Cramp an example of damn simple websockets in Rails? It's Ruby, not Rails. It's also probably worth mentioning that it literally only works with Thin, is unmaintained, largely undocumented, and that the latest master on GitHub doesn't actually work. Not really the best example to pick!

Cramp is based on Rack, just like Rails... there is nothing stopping you from using the two in conjunction.

Well, no. But if someone said "CodeIgniter sucks" and the counter-argument was "No it doesn't, there's this great framework called Symphony" you'd probably take issue with that, no?

Re: Why critics of Rails have it all wrong (and Ruby's bright multicore future)

#123

Post by hackerboos »

dscrd wrote: post #113
bascule wrote: post #97

Earlier quoted context omitted.

The release notes for Django 1.4, for example, list support for both Time Zones and Selenium. Time Zones were added to Rails 2.1 in 2008. selenium-on-rails also debuted in 2008. Does it not seem strange to you that it took 4 years after Rails for Django to get these features?

Really, if you wanna complain about something that's in Rails and not in Django properly, talk about database migrations.

South...but I agree that database migrations should be part of the Django core.

Re: Why critics of Rails have it all wrong (and Ruby's bright multicore future)

#124

Post by cheald »

krichman wrote: post #118
cheald wrote: post #107

Earlier quoted context omitted.

I absolutely agree with you. What sticks in my craw is the oft-repeated mantra that "Rails is too heavy" or the perception that Sinatra is doing something that Rails isn't. When you look at Rails as a collection of middlewares (which you can choose!) and support libraries (require 'rails/all' may not be needed!), instead of looking it as a monolithic black box that can't be configured to fit your needs, it's suddenly…

I guess I got the wrong impression from your argument. It all depends on what you are trying to accomplish, as you say.

The reducto ad absurdum was a poor choice, and likely obscured the point, so my fault. :)

Re: Why critics of Rails have it all wrong (and Ruby's bright multicore future)

#125

Post by VeejayRampay »

cheald wrote: post #21
mtkd wrote: post #5

"Rails is great for JSON APIs" Rails is good for simple APIs (especially adding an API to an existing HTML site). However, if you want to do more than that, elegantly - it isn't great yet. You quickly end up with some fairly messy serialization hacks and confusion between what should sit in the controller and the model. The active_model_serializers gem is a really good start, but there is a way to go to get to the le…

Use decorators. Draper is my personal favorite, and it very cleanly solves the issue of serialization nightmares and controller/model confusion. (I hope that it ends up in the Rails core someday, because it really is a gamechanger in how Rails is used for non-HTML content!)

Agreed, Draper + Jbuilder and you got yourself plenty of decoupling and beauty.

Re: Why critics of Rails have it all wrong (and Ruby's bright multicore future)

#126

Post by AffableSpatula »

samd wrote: post #47

"Modern HTML5/JS apps depend on beautiful, consistent RESTful JSON APIs." "Rails is great for JSON APIs." "Many of these companies have client-heavy HTML5/JS applications which consume a JSON API coming out of Rails. Many of them have APIs that are routinely cited as archetypical RESTful JSON APIs." Rails is great for JSON RPC over HTTP. It's not great for beautiful, consistent RESTful APIs. It still lacks basic supp…

there's a gem called roar that's been around for a while for producing hypermedia in ruby. there's also a roar-rails gem specifically for integration with rails.

Re: Why critics of Rails have it all wrong (and Ruby's bright multicore future)

#127

Post by deafbybeheading »

jes5199 wrote: post #81
tlack wrote: post #73

Earlier quoted context omitted.

Node is no panacea, but that's not quite true about stable APIs. npm is great about maintaining separately versioned libraries and reducing conflicts. In your package.json can specify what version of a library to use and npm mostly figures it out for you. For instance, I'm still intentionally using an older version of Express (2.5.9 instead of 3.0.x) and npm hasn't had a problem figuring out deps. Part of the reason…

sure, but, if you chose to upgrade to Express 3.0.0, would your application still work? or are all the method signatures in Express 3 different from Express 2.5 ?

And (as you note above), is 2.5 still getting critical bug fixes? There's a thin line between stable and stagnant.
Post reply on HN