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…
Why critics of Rails have it all wrong (and Ruby's bright multicore future)
111–120 of 127 posts
Re: Why critics of Rails have it all wrong (and Ruby's bright multicore future)
#112Earlier 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…
Re: Why critics of Rails have it all wrong (and Ruby's bright multicore future)
#113Earlier 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?
Re: Why critics of Rails have it all wrong (and Ruby's bright multicore future)
#114Earlier 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.
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)
#115Earlier 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.
Re: Why critics of Rails have it all wrong (and Ruby's bright multicore future)
#116Re: Why critics of Rails have it all wrong (and Ruby's bright multicore future)
#117Re: Why critics of Rails have it all wrong (and Ruby's bright multicore future)
#118Earlier 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…
Re: Why critics of Rails have it all wrong (and Ruby's bright multicore future)
#119Earlier 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?
The time zone support, though, was really overdue.
Re: Why critics of Rails have it all wrong (and Ruby's bright multicore future)
#120Earlier 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.