20 ms·

What’s Up With All These Changes in Rails?

353 points by jcorcuera 15y ago

stephth 15y ago
I feel like this discussion wouldn't be getting so much traction if it was easier to learn the differences between specific versions. Today there's enough resources out there to learn about rails and/or the differences between versions and/or 'the right way' of doing things, but it's scavenger hunt meets jigsaw puzzle. Currently, if you don't follow the Rails evolution regularly, going out there and catch up with it can be intimidating for some. There's a need for a central Rails reference that makes this task trivial. Maybe a document with some sort of interactive diff functionality that allows to see specific version differences side by side in a friendly manner. Some system that doesn't force the writers to re-think a full document for every version, that can evolve without erasing older information, and that assists the reader by showing specific chunks of information that she should read in order to catch up to the specific version she is aiming for. Getting this started is a non-trivial task, but it seems like there's enough energy, innovation and attention to detail surrounding Rails to solve this problem.
- acangiano 15y ago
  http://apidock.com/rails http://apidock.com/rails has compatibility information for Rails versions. Not quite what you'd like but definitely helpful.
- wwkeyboard 15y ago
  I think part of this problem comes from the number of blog posts that don't reference versions when explaining something. This adds to confusion if the topic has changed and the post is not updated/marked out of date.
- bonaldi 15y ago
  I abandoned Rails years back because of precisely this problem. Releases would break or arbitrarily drop functionality, with little or no documentation. If you got more than a few point releases behind you were really screwed. I couldn't explain the dearth of documentation for these changes at all, it seemed so lax compared to other platforms. Then I realised all the incentives for those who would produce the documents were towards producing books and paid-for screencasts, and knew my time was up.
  - bcardarella 15y ago
    Prior to Rails 3 Rails' versioning scheme left a lot to be desired. However, starting with Rails 3 it is supposed to be following Semantic Versioning. (http://semver.org http://semver.org) This should help with giving people an idea if they can update without fear their app will break.
  - deleted 15y ago
    [deleted]
ry0ohki 15y ago
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.
- bad_user 15y ago
  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 path for building UI, the Microsoft recommended way? The Win16 API? The Win32 API? MFC? WTL? Windows Forms? WPF? Silverlight? HTML5? Evolution happens, you need to deal with it. The only stable API I know that is still relevant and still important to learn (instead of an abstraction) is POSIX-stuff.
  - ry0ohki 15y ago
    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).
    - bad_user 15y ago
      Yeah, but ASP.NET sucks. Don't get me wrong, it was great in 2001 when it was released, but the Viewstate/Postback model really sucks judging by modern standards and it was a really bad idea when viewed in perspective. And ASP.NET MVC is different and whatever compatibility it has with ASP.NET is actually hurting, IMHO. I mean, here's a framework with potential, but it has to carry the old bagage of ASP.NET from the start. I get it that a framework like Rails moves TOO FAST for its own good, but nothing compels you to upgrade right now. Lots of people are still on Rails 2.3, it's a stable and reliable version and if you'll look around many projects have 2 branches, one for 2.3 and one for 3.0. And some of the projects, especially Rack middleware, don't need 2 branches. It kind of sucks from one perspective - the 2.3 branches are going to receive less patches/upgrades, but you have the source code. If something really important is missing, or there's some unfixed bug, you can go ahead and fix it yourself. You can't say the same thing about a binary DLL. I remember when I first tried out ASP.NET 2.0 - it contained an annoying bug related to their CSRF protection (if you clicked any control before the page loaded, it triggered an error since the CSRF token was getting loaded right before the </form> tag, at the end of the page), and it took a service pack and 2 months to get it fixed.
honza 15y ago
You guys should switch to Django.
dasil003 15y ago
I believe that Rails does sacrifice something in terms of stability compared to other projects, but that is also what allows Rails to be a industry-leading framework 7 years in. If you are a developer stuck supporting a lot of old Rails 1.x and 2.x projects with no budget, then absolutely you will feel the pain of upgrading and marginal legacy support that you wouldn't necessarily feel had you gone with a more venerable Java stack (for instance). That said, if you are actively building an application over several years then the forward development of Rails means greater productivity and functionality on an ongoing basis rather than being stuck with an outdated framework. My current project is over 4 years old, started in the Rails 1.2 era, 100+ models, 30+ gems, 50k LOC, and I can vouch for the pain that the Rails 3 upgrade caused. That said, the upgrade gave us a lot of immediate benefits: the rails_xss upgrade forced us to close a number of small XSS holes that we probably never would have found otherwise, the Bundler upgrade solved several real-world deployment issues that led to downtime over the years, ActiveRecord 3 allowed us to clean up a ton of hairy querying code we had written with its fantastic composability and laziness, the modularity and instrumentation allowed massive logging and generator improvements to be inline with project standards, the ActionMailer API allowed us to significantly DRY up our extensive email notification suite. In short, Rails development is still definitely heading in the right direction for my organization. There's no doubt that API stability is better in many other frameworks, but as Yehuda points out here, the changes made in Rails are done for good reason that can benefit a lot of people. If stability is more important than agility for your project (without disparagement), then Rails is probably the wrong choice (I tend to use PHP in those cases).
erikpukinskis 15y ago
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 the face of a smorgasbord of shiny, new, and often superior, competing technologies.
- mhartl 15y ago
  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-for-content/ 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.
  - erikpukinskis 15y ago
    I feel like if you've got lots of text and embedded code mixed together in a template there's probably something wrong with your architecture. For the few cases where that makes sense, ERb is great. But I have a hard time imagining it's common enough to make it the default. Edit: Also, the post you linked to outlines several simple ways to mix text into your HAML (inlining HTML, using markdown filters, etc)
  - bonzoesc 15y ago
    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.
    - mhartl 15y ago
      Sounds like a good solution. I'll have to try that out.
  - chriseppstein 15y ago
tjogin 15y ago
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.
- SeanDav 15y ago
  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.
  - thenduks 15y ago
    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.
    - 1337p337 15y ago
      Even before 1.x, Rails has been pretty easy to figure out, and looking at the old documentation, apparently well-documented. There were countless tutorial-style blog posts if the API docs weren't enough. The Ruby mailing list was inundated for a long time with talk about Rails, to the point that I had to make a filter. I'm not by any means a Rails fan, and think that even now, it feels like a PHP framework. (I have a "competing" web framework that I wrote and use whenever I have the flexibility, if you can call it a competitor; it's not actively promoted and the users number in the low single digits). But they do deserve credit for making sure that it's easy to figure out how to get things done.
  - brunomiranda 15y ago
    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.
  - 15y ago
ssmoot 15y ago
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 from an OO stand-point. It's the code I wished I could write in DM. I didn't use it (or something like it) in DM because I'd been there and seen the consequences. To give the point some context, you might expect NHibernate to impose a 10% overhead on c#. NHibernate is a very complex library, doing a lot more than most (any?) Ruby O/RM. In Ruby, once you get beyond the most trivial examples, you can easily see numbers like 50% overhead, and some queries that would be a cake-walk in .NET are impractical or even impossible in Ruby with constrained resources or service timeouts. Ruby method dispatch and object instantiation is slow. Damn slow. Ridiculously slow. The reason DM and now AR perform two-query-eager-loads to avoid JOINs has almost nothing to do with database performance. I doubt many Rubyists really understand or grok what that means. It has everything to do with the instantiation and even simple iteration of a cartesian product in Ruby being infeasibly slow. Getting back to Arel: It's probably the very best of Rails OO. But that it's introduced some very serious performance regressions is no surprise at all. I said as much to NK and Yehuda when we discussed it during DataMapper 0.9 development. With Ruby you have to make compromises. Especially in such a critical-loop portion of your stack. On the other hand, if you're going to stay with AR, then it probably needed to happen sooner or later. Best of all worlds would have been to drop AR altogether and promote a migration to Sequel for the official Rails O/RM. ;-)
- euroclydon 15y ago
  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?
  - psadauskas 15y ago
    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 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 https://gist.github.com/fabfaf1bd8503fbf6d32
trustfundbaby 15y ago
I appreciate the post and am a huge fan of Yehuda, he used my comments as teeing off points for your remarks but I feel that what I was trying to say has been lost in his response, probably because I was unclear. Lets start with this ... "The Rails core team does seem to treat the project as if it’s a personal playground" This was said more in frustration with the coffeescript/sass decision than any real belief that it really was the case. I understand it may be hurtful and disparaging of the amazing effort that the Rails core team has dedicated to making Rails fantastic, and I apologize unreservedly. With respect to outlining the changes (prototype to jquery etc), I'm not complaining about the changes per se (because I like most of them), what I'm complaining about is the pace of the changes. Something as major as the asset pipelining feature (where you move assets out of the public folder and into the app folder), for example, seems big enough that it should be a 3.2 release not the next release after an already major change in 3.0. See what I'm saying? I haven't worked on the Rails core, so this can be taken with a pinch of salt, but I feel like it would be a good idea to adopt the Intel tick tock refresh style of cpu releases http://en.wikipedia.org/wiki/Intel_Tick-Tock http://en.wikipedia.org/wiki/Intel_Tick-Tock, where major releases come out on the 'tock' and are refined on the 'tick'. That would work well for Rails releases, giving major releases enough time to settle into the Rails consciousness before the next set of changes comes down. It was great to get a thorough explanation of the rationalization behind the decisions that have been made recently, it would be awesome to see that increase in frequency. I just want to thank the Rails team for all the hard work and have them understand that while I may argue hard for what I believe, that I have nothing but the highest regard for them.
- ayb 15y ago
  >> Something as major as the asset pipelining feature (where you move assets out of the public folder and into the app folder), for example, seems big enough that it should be a 3.2 release not the next release after an already major change in 3.0. What's the difference between putting it in 3.1 vs. 3.2? Is the 3.2 version number somehow more substantial than 3.1? Also there have been quite a few releases after 3.0 - I believe the 3.0 branch is up to 3.0.8 now.
  - 15y ago
deleted 15y ago
[deleted]
Jd 15y ago
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).
- chollida1 15y ago
  > (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.
jmtame 15y ago
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.
kingkilr 15y ago
> Ruby core (“MRI”) itself has sunk an enormous amount of time into performance improvements in Ruby 1.9, going so far as to completely rewrite the core VM from scratch. This isn't particularly accurate, my understanding is that what became the 1.9 VM was originally an external fork (or rewrite, I'm not clear on which) known as YARV, which was later integrated, but was not originally developed by the MRI team. As always feel free to tell me I'm a moron who has no idea what he's talking about.
- wycats 15y ago
  YARV was an external fork that was integrated into MRI pretty early, and then worked on by the core team for several years. My point was simply that YARV's existence and the commitment of the core team to get it into core (and the resulting performance improvements) disprove the idea that the Ruby core team doesn't care about performance.
kreek 15y ago
Coming from PHP Rails was a great way for me to learn best practices and get disciplined. Now that I have a good foundation I find myself using Sinatra plus whatever gems fit my small to medium projects. So it might not be that Rails is too heavy, it could be that some of these projects don't require the learning curve of Rails to be successful.
mmaunder 15y ago
Rails seems to be focused on it's own navel. It's written by developers to solve problems developers perceive they have. The platform rewards new layers of abstraction within the community - and those layers really exist to enforce a discipline which may not be needed and becomes restrictive if you don't want to do things the Rails way. From my perspective as a serial startup founder, I won't touch the platform because startups must innovate or die and to enforce too much discipline on the way things are done within a platform is to risk killing innovation. The best startups not only use platforms in unexpected ways, but are platform agnostic and use multiple platforms that probably didn't expect to have to talk to each other. Startups choosing Rails need to remember that 37Signals have a group of mature apps that are maintaining and incrementally improving with (I'm guessing) growing team of devs. Their apps are also B2B and have relatively low traffic compared to many consumer focused startups. Their focus is code and team scaleability. They aren't rapidly prototyping or rapidly innovating. Also as the center of the Rails community, they don't need to care that Ruby devs are harder to come by than PHP or more mainstream languages. Rails also strikes me as a rockstar dev culture that puts marketing, innovation and being perceived as a thought leader ahead of everything else, including the boring crap like productivity, simplicity and performance: http://www.flickr.com/photos/46457493@N00/4441909186/in/set-72157594262577872/ http://www.flickr.com/photos/46457493@N00/4441909186/in/set-...
- tjogin 15y ago
  You seem to be very unfamiliar with Rails and the Rails community.
ryan-allen 15y ago
We have always been at war with Eurasia!
sams99 15y ago
What surprises me is that lack of backlash for the shoddy upgrade process... Moving from Rails 2 to Rails 3 is a nightmare, a documented nightmare in 3 parts http://goo.gl/2Xw7n http://goo.gl/2Xw7n Sure you can get part of the way by porting to bundler and upgrading to ruby 1.9.2, but there is no plugin or way to have an app work with both Rails 2 and Rails 3 at the same time. And this is a year after it was released with 3.1 just around the corner. For the upgrade you need to change boot.rb, application.rb your routes and all your other configuration. Potentially you may need to update a ton of views to allow for the xss protection. By themselves none of the changes in Rails 3 are bad, its just that somehow they managed to make it very very hard to upgrade, so less people use it, and it gets less testing and stuff regresses. I think if the team focused on a bridge / integrated upgrade path for rails 2 that allows you to switch to rails 3 seamlessly it would do wonders for adoption.

353 points by jcorcuera 15y ago

I feel like this discussion wouldn't be getting so much traction if it was easier to learn the differences between specific versions. Today there's enough resources out there to learn about rails and/or the differences between versions and/or 'the right way' of doing things, but it's scavenger hunt meets jigsaw puzzle. Currently, if you don't follow the Rails evolution regularly, going out there and catch up with it can be intimidating for some. There's a need for a central Rails reference that makes this task trivial. Maybe a document with some sort of interactive diff functionality that allows to see specific version differences side by side in a friendly manner. Some system that doesn't force the writers to re-think a full document for every version, that can evolve without erasing older information, and that assists the reader by showing specific chunks of information that she should read in order to catch up to the specific version she is aiming for. Getting this started is a non-trivial task, but it seems like there's enough energy, innovation and attention to detail surrounding Rails to solve this problem.

acangiano 15y ago
http://apidock.com/rails http://apidock.com/rails has compatibility information for Rails versions. Not quite what you'd like but definitely helpful.
wwkeyboard 15y ago
I think part of this problem comes from the number of blog posts that don't reference versions when explaining something. This adds to confusion if the topic has changed and the post is not updated/marked out of date.
bonaldi 15y ago
I abandoned Rails years back because of precisely this problem. Releases would break or arbitrarily drop functionality, with little or no documentation. If you got more than a few point releases behind you were really screwed. I couldn't explain the dearth of documentation for these changes at all, it seemed so lax compared to other platforms. Then I realised all the incentives for those who would produce the documents were towards producing books and paid-for screencasts, and knew my time was up.
- bcardarella 15y ago
  Prior to Rails 3 Rails' versioning scheme left a lot to be desired. However, starting with Rails 3 it is supposed to be following Semantic Versioning. (http://semver.org http://semver.org) This should help with giving people an idea if they can update without fear their app will break.
- deleted 15y ago
  [deleted]

ry0ohki 15y ago

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.

bad_user 15y ago
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 path for building UI, the Microsoft recommended way? The Win16 API? The Win32 API? MFC? WTL? Windows Forms? WPF? Silverlight? HTML5? Evolution happens, you need to deal with it. The only stable API I know that is still relevant and still important to learn (instead of an abstraction) is POSIX-stuff.
- ry0ohki 15y ago
  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).
  - bad_user 15y ago
    Yeah, but ASP.NET sucks. Don't get me wrong, it was great in 2001 when it was released, but the Viewstate/Postback model really sucks judging by modern standards and it was a really bad idea when viewed in perspective. And ASP.NET MVC is different and whatever compatibility it has with ASP.NET is actually hurting, IMHO. I mean, here's a framework with potential, but it has to carry the old bagage of ASP.NET from the start. I get it that a framework like Rails moves TOO FAST for its own good, but nothing compels you to upgrade right now. Lots of people are still on Rails 2.3, it's a stable and reliable version and if you'll look around many projects have 2 branches, one for 2.3 and one for 3.0. And some of the projects, especially Rack middleware, don't need 2 branches. It kind of sucks from one perspective - the 2.3 branches are going to receive less patches/upgrades, but you have the source code. If something really important is missing, or there's some unfixed bug, you can go ahead and fix it yourself. You can't say the same thing about a binary DLL. I remember when I first tried out ASP.NET 2.0 - it contained an annoying bug related to their CSRF protection (if you clicked any control before the page loaded, it triggered an error since the CSRF token was getting loaded right before the </form> tag, at the end of the page), and it took a service pack and 2 months to get it fixed.

honza 15y ago

You guys should switch to Django.

dasil003 15y ago

I believe that Rails does sacrifice something in terms of stability compared to other projects, but that is also what allows Rails to be a industry-leading framework 7 years in. If you are a developer stuck supporting a lot of old Rails 1.x and 2.x projects with no budget, then absolutely you will feel the pain of upgrading and marginal legacy support that you wouldn't necessarily feel had you gone with a more venerable Java stack (for instance). That said, if you are actively building an application over several years then the forward development of Rails means greater productivity and functionality on an ongoing basis rather than being stuck with an outdated framework. My current project is over 4 years old, started in the Rails 1.2 era, 100+ models, 30+ gems, 50k LOC, and I can vouch for the pain that the Rails 3 upgrade caused. That said, the upgrade gave us a lot of immediate benefits: the rails_xss upgrade forced us to close a number of small XSS holes that we probably never would have found otherwise, the Bundler upgrade solved several real-world deployment issues that led to downtime over the years, ActiveRecord 3 allowed us to clean up a ton of hairy querying code we had written with its fantastic composability and laziness, the modularity and instrumentation allowed massive logging and generator improvements to be inline with project standards, the ActionMailer API allowed us to significantly DRY up our extensive email notification suite. In short, Rails development is still definitely heading in the right direction for my organization. There's no doubt that API stability is better in many other frameworks, but as Yehuda points out here, the changes made in Rails are done for good reason that can benefit a lot of people. If stability is more important than agility for your project (without disparagement), then Rails is probably the wrong choice (I tend to use PHP in those cases).

erikpukinskis 15y ago

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 the face of a smorgasbord of shiny, new, and often superior, competing technologies.

mhartl 15y ago
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-for-content/ 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.
- erikpukinskis 15y ago
  I feel like if you've got lots of text and embedded code mixed together in a template there's probably something wrong with your architecture. For the few cases where that makes sense, ERb is great. But I have a hard time imagining it's common enough to make it the default. Edit: Also, the post you linked to outlines several simple ways to mix text into your HAML (inlining HTML, using markdown filters, etc)
- bonzoesc 15y ago
  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.
  - mhartl 15y ago
    Sounds like a good solution. I'll have to try that out.
- chriseppstein 15y ago

tjogin 15y ago

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.

SeanDav 15y ago
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.
- thenduks 15y ago
  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.
  - 1337p337 15y ago
    Even before 1.x, Rails has been pretty easy to figure out, and looking at the old documentation, apparently well-documented. There were countless tutorial-style blog posts if the API docs weren't enough. The Ruby mailing list was inundated for a long time with talk about Rails, to the point that I had to make a filter. I'm not by any means a Rails fan, and think that even now, it feels like a PHP framework. (I have a "competing" web framework that I wrote and use whenever I have the flexibility, if you can call it a competitor; it's not actively promoted and the users number in the low single digits). But they do deserve credit for making sure that it's easy to figure out how to get things done.
- brunomiranda 15y ago
  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.
- 15y ago

ssmoot 15y ago

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 from an OO stand-point. It's the code I wished I could write in DM. I didn't use it (or something like it) in DM because I'd been there and seen the consequences. To give the point some context, you might expect NHibernate to impose a 10% overhead on c#. NHibernate is a very complex library, doing a lot more than most (any?) Ruby O/RM. In Ruby, once you get beyond the most trivial examples, you can easily see numbers like 50% overhead, and some queries that would be a cake-walk in .NET are impractical or even impossible in Ruby with constrained resources or service timeouts. Ruby method dispatch and object instantiation is slow. Damn slow. Ridiculously slow. The reason DM and now AR perform two-query-eager-loads to avoid JOINs has almost nothing to do with database performance. I doubt many Rubyists really understand or grok what that means. It has everything to do with the instantiation and even simple iteration of a cartesian product in Ruby being infeasibly slow. Getting back to Arel: It's probably the very best of Rails OO. But that it's introduced some very serious performance regressions is no surprise at all. I said as much to NK and Yehuda when we discussed it during DataMapper 0.9 development. With Ruby you have to make compromises. Especially in such a critical-loop portion of your stack. On the other hand, if you're going to stay with AR, then it probably needed to happen sooner or later. Best of all worlds would have been to drop AR altogether and promote a migration to Sequel for the official Rails O/RM. ;-)

euroclydon 15y ago
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?
- psadauskas 15y ago
  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 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 https://gist.github.com/fabfaf1bd8503fbf6d32

trustfundbaby 15y ago

I appreciate the post and am a huge fan of Yehuda, he used my comments as teeing off points for your remarks but I feel that what I was trying to say has been lost in his response, probably because I was unclear. Lets start with this ... "The Rails core team does seem to treat the project as if it’s a personal playground" This was said more in frustration with the coffeescript/sass decision than any real belief that it really was the case. I understand it may be hurtful and disparaging of the amazing effort that the Rails core team has dedicated to making Rails fantastic, and I apologize unreservedly. With respect to outlining the changes (prototype to jquery etc), I'm not complaining about the changes per se (because I like most of them), what I'm complaining about is the pace of the changes. Something as major as the asset pipelining feature (where you move assets out of the public folder and into the app folder), for example, seems big enough that it should be a 3.2 release not the next release after an already major change in 3.0. See what I'm saying? I haven't worked on the Rails core, so this can be taken with a pinch of salt, but I feel like it would be a good idea to adopt the Intel tick tock refresh style of cpu releases http://en.wikipedia.org/wiki/Intel_Tick-Tock http://en.wikipedia.org/wiki/Intel_Tick-Tock, where major releases come out on the 'tock' and are refined on the 'tick'. That would work well for Rails releases, giving major releases enough time to settle into the Rails consciousness before the next set of changes comes down. It was great to get a thorough explanation of the rationalization behind the decisions that have been made recently, it would be awesome to see that increase in frequency. I just want to thank the Rails team for all the hard work and have them understand that while I may argue hard for what I believe, that I have nothing but the highest regard for them.

ayb 15y ago
>> Something as major as the asset pipelining feature (where you move assets out of the public folder and into the app folder), for example, seems big enough that it should be a 3.2 release not the next release after an already major change in 3.0. What's the difference between putting it in 3.1 vs. 3.2? Is the 3.2 version number somehow more substantial than 3.1? Also there have been quite a few releases after 3.0 - I believe the 3.0 branch is up to 3.0.8 now.
- 15y ago

deleted 15y ago

[deleted]

Jd 15y ago

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).

chollida1 15y ago
> (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.

jmtame 15y ago

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.

kingkilr 15y ago

> Ruby core (“MRI”) itself has sunk an enormous amount of time into performance improvements in Ruby 1.9, going so far as to completely rewrite the core VM from scratch. This isn't particularly accurate, my understanding is that what became the 1.9 VM was originally an external fork (or rewrite, I'm not clear on which) known as YARV, which was later integrated, but was not originally developed by the MRI team. As always feel free to tell me I'm a moron who has no idea what he's talking about.

wycats 15y ago
YARV was an external fork that was integrated into MRI pretty early, and then worked on by the core team for several years. My point was simply that YARV's existence and the commitment of the core team to get it into core (and the resulting performance improvements) disprove the idea that the Ruby core team doesn't care about performance.

kreek 15y ago

Coming from PHP Rails was a great way for me to learn best practices and get disciplined. Now that I have a good foundation I find myself using Sinatra plus whatever gems fit my small to medium projects. So it might not be that Rails is too heavy, it could be that some of these projects don't require the learning curve of Rails to be successful.

mmaunder 15y ago

Rails seems to be focused on it's own navel. It's written by developers to solve problems developers perceive they have. The platform rewards new layers of abstraction within the community - and those layers really exist to enforce a discipline which may not be needed and becomes restrictive if you don't want to do things the Rails way. From my perspective as a serial startup founder, I won't touch the platform because startups must innovate or die and to enforce too much discipline on the way things are done within a platform is to risk killing innovation. The best startups not only use platforms in unexpected ways, but are platform agnostic and use multiple platforms that probably didn't expect to have to talk to each other. Startups choosing Rails need to remember that 37Signals have a group of mature apps that are maintaining and incrementally improving with (I'm guessing) growing team of devs. Their apps are also B2B and have relatively low traffic compared to many consumer focused startups. Their focus is code and team scaleability. They aren't rapidly prototyping or rapidly innovating. Also as the center of the Rails community, they don't need to care that Ruby devs are harder to come by than PHP or more mainstream languages. Rails also strikes me as a rockstar dev culture that puts marketing, innovation and being perceived as a thought leader ahead of everything else, including the boring crap like productivity, simplicity and performance: http://www.flickr.com/photos/46457493@N00/4441909186/in/set-72157594262577872/ http://www.flickr.com/photos/46457493@N00/4441909186/in/set-...

tjogin 15y ago
You seem to be very unfamiliar with Rails and the Rails community.

ryan-allen 15y ago

We have always been at war with Eurasia!

sams99 15y ago

What surprises me is that lack of backlash for the shoddy upgrade process... Moving from Rails 2 to Rails 3 is a nightmare, a documented nightmare in 3 parts http://goo.gl/2Xw7n http://goo.gl/2Xw7n Sure you can get part of the way by porting to bundler and upgrading to ruby 1.9.2, but there is no plugin or way to have an app work with both Rails 2 and Rails 3 at the same time. And this is a year after it was released with 3.1 just around the corner. For the upgrade you need to change boot.rb, application.rb your routes and all your other configuration. Potentially you may need to update a ton of views to allow for the xss protection. By themselves none of the changes in Rails 3 are bad, its just that somehow they managed to make it very very hard to upgrade, so less people use it, and it gets less testing and stuff regresses. I think if the team focused on a bridge / integrated upgrade path for rails 2 that allows you to switch to rails 3 seamlessly it would do wonders for adoption.