Live data from Hacker News

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

unlimitednovelty.com

111–120 of 127 posts

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

#111

I love Ruby, but I have no love for Rails. Want to write a nice JSON API using something light and nice? Use Sinatra, pick your favorite ORM (even ActiveRecord) and go to town. Why mess with all the other Rails junk when you can have a simple app.rb for your sinatra app and just write simple little controller actions and you're good to go? You don't need all the ceremony and structure of Rails and MVC to write a JSON…

Cheez, the reason to not use Sinatra for me is that I'd have to implement all the security measures myself. Sure for a hobby project or a really simple project it might be OK. I guess it all depends on what budget you have for spending time re-implementing all the plumbing.

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

#112

Earlier quoted context omitted.

Yeah. Just read the top comment (as I write this): "You don't need all the ceremony and structure of Rails and MVC." I think the problem with this outlook is that you don't need it...until you, you know, need it. Rails has a lot of niceties that you lose with Sinatra. Why not start from a superlight Rails app (using any of the many gems or ActionController::Metal options) and then add on bits and pieces when you need…

For me personally it's because Rails is so fucking slow these days. That's it, I don't mind having all that structure and ceremony sitting there. It doesn't stop me from architecting things however I please in lib/ and app/models/. But when it takes seconds for a brand new app to run `rake -T` it forces me to look for speedier alternatives. Speed will probably be what ultimately pushes me off Ruby as my bread and but…

rake -T One second for me running Ruby 1.9.3p125 with Rails 3.2.8.

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

#113
post #97
post #89

Earlier quoted context omitted.

I use Django for my projects and I don't share this opinion on the maturity aspect. Can you explain your statement a bit more? What aspects of Django are immature?

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.

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

#114

Earlier quoted context omitted.

I don't understand why you think Rails was on hold for all that time and that the modularity is not worth it. Yes it was a tremendous refactoring effort that took a lot of cycles, but Rails 3 has come out with great features. I mean arel, unobtrusive js, bundler, routing API, and actionmailer overhaul just in 3.0. The asset pipeline, full engine support, modularity benefits such as pluggable ORMs and log subscribers.…

It is worth pointing out that you're talking to the dude who wrote Jammit. The asset pipeline was not an innovation in or by Rails3.

I know who Jeremy is, and my question is legit. Innovation is a loaded term, and has nothing to do with the question of Rails stagnating. Rails is known for the nice packaging of good ideas, not for brand new ideas. I think you could argue the same about Node or 99.99% of all software since new ideas are extremely rare as are really good quality implementations.

So in all I seriousness, I want to know where he feels Rails is lagging.

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

#115
post #78

Earlier quoted context omitted.

For me personally it's because Rails is so fucking slow these days. That's it, I don't mind having all that structure and ceremony sitting there. It doesn't stop me from architecting things however I please in lib/ and app/models/. But when it takes seconds for a brand new app to run `rake -T` it forces me to look for speedier alternatives. Speed will probably be what ultimately pushes me off Ruby as my bread and but…

Do not blame ruby for the failings of rails. Personally I have never had any problems with speed when developing large projects with Ramaze, Sinatra or Padrino. In my experience this only happens to Rails. No clue why though. Maybe some gems used by Rails take too long to load.

Ah but if Ruby were faster Rails would be faster. Whether it's possible to do less and be acceptably fast is besides the point, I like Rails.

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

#116
I feel I've been struggling with Rails for a while now, at the time I've got excited about the promise Merb brought, but the merge hasn't noticeable changed the way I work. Mountable engines seems like a big hack to me and I some times struggle with class reloading in development because of it. Sinatra got mountable apps from the beggining because of being closer to rack, one could just us rack mount to inclue another app. I worked for a while on a big Sinatra app and it was a pleasant experience allthough Sinatra provides too little, but latelly I started a personal project on Padrino and a found a joy I havent felt in a wile using the languaje and tools I learned to love, Padrino is like I've allways wanted Rails. I am gratefull of what Rails has taught me, but I want to get off the bandwagon, Rails has grown to big and complex for my taste.

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

#118
post #107

Earlier quoted context omitted.

I get what you are saying, but I feel reducto ad absurdum is unfair here. I understood the parent's point as this; using Sinatra to give yourself the convenience of the {get,post,...} methods for working with HTTP vs. Rails, which forces upon you its more opinionated structure for websites. I agree with the parent, that I have no use for the complexity of Rails and Sinatra is convenient. Other people are free to choo…

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.

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

#119
post #97
post #89

Earlier quoted context omitted.

I use Django for my projects and I don't share this opinion on the maturity aspect. Can you explain your statement a bit more? What aspects of Django are immature?

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?

There were plenty of extensions that allowed you to use Selenium with Django, I maintained one of them. Django is fairly conservative about including new features into the core that work well as extensions. And this is something I value a lot.

The time zone support, though, was really overdue.

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

#120

Earlier quoted context omitted.

I don't think loud people contribute to the health of a community. In fact, I consider it a "community-smell" - when there is too much incentive to be a "rockstar", too many people will focus on being rockstars and not enough will be focus on actually getting the job done.

Right, totally agree, in the Enterprise Java world (love Java, can't stand the enterprise connotation) things ran a muck and we ended up with J2EE. Spring isn't better only different. Too loud voices in any camp just mess things up, then they move on and we are left to sort things out.

When it came out, Spring was massively different from J2EE. "J2EE Development without EJB" was mindblowing for the Enterprise community back in 2004
Post reply on HN