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

31–40 of 115 posts

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

#31

Post by jmtame »

Thanks Yehuda--you had quoted me on the asset pipeline and I have since upgraded to Cedar on Heroku. I suppose the slow loading of images in the asset pipeline was the biggest gripe on my part, but didn't realize images should still be served through /public. I would say that I am still hesitant to deploy apps using release candidates, but overall think the Rails team does a great job on the upgrades. Maybe more emphasis on documentation, but understandably it's a release candidate.

Also, DHH chimed in and offered some awesome advice that I didn't know about:

rake assets:precompile will automatically copy images from app/assets/images to public/assets.

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

#32

Post by Jd »

chollida1 wrote: post #30
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…

There is a huge learning curve with Rails, insofar as it is its own "opinionated" framework with numerous conventions, if well-chosen, that are unique to Rails. You can deploy web apps in Rails without adopting all of these things, but you will never be respected by Rails developers (I've heard devs say "that's not the Rails way" countless times). Usually these conventions are chosen for good reasons (even though they frequently change), but impose a significant cost since you have to learn:

(1) Ruby the language

(2) Idiomatic Ruby as perceived by Rails Devs

(3) Rails conventions

(4) Appropriate plugins/addons

All of them take a decent amount of time to learn (well). 3 & 4 also change pretty frequently.

So, it is possible you "grok" everything quite well (I'd guess that you do), but haven't learned all the specifics that make things tick the "Rails way."

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

#34

Post by sebilasse »

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…

You can have your sexy app up in a couple of weeks. But maintaining it still takes time, no matter what language/framework you're using. Upgrading to a new version is in the end maintenance (security fixes, underlying framework improvements, and the refactorings that go hand in hand with upgrading).

If you go with rails you still can get to a point very quick, with the downside that you have to spend time for upgrading. But both the elegance and maturity of rails 3, in regard of it's age is quite unique. The older it gets the prettier.

[2]. Agreed. I've been working both on client projects and in startups. If you have 10 Rails projects from clients to support, this is a nightmare, (rails 1.2 - 3.0, from mongrels to passengers). It's hard to charge clients for a rails upgrade.

[3] I developed rails since 0.14 full-time. I think rails was/is very conservative regarding trendy things (except coffeescript).

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

#35

Post by freshfunk »

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…

Glad to hear your opinion on this.

What frameworks, in your opinion, are stable, relevant today, easy to use, and has a good community?

I've been doing some client-side scripting with Ruby lately just for fun and I've also played with Python in the past. I haven't used Rails or Django. After reading all of this, I'm leaning towards Python/Django but haven't used neither web framework I'm curious as to people's opinions.

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

#36

Post by jshen »

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.

"Rails is very hard for the beginner to learn"

compared to what? Have you tried to learn Spring MVC? No way rails is harder to learn than that. Are you comparing it to no-framework php files?

Forgive me, but I fail to see how the main point of the original article is even valid.

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

#37

Post by freshfunk »

sebilasse wrote: post #34
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…

You can have your sexy app up in a couple of weeks. But maintaining it still takes time, no matter what language/framework you're using. Upgrading to a new version is in the end maintenance (security fixes, underlying framework improvements, and the refactorings that go hand in hand with upgrading). If you go with rails you still can get to a point very quick, with the downside that you have to spend time for upgradi…

>But maintaining it still takes time, no matter what language/framework you're using. Upgrading to a new version is in the end maintenance (security fixes, underlying framework improvements, and the refactorings that go hand in hand with upgrading).

Pointing out the obvious here but using matured languages/frameworks tends to have less of this problem.

It's like dating: stable -> boring and reliable while dynamically changing -> exciting but scary.

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

#38

Post by gaius »

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…

Of course the ORM is slow! Is there anyone in 2011 who doesn't know this? Why not bite the bullet and learn SQL? Your DBA will thank you.

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

#39

Post by bonzoesc »

mhartl wrote: post #14
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 is great for many cases, but it's terrible when the ratio of text to embedded code gets large. Chris Eppstein, one of the developers of Haml, made a blog post to this effect last year: http://chriseppstein.github.com/blog/2010/02/08/haml-sucks-f... As a result, though I love Haml, I think ERb is a more sensible default.

I think ERB ends up kind of ugly for prose too; adding rdiscount as a dependency and using the markdown filter in Haml is usually how I do it.

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

#40

Post by ry0ohki »

bad_user wrote: post #9
ry0ohki wrote: post #3

It seems like a tough line, and I sympathize with both sides. Either you can go the Microsoft route and be backwards compatible til the end of time (which is great for devs, but causes baggage) or you can embrace change while the community is still young(ish). It seems like at a minimum, everything in a major version should be backwards compatible (ie a 3.0 project will work in 3.1 without changes) though.

Either you can go the Microsoft route and be backwards compatible til the end of time You probably never went with Microsoft to say that. Yes, they are shipping the DLLs till the end of time, but you can also find the source code to Rails 2.3 till the end of time (it's right there, in your face), just as you can find the source code of Linux 0.01 (the initial release). On the other hand, what's the latest recommended…

Microsoft definitely has a lot of the "hey try this new thing" going on, but the key difference is I don't have to painfully upgrade all of my ASP.NET 2.0 applications when ASP.NET 3.0 or 3.5 comes out. Sure those support new features, but they are usually 99% compatible with the old versions (I believe they deprecate over two versions for the things that do change). Also if I look for code on the web, it's usually valid for any version (with the exception of LINQ).
Post reply on HN