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

What’s Up With All These Changes in Rails?

yehudakatz.com

Post reply on HN
Print view View original

21–30 of 115 posts

Re: What’s Up With All These Changes in Rails?

#21

Post by psadauskas »

euroclydon wrote: post #15
ssmoot wrote: post #13

I'm not a fan of Rails myself, but I sympathize with Yehuda's position. The helpers are my #1 gripe with Rails. It really kills productivity to have to dig through all your views for what feels like pet changes. The one point Yehuda's making I'd dispute is the impact of Arel. I saw a very early version of Arel back when I was maintaining DataMapper. To be clear, Arel is beautiful code. It's ridiculously well done IMO…

Wow! This is the first I've heard that RoR's ORM is slow. That's it's slow because Ruby is slow, is even more of a shocker. I'd love to hear some practical limitations that applications using Ruby and NHibernate face when querying data. Is this slowness a reason that so many no-sql engines seemed to have sprung at the same time as RoR?

It is embarrassingly slow. I did some tests a couple years ago, on ActiveRecord 3.0.pre, and its 20x slower to initialize empty objects (no database access) than DataMapper, or just making empty Ruby objects & hashes.

https://gist.github.com/260280

Edit: Ran it with AR 3.0.7 and 3.1.0.rc4. Granted, this is with a 2-years newer CPU, but 3.0.7 is a huge step up. 3.1 seems to have regressed again, I'll ping tenderlove about it when I see him.

https://gist.github.com/fabfaf1bd8503fbf6d32

Re: What’s Up With All These Changes in Rails?

#22

Post by Jd »

There's a deeper problem that Yehuda isn't hitting and that is that there is an inverse correlation between being cool and cutting edge and being consumer friendly.

Rails is, and really has always been, a framework which changes very quickly. Although virtually all of these changes are for the better either in some abstract feels-better sense or in a tangible practical sense, each of these changes imposes a cost on other people.

This isn't really a problem with the decisions of the rails core team, it is the entire ethos accompanying rails. Authentication plugins I remember from 4 years ago are barely maintained today, and there are a whole bunch of new ones. I'm guessing my knowledge re: authentication has a half-life of approximately 1.5 years.

The implications are as follows:

(1) If you are a Rails developer you need to be a full-time Rails developer and not do too much else. You can't do Rails and a bunch of other things because Rails will take up a lot of your time.

(2) Think you can code, release, and forget about it? Think again. If you have projects, you (and the people who commissioned the projects) need to know that these projects need to have at least 5 hrs / week budgeted for the indefinite future (perhaps less, but the point is that they need a developer on staff -- they can't simply be released and forgotten about).

(3) Extra caution, since not all change is good change. You may end up to subject whatever is cool at the time. That's not to say that this really affects the core team, but there are a gazillion Rubyists out there attempting to change everything over to MongoDB that works just fine in whatever flavor of SQL they were running before. A lot of people have been burned here.

All of these take away from the promise and excitement of Rails for many people -- which was not simply "oh we can be on the cutting edge of technology," but "oh, we can have a sexy app with decent functionality up in a matter of a couple weeks with half the budget of what we thought." That second impression, which is what a lot of the Rails ecosystem is built off of, is largely false (esp. now that there are a bunch of other quickstart web frameworks).

Re: What’s Up With All These Changes in Rails?

#23

Post by thenduks »

SeanDav wrote: post #16
tjogin wrote: post #12

I'm so impressed with Yehuda's ability to be both persuasive and calm while completely destroying every aspect of the argument he is refuting.

Agree that Yehuda is calm and makes good points - However the main point of the original article still remains intact - Rails is very hard for the beginner to learn, much harder than before.

If you recall back in the Rails 1.x days, it wasn't exactly pleasant to learn -- if only because of the awful documentation.

Point being, Rails' first priority is to improve developers' productivity, sanity and happiness - all developers using it, not just new ones.

Re: What’s Up With All These Changes in Rails?

#24

Post by brunomiranda »

erikpukinskis wrote: post #11

I kind of wish they would go further. While I prefer Rspec, I understand and sympathize with those who feel Test::Unit is a better default. But HAML feels like such a vast, unambiguous, never-going-back improvement over ERB that I am honestly baffled Rails hasn't adopted it. It's at least as big a win as Sass and CoffeeScript, if not bigger. I agree with Katz here. If anything, Rails has shown remarkable restraint in…

HAML has not been adopted because DHH does not like it.

Re: What’s Up With All These Changes in Rails?

#25

Post by brunomiranda »

SeanDav wrote: post #16
tjogin wrote: post #12

I'm so impressed with Yehuda's ability to be both persuasive and calm while completely destroying every aspect of the argument he is refuting.

Agree that Yehuda is calm and makes good points - However the main point of the original article still remains intact - Rails is very hard for the beginner to learn, much harder than before.

Programming is really not supposed to be super easy. When someone is able to start "programming websites" in a couple hours using Rails things get dirty, ala 2007-08 when Rails started getting a bad reputation for amateurish/slow/buggy applications.

Re: What’s Up With All These Changes in Rails?

#26

Post by msbarnett »

erikpukinskis wrote: post #11

I kind of wish they would go further. While I prefer Rspec, I understand and sympathize with those who feel Test::Unit is a better default. But HAML feels like such a vast, unambiguous, never-going-back improvement over ERB that I am honestly baffled Rails hasn't adopted it. It's at least as big a win as Sass and CoffeeScript, if not bigger. I agree with Katz here. If anything, Rails has shown remarkable restraint in…

To me, the pain-point with HAML has always been that it's much harder to teach our front end designers to use it instead of HTML, whereas Sass presented much less of a barrier for them vs Javascript.

HAML feels great for me as a dev vs the verbosity of hand-hacking HTML, but for the guys who spend 90% of their time in photoshop and 10% chopping their PSDs into static HTML to hand to me, I'm not convinced it's worth the lost productivity to teach them a new markup.

Re: What’s Up With All These Changes in Rails?

#27

Post by 1337p337 »

erikpukinskis wrote: post #11

I kind of wish they would go further. While I prefer Rspec, I understand and sympathize with those who feel Test::Unit is a better default. But HAML feels like such a vast, unambiguous, never-going-back improvement over ERB that I am honestly baffled Rails hasn't adopted it. It's at least as big a win as Sass and CoffeeScript, if not bigger. I agree with Katz here. If anything, Rails has shown remarkable restraint in…

I agree that it's much nicer than ERB for HTML, but I still use ERB for, e.g., config file generation.

HAML, though, shares the same fundamental problem with ERB: it's straddling the code/template fence. I wrote the Hoshi ( http://github.com/pete/hoshi ) gem to address this, and used it in the last Rails application I wrote (still in production), and still use it for HTML when I need that. (It's still in the "personal itch" phase, so it's only maintained when I notice that W3C doesn't like something or when I'm missing a feature. For example, I haven't done any HTML5, so I haven't put any in.)

For anything requiring a wall of text (in HAML, ERB, Hoshi, whatever), I think it's a mistake to put it into your view code. Make a place where copy goes, decide on a markdown format, and write a helper that pulls in and processes that text. Even if the coders are writing the copy, it's helpful to have the text seperate, and easier to edit besides. And if it turns out that you need the text editable via a web UI or something, it makes the change easier: modify the helper to fetch text by name from the database rather than the filesystem, and import all of the text into the database. Everything is easier all around; I'm at the point where it looks like a code smell when I see walls of text (or frequently edited text) in a template.

Re: What’s Up With All These Changes in Rails?

#28

Post by [deleted] »

brunomiranda wrote: post #24
erikpukinskis wrote: post #11

I kind of wish they would go further. While I prefer Rspec, I understand and sympathize with those who feel Test::Unit is a better default. But HAML feels like such a vast, unambiguous, never-going-back improvement over ERB that I am honestly baffled Rails hasn't adopted it. It's at least as big a win as Sass and CoffeeScript, if not bigger. I agree with Katz here. If anything, Rails has shown remarkable restraint in…

HAML has not been adopted because DHH does not like it.

[deleted]

Re: What’s Up With All These Changes in Rails?

#29

Post by wycats »

psadauskas wrote: post #21
euroclydon wrote: post #15

Earlier quoted context omitted.

Wow! This is the first I've heard that RoR's ORM is slow. That's it's slow because Ruby is slow, is even more of a shocker. I'd love to hear some practical limitations that applications using Ruby and NHibernate face when querying data. Is this slowness a reason that so many no-sql engines seemed to have sprung at the same time as RoR?

It is embarrassingly slow. I did some tests a couple years ago, on ActiveRecord 3.0.pre, and its 20x slower to initialize empty objects (no database access) than DataMapper, or just making empty Ruby objects & hashes. https://gist.github.com/260280 Edit: Ran it with AR 3.0.7 and 3.1.0.rc4. Granted, this is with a 2-years newer CPU, but 3.0.7 is a huge step up. 3.1 seems to have regressed again, I'll ping tenderlove a…

Benchmarks on ActiveRecord before the work Aaron did on Arel (which was dropped in in 3.0.x due to the magnitude of the perfect issue/improvement) are not totally relevant today.

There are still some issues, but there is still low-hanging-fruit as well, such as Aaron's work to add prepare statement caching to Rails 3.1

Re: What’s Up With All These Changes in Rails?

#30

Post by chollida1 »

Jd wrote: post #22

There's a deeper problem that Yehuda isn't hitting and that is that there is an inverse correlation between being cool and cutting edge and being consumer friendly. Rails is, and really has always been, a framework which changes very quickly. Although virtually all of these changes are for the better either in some abstract feels-better sense or in a tangible practical sense, each of these changes imposes a cost on o…

> (1) If you are a Rails developer you need to be a full-time Rails developer and not do too much else. You can't do Rails and a bunch of other things because Rails will take up a lot of your time.

I'm glad to see someone else say this. I don't use rails often, nor am I a "front end" developer by trade.

I have put together some simple web apps using rails, but it seems that each time I go back to rails and try to use the newest released version I'm starting back close to square 1 due to how things always seem to change.

I always just assumed that I didn't grok web frameworks, though this is still a possibility.

Post reply on HN