Learning from Rails’ failures


Ruby on Rails undisputedly changed the way web frameworks are designed. Rails became a reference when it comes to leveraging conventions, easy baked in feature set and a rich ecosystem. However, I think that Rails did and still does a lot of things pretty poorly.  By writing this post, I’m not trying to denigrate Rails, there are many other people out there already doing that. My hope is that by listing what I think didn’t and still doesn’t go well, we can learn from our mistakes and improve existing solutions or create better new ones.

Migration/upgrades

Migrating a Rails App from a version to the other is very much like playing the lottery, you are almost sure you will lose. To be more correct, you know things will break, you just don’t know what, when and how. The Rails team seems to think that everybody is always running on the cutting edge version and don’t consider people who prefer to stay a few version behind for stability reasons. What’s worse is that plugins/gems might or might not compatible with the version you are updating to, but you will only know that by trying yourself and letting others try and report potential issues.

This is for me, by far, the biggest issue with Rails and something that should have been fixed a long time ago. If you’re using the WordPress blog engine, you know how easy and safe it is to upgrade the engine or the plugins. Granted WordPress isn’t a web dev framework, but it gives you an idea of what kind of experience we should be striving for.

 

Stability vs playground zone

New features are cool and they help make the platform more appealing to new comers. They also help shape the future of a framework. But from my perspective, that shouldn’t come to the cost of stability. Rails 3′s new asset pipeline is a good example of a half-baked solution shoved in a release at the last minute and creating a nightmare for a lot of us trying to upgrade. I know, I know, you can turn off the asset pipeline and it got better since it was first released. But shouldn’t that be the other way around? Shouldn’t fun new ideas risking the stability of an app or making migration harder, be off by default and turned on only by people wanting to experiment? When your framework is young, it’s normal that you move fast and sometimes break, but once it matures, these things shouldn’t happen.

 

Public/private/plugin APIs

This is more of a recommendation than anything else. When you write a framework in a very dynamic language like Ruby, people will “monkey patch” your code to inject features. Sometimes it is due to software design challenges, sometimes it’s because people don’t know better. However,  by not explicitly specifying what APIs are private (they can change at anytime, don’t touch), what APIs are public (stable, will be slowly deprecated when they need to be changed) and which ones are for plugin devs only (APIs meant for instrumentation, extension etc..), you are making migration to newer versions much harder. You see, if you have a small, clean public API, then it’s easy to see what could break, warn developers and avoid migration nightmares. However, you need to start doing that early on in your project, otherwise you will end up like Rails where all code can potentially change anytime.

 

Rails/Merb merge was a mistake

This is my personal opinion and well, feel free to disagree, nobody will ever be able to know to for sure. Without explaining what happened behind closed doors and the various personal motivations, looking at the end result, I agree with the group of people thinking that the merge didn’t turn up to be a good thing. For me, Rails 3 isn’t significantly better than Rails 2 and it took forever to be released. You still can’t really run a mini Rails stack like promised. I did hear that Strobe (company who was hiring Carl Lerche, Yehuda Katz and contracted Jose Valim) used to have an ActionPack based, mini stack but it was never released and apparently only Rails core members really knew what was going on there. Performance in vanilla Rails 3 are only now getting close to what you had with Rails 2 (and therefore far from the perf you were getting with Merb). Thread-safety is still OFF by default meaning that by default your app uses a giant lock only allowing a process to handle 1 request at a time. For me, the flexibility and performance focus of Merb were mainly lost in the merge with Rails. (Granted, some important things such as ActiveModel, cleaner internals and others have made their way into Rails 3)

But what’s worse than everything listed so far is that the lack of competition and the internal rewrites made Rails lose its headstart.  Rails is very much HTML/view focused, its primarily strength is to make server side views trivial and it does an amazing job at that. But let’s be honest, that’s not the future for web dev. The future is more and more logic pushed to run on the client side (in JS) and the server side being used as an API serving data for the view layer. I’m sorry but adding support for CoffeeScript doesn’t really do much to making Rails evolve ahead of what it currently is. Don’t get me wrong, I’m a big fan of CoffeeScript, that said I still find that Rails is far from being optimized to developer web APIs in Rails. You can certainly do it, but you are basically using a tool that wasn’t designed to write APIs and you pay the overhead for that. If there is one thing I wish Rails will get better at is to make writing pure web APIs better (thankfully there is Sinatra). But at the end of the day, I think that two projects with different philosophies and different approaches are really hard to merge, especially in the open source world. I wouldn’t go as far as saying like others that Rails lost its sexiness to node.js because of the wasted time, but I do think that things would have been better for all if that didn’t happen. However, I also have to admit that I’m not sure how much of a big deal that is. I prefer to leave the past behind, learn from my own mistake and move on.

 

Technical debts

Here I’d like to stop to give a huge props to Aaron “@tenderlove” Patterson, the man who’s actively working to reduce the technical debts in the Rails code base. This is a really hard job and definitely not a very glamorous one. He’s been working on various parts of Rails including its router and its ORM (ActiveRecord). Technical debts are unfortunately normal in most project, but sometimes they are overwhelming to the point that nobody dares touching the code base to clean it up. This is a hard problem, especially when projects move fast like Rails did. But looking back, I think that you want to start tackling technical debts on the side as you move on so you avoid getting to the point that you need a hero to come up and clean the piled errors made in the past. But don’t pause your entire project to clean things up otherwise you will lose market, momentum and excitement. I feel that this is also very much true for any legacy project you might pick up as a developer.

 

Keep the cost of entry level low

Getting started with Rails used to be easier. This can obviously argued since it’s very subjective, but from my perspective I think we forgot where we come from and we involuntary expect new comers to come with unrealistic knowledge. Sure, Rails does much more than it used to do, but it’s also much harder to get started. I’m not going to argue how harder  it is now or why we got there. Let’s just keep in mind that it is a critical thing that should always be re-evaluated. Sure, it’s harder when you have an open source project, but it’s also up to the leadership to show that they care and to encourage and mentor volunteers to  focus on this important part of a project.

 

Documentation

Rails documentation isn’t bad, but it’s far from being great. Documentation certainly isn’t one of the Ruby’s community strength, especially compared with the Python community, but what saddens me is to see the state of the official documentation which, should, in theory be the reference. Note that the Rails guides are usually well written and provide value, but they too often seem too light and not useful when you try to do something not totally basic (for instance use an ActiveModel compliant object). That’s probably why most people don’t refer to them or don’t spend too much time there. I’m not trying to blame anyone there. I think that the people who contributed theses guides did an amazing job, but if you want to build a strong and easy to access community, great documentation is key. Look at the Django documentation as a good example. That said, I also need to acknowledge the amazing job done by many community members such as Ryan Bates and Michael Hartl consistently providing high value external documentation via the railscasts and the intro to Rails tutorial available for free.

 

In conclusion, I think that there is a lot to learn from Rails, lots of great things as well as lots of things you would want to avoid. We can certainly argue on Hacker News or via comments about whether or not I’m right about Rails failures, my point will still be that the mentioned issues should be avoided in any projects, Rails here is just an example. Many of these issues are currently being addressed by the Rails team but wouldn’t it be great if new projects learn from older ones and avoid making the same mistakes? So what other mistakes do you think I forgot to mention and that one should be very careful of avoiding?

 

Updates:

  1. Rails 4 had an API centric app generator but it was quickly reverted and will live as gem until it’s mature enough.
  2. Rails 4 improved the ActiveModel API to be simpler to get started with. See this blog post for more info.

Similar Posts

, , , , , ,

  1. #1 by Nicolas Mérouze - February 29th, 2012 at 08:20

    I totally agree with you. But in my experience Rails developers with a few years of experience have a fear to switch to something else. Switching to another ORM is easy, change of the entire framework is hard.

    IMO Unless you have very complex applications, there’s nothing to miss from Rails that you can’t have through rubygems.

  2. #2 by Eleo - February 29th, 2012 at 08:24

    Does the Rails/Merb merge even really qualify as a merge? I feel like the outcome of that whole thing was Merb dying and Rails becoming slightly more Merblike while still largely remaining Rails. Where as Merb’s approach to modularity was to specify what you wanted your stack to be, Rails is all about removing what you don’t need. To make a trite analogy, Merb was ordering the pepperoni-sausage pizza I wanted, and Rails is getting a supreme pizza with everything imaginable on it and having to pick off all the toppings I don’t care for.

    I remain rather bitter about it because I really liked Merb. Luckily for me there’s still Padrino as a solid, lightweight, flexible alternative to Rails.

  3. #3 by David C - February 29th, 2012 at 08:45

    I couldn’t agree more on merb/rails merge. personally I am switching to padrino.

  4. #4 by hmans - February 29th, 2012 at 08:51

    Lost me when author started comparing upgrading a Rails app to upgrading a WordPress blog.

    • #5 by Terry Roe - March 1st, 2012 at 05:35

      hmans,

      You might want to go back and finish reading the paragraph where he was talking about WordPress. He ended it with this: “Granted WordPress isn’t a web dev framework, but it gives you an idea of what kind of experience we should be striving for.”

      There are a lot of great insights in this article that might be useful to you.

      TR

  5. #6 by James Britt - February 29th, 2012 at 08:51

    More options are better, but the voices pushing for a Rails monoculture eventually won. Hand-wringing about Rails is just time wasted; in the future, people need to be be careful what they wish for.

    On the bright side, Ramaze has always been, and continues to be, a solid, full-featured yet no-bloat framework, and what I turn to first when building Ruby web apps.

  6. #7 by hmans - February 29th, 2012 at 09:06

    Ramaze is great, for the right type of application.

    Sinatra is great, for the right type of application.

    Node.js is great, for the right type of application.

    Django is great, for the right type of application.

    Zope is great, for the right type of application. (Right?)

    Zend is great, for the right type of application.

    Twisted is great, for the right type of application.

    Rails is great, for the right type of application.

  7. #8 by Matt Aimonetti - February 29th, 2012 at 09:08

    Some great comments and suggestions available on HN: http://news.ycombinator.com/item?id=3648247

  8. #9 by Tomas Ordoñez - February 29th, 2012 at 09:23

    Hey Merbist,

    This article is very informative. I am a new programmer taking the Ruby on Rails class @CodeAcademy. Coming from a WordPress background. The WP framework is a good comparison. I think that people that make plugins are aware that the WP people want to keep on improving it. If they don’t update their plugins to be in compliance with the latest WP version. Then simply, people just install the plugin and look for a compatible one. If plugin people don’t keep up, they loose customers.

    As I am learning in Rails gems are the plugins. But I think the difference is that a lot of gems are available for free due to open source. And as far as I know (I don’t know much) not a lot of gems are funded ($$). Instead they are taken by whoever wants to work on them.

    Since gems don’t generate revenue for whoever is maintaining it, then there is not a serious commitment to make sure such gem complies with the latest versions of Ruby and Rails.

    I see a lot of people in my class struggling doing a tutorial. Because a lot of tutorials don’t mention which versions of ruby, rails and gems were used for it. So when they try to do one and they get stuck half way because a gem is not compatible they get discouraged. Fortunately we have a great community of mentors that are available to help us.

    About entry level. If it were not for Hartl’s tutorial it is pretty impossible for an entry level person to get into this. Everybody in my class adores this guy. There are a lot of books out there but nothing compares with Hartl with his easy way to explain in detail, step by step what to do. From creating an app to deploying it.

    I don’t see many people using the Rails guide simply because it doesn’t have a search box.

  9. #10 by Steve Klabnik - February 29th, 2012 at 09:44

    I’m glad that people are making these kinds of posts. We can only grow through critiquing ourselves.

    With that said, there’s a few things that I don’t agree with.

    I’ve never really had a huge problem upgrading my sites through various versions of Rails. I do tend to be the kind of person who either upgrades shortly after release, or _NEVER UPGRADES_. I do have a Rails 3.0.8 app in the wild, for example.

    I’m totally split on the asset pipeline. I really, really like it and how it works, but I do think that it shouldn’t have held up 3.1 for so long. I personally haven’t had many problems with it, but I think I develop apps the way that DHH does: 99.9% server side, with some JS sprinkled on top. If my apps tended toward heavier JS, I might find edge cases sooner.

    I thought that one of the big things with Rails 3 was declaring which APIs were public and which were private. Could be wrong.

    I know there was some shady stuff going on with the Merb/Rails merge, but I think that overall, it helped enable @tenderlove to start paying off that technical debt that’s so incredibly valuable. I could be totally making that up, though, that’s just my perception. It certainly hurt Rails to stand still for so long, but I’m not sure how to reconcile your dislike of the merge with your love of Aaron fixing things. They seem to be in the same category to me. Lots of the merge (at least from the outside) seemed to be paying off all kinds of accumulated technical debt.

    On entry-level people, I think I agree with DHH: http://news.ycombinator.com/item?id=3328427

    Documentation can always be improved, agree 100% there.

  10. #11 by Gregory Ostermayr - February 29th, 2012 at 10:30

    Rails may have a barrier to entry but it is no where near the level of aggravation ASP.Net pummels you with. The biggest barrier I’ve seen is initial setup and finding the right tutorial for the right version of rails.

    Similarly, having to stare at MSDN quite a bit the rails documentation seems like an absolute joy to me in comparison.

  11. #12 by Alice - February 29th, 2012 at 10:34

    A project should not have performance regressions between major or minor releases once it reaches 1.0. This is easy enough to enforce through the test suite.

    The Apache project had to slog through a similar tarpit when Apache 2.0 was released with a “better architecture” but slower performance for a majority of the real-world userbase. 2.2 was forced to restore some of the original implementation strategies from 1.x.

    Rails does not have any guiding principles except “what does David think is best?”. As his experience, needs, and opinions have changed over the years Rails has become increasingly incoherent.

  12. #13 by Richard Schneeman - February 29th, 2012 at 10:37

    Love the article, especially agree with the ‘getting started story’. Trading a verbose manual process for a difficult to memorize DSL isn’t always the way to go. I’ve been teaching Rails classes at UT and students take way too long to really to grok the subtleties of how to use different path’s in their views. Even then frequent trips to `rake routes` are necessary. I’m for adding helpful logging and comments to error messages to help out newcomers (https://github.com/rails/rails/issues/created_by/schneems?sort=created&direction=desc&state=closed&page=1) but as DHH pointed out if a framework doesn’t have great usability, those are just bandaids. I would love to see some interaction/service design research done on the usability of the framework.

  13. #14 by AstonJ - February 29th, 2012 at 10:49

    Hi Matt, you make some interesting points. Here’s what I think as a relative newcomer to both Ruby and Rails (but not to building large/busy websites).

    MIGRATION/UPGRADES & STABILITY VS PLAYGROUND ZONE.
    I appreciate what you’re saying and yes upgrading could be easier – but the benefit of the way Rails does it now, is that uptake is significantly higher, because it is practically pushed on you. I think I prefer this because it helps keep Rails cutting edge (one of the reasons I choose Rails over other frameworks). Maybe I’ll change my mind once I’ve got a few apps that need upgrading – then again maybe not, I’ve always preferred redoing things from scratch than upgrading/patching things anyway (with app-powered sites such as wordpress/vbulletin – I would redo the customisations from scratch for every major upgrade – but happy to patch minor updates).

    PUBLIC/PRIVATE/PLUGIN APIS.
    I don’t really have an opinion on this.

    RAILS/MERB MERGE WAS A MISTAKE.
    I remember when I first started researching web frameworks, the Merb and Rails split worried me – as I thought it would end up in two factions (two frameworks basically aiming for the same thing) and would split the community. So the merge did two things (for me anyway) showed me the community is united (and not affected by egos), and made me feel better about coming to Ruby (instead of going with a framework in another language).

    TECHNICAL DEBTS.
    Again I don’t really have an opinion on this being a relative newcomer – but I guess many people would disagree.

    KEEP THE COST OF ENTRY LEVEL LOW.
    This one I think I am qualified to comment on :D I didn’t choose Rails because it was ‘easy’ to get into (although it is, because it is written in Ruby). I choose Rails because it was the best web framework. If people want wordpress-ease, they should use wordpress – a web framework is completely different to an off-the-shelf app which is designed for one main purpose, even if with some leeway for customisation. I left off-the-shelf packages for Rails because I hated being restricted by them, and I was prepared to learn to program to use Rails. To my surprise, learning Ruby and Rails was *much* easier than learning say PHP and CakePHP (which I tried briefly). Also, I believe anyone serious about learning Ruby and Rails, can easily, in about 3 to 4 months by following this guide: http://astonj.com/tech/best-way-to-learn-ruby-rails/

    DOCUMENTATION
    I have to disagree – I *love* the Rails Guides, I’ve been reading them from start to finish on my Kindle (currently half way through Digging Deeper). Of course maybe like almost anything they could be better, but I disagree that they’re “far from great”. Try working with a forum app where documentation is next to non-existent lol.

    SUMMARY

    I came to Rails because I wanted a cutting edge web framework, one that was written in a clean, modern language – and that’s what will keep me here. I’m aware and happy to continue learning and keeping myself up to date to stay current. What I don’t want is a framework to lag behind others – that would very quickly make me think about jumping ship… and I reckon a large majority of others think the same too.

  14. #15 by Xavier Noria - February 29th, 2012 at 11:51

    I have to disagree with regard to documentation.

    Rails documentation had a lot of room for improvement before docrails. When Pratik created docrails (which was a brilliant idea) and they got public write access three things happened.

    One, content and conventions improved a ton. And I personally sat my ass in a chair for a long time doing this. Because, you know, Rails in the abstract is not going to write documentation, this is an open source project, *you* have to go your ass and contribute (“you” being a generic you).

    Two, the guides were born.

    Three, the project internally started to give more love for docs. Patches are monitored for docs coverage, etc.

    After more than three years of docrails, people contribute daily a lot of work. I think docrails is unique and speaks by itself in favor of Rails documentation.

    My impression nowadays is that Rails documentation is good. That is not to mean it cannot be improved. Of course I’d love to have more guides, and more depth, and better API. I’d also love to have a different tool for API generation (something I’ve explained several times). But the fact that things can be better does not mean that things aren’t great. So we disagree in this particular point. I think Rails docs are great, and of course a lot of people read the guides, where did you get the idea about guides usage?

    Regarding the Rails Tutorial: The Rails Tutorial has a free version, absolutely, it is really first-class material, and the official docs link to it. You call it “external” documentation, but you cannot forget the Rails Tutorial is a commercial book, and an excellent one, one just can’t compare a commercial product with volunteer work. The same way you cannot put MacRuby’s open source documentation on the same page as your book.

    • #16 by Matt Aimonetti - March 1st, 2012 at 16:56

      Thanks Xavier for the feedback. I agree that a lot of effort has been put in the documentation, especially the API doc. I’m personally a big fan of the guides because they quickly answer a specific problem. When I look at the API docs, I get totally overwhelmed, not knowing what version of the method does what etc…
      There is also the issue of the entry points. In Rails, you have a lot of entry points and I don’t think it’s fair to expect developers to know what API to use so they can go look up the documentation.

      In other words, what I meant was that the current state of documentation to address a given problem is basically limited to the guides and they are still quite light (even tho what exists is quite good).

      Compare that with the Django book and you will understand what I mean. To take a concrete example, I wanted to write a simple non-AR class that works with Rails helpers. Looking for documentation on how to do that is really hard, you get some outdated blog posts, you get some pointers but nothing concrete. You figure out you need to use ActiveModel but googling “getting started with ActiveModel” won’t give you much more info. You then tweet about it and you are told that you can #1 read the source code (hey, it’s Ruby, it’s easy!) or #2 buy José Valim’s excellent book.

      • #17 by Paul Soszynski - March 3rd, 2012 at 11:45

        As I see this, the main priority in Rails guides is to cover the basic topics. It will eventually get more advanced topics. But if you want to do something that just 1% of the Rails developers want to do, for example, create your own Active Model object, you may need to use Google, you may need to read the source code, you may need to buy a book. As you said yourself, books, blog posts, are all part of the community.

        As in the comment #17, many people are very thankful about Rails Guides. Complaining about the guides just because you are an advanced programmer and cannot find a guide related to you is a mouthful complaint.

        It is also funny that you wrote a book about MacRuby to solve, as you said, “a serious lack of documentation” but when the same thing happens to Rails 3, with Crafting Rails Applications being a great documentation about Rails’ modularity, it is somehow invalid?

        • #18 by Matt Aimonetti - March 3rd, 2012 at 22:51

          You are obviously bitter so I won’t get into an endless argument based on a subjective perspective of what should or shouldn’t be documented and who uses what part of Rails ;) .

          However regarding MacRuby, I still do consider that the project is NOT well enough documented, but the difference with Crafting Rails Apps and my book is that my book is covering a language implementation and not a framework and that my book is freely available in HTML format.

        • #19 by Paul Soszynski - March 4th, 2012 at 02:48

          So, if I got this right, you complain that Rails 3 took to long when it was basically on the back of three people (Yehuda, Carl and Jose) and when they put a book together after all the work, the book not being free but $20 is a problem?

          All I am saying is: you saw a problem in the Macruby community and you are trying to fix it. You see the same problem with Rails and you are mouthful complaining.

  15. #20 by AstonJ - February 29th, 2012 at 13:01

    Xavier Noria :
    I have to disagree with regard to documentation.
    Rails documentation had a lot of room for improvement before docrails. When Pratik created docrails (which was a brilliant idea) and they got public write access three things happened.
    One, content and conventions improved a ton. And I personally sat my ass in a chair for a long time doing this. Because, you know, Rails in the abstract is not going to write documentation, this is an open source project, *you* have to go your ass and contribute (“you” being a generic you).
    Two, the guides were born.
    Three, the project internally started to give more love for docs. Patches are monitored for docs coverage, etc.
    After more than three years of docrails, people contribute daily a lot of work. I think docrails is unique and speaks by itself in favor of Rails documentation.
    My impression nowadays is that Rails documentation is good. That is not to mean it cannot be improved. Of course I’d love to have more guides, and more depth, and better API. I’d also love to have a different tool for API generation (something I’ve explained several times). But the fact that things can be better does not mean that things aren’t great. So we disagree in this particular point. I think Rails docs are great, and of course a lot of people read the guides, where did you get the idea about guides usage?
    Regarding the Rails Tutorial: The Rails Tutorial has a free version, absolutely, it is really first-class material, and the official docs link to it. You call it “external” documentation, but you cannot forget the Rails Tutorial is a commercial book, and an excellent one, one just can’t compare a commercial product with volunteer work. The same way you cannot put MacRuby’s open source documentation on the same page as your book.

    Just a quickie to say thank you to you and everyone who has worked on the Rails Guides – they really are excellent, and the .mobi version makes fantastic use of the Kindle – I’ve not seen any other ‘book’ use it like the Rails Guides does.

  16. #21 by jebw - February 29th, 2012 at 14:28

    As a rails user since 1.1 I’d like to lend a voice to the easy of use comment – when rails first came out it seemed to do a lot, and was easy to get started with, and relatively understandable through the Agile Web Dev book. These days it feels much heavier whilst simultaneously doing far less, a of the ‘useful’ features – acts_as_list, in place edit, etc have been superseded by gems, but these often are a mixed bag for both docs and code quality.

  17. #22 by Nik - February 29th, 2012 at 21:31

    I always agree on making things simple so that anyone can get in JustLikeThat(tm) – That’s a principle we should never doubt. Galileo believed in writing his findings in Italian instead of Latin, so that commoners can follow their curiosity deeper and with luck, some of them might find themselves not so common and do great things with it and everyone benefits

    Systems grow to accommodate, it is never easy to keep accommodating while making things simple for beginners. Like Jobs once said in his OS X intro, he wanted to make it powerful and usable for professional and the rest of us at the same time, just like a Pixar movie, kids get something out of it, adults get something out of it. It is difficult but there are no exits but charge into this difficulty and stay with it. And I think the next version of Rails should focus on just making everything snappier and nearly one-click installing. — By making things snappier, even if something were to fail, it’s always better to fail fast. Two reasons for this. One, the obvious of the two, is that people can move on to another solutions more quickly, making tinkering less painful. Two, because you know if something were to fail, it won’t take a second to find out, it encourages people to try things out.

    I know why there aren’t really that many one-click installers, the same reason why active scaffolding was removed upon rails 2 (?), rails team wanted people to learn more about the internal, so they tuned the magic down. I was lucky, now I looked back in 2005, I used instantrails and from not knowing a thing about programming/html/js/css to knowing a lot more, I would have been discouraged if I followed through the tutorial and got hiccup every step because I wasn’t on one of those lucky systems that the tutorial was consciously or unconsciously intended for. — I know it’s good to know your mothertongue’s subjunctive and all, but it’s more important to first learn your mothertongue or some tongue to get your started to even talk about subjunctive.

  18. #23 by Jeff Casimir - March 1st, 2012 at 05:20

    If you accept these ideas/issues as valid, then the only question becomes “can it be fixed, or do we need to start over?”

    The classical “great rewrite” issue.

    • #24 by Matt Aimonetti - March 1st, 2012 at 16:40

      From my perspective, speaking of Rails, I think that these issues can be fixed otherwise I wouldn’t be using Rails anymore. Also, as I said, I know people are working to get these things fixed. Based on the feedback I personally got, a lot of people seem to agree but also willing to help.

  19. #25 by Terry Roe - March 1st, 2012 at 05:44

    Merbist,

    Thanks for a very articulate summary of these issues. This kind of information is difficult to know before you dive into using a framework. Wouldn’t it be lovely if open source projects came with a full disclosure of strengths and weaknesses as defined by the community?

    TR

    • #26 by Matt Aimonetti - March 1st, 2012 at 16:43

      Such a disclosure would require a high level of introspection, honesty and a controlled ego. Things that most FOSS lack. The other thing is that FOSS is also all about competition and getting a momentum which often means somewhat unethical marketing maneuvers :(

  20. #27 by cbmeks - March 1st, 2012 at 07:45

    Anyone who thinks Rails has a huge learning curve or large barrier of entry has never been in the Java/Struts/Spring world.

    When your first web app has to deal with DispatcherServlets, DelegatingFilterProxy’s, and Filter Chains then you might take that back.

    Rails for the win. Or hell, anything Ruby based with some Backbone sprinkled in.

    • #28 by Matt Aimonetti - March 1st, 2012 at 16:47

      If you satisfy yourself by comparing with worse products than the one you do/use, then you won’t really improve. I personally prefer to look at the best in the category and aim to become even better. So, at the end of the day, it depends on your perspective, do you want to be better than the worse or the best ;)

  21. #29 by irv - March 1st, 2012 at 09:21

    I agree with almost all of this. I gave a presentation on Rails to some people at work recently. I had to tell them the truth, that upgrading from Rails 2 to 3 was a nightmare and 3 is harder to get started with but you should use it anyway, since the newer gems tend to not support the older Rails.

    I hate having to sound negative like that when I’m trying to get people to adopt something. But some of these people around here are still using JSP. Ack! At its worst, rails is better than that PoS could ever be.

  22. #30 by Scott - March 1st, 2012 at 13:30

    “it’s also much harder to get started” – It’s mind boggling that you would say that. Absolutely inaccurate.

    In my experience, it’s never been easier to get a Rails development environment installed, to create a Rails app, and to get it deployed. Between homebrew, gems, Gemfiles, and other offerings such as Heroku – starting a new Rails app has never been easier. Never.

    • #31 by Matt Aimonetti - March 1st, 2012 at 16:44

      I see your point: tooling got better. I absolutely agree with that, but it doesn’t mean that creating a real app did?

  23. #32 by Michael McDermott - March 1st, 2012 at 17:13

    Mr. Aimonetti,
    Thank you very much for a very insightful post. While tooling has become easier, it used to be a ton easier to get a simple web app up and running. I tend to reach for Sinatra more and more for small projects.

    I think a recent post by Giles Bowkett’s echo’s your sentiment that the cutting edge of Rails dulled during the merge. The point I take from both essays is that by treading water, some of the forward thinking ideas in the web app space in general have not crept into Rails at a pace they used to. It is hard to argue whether this is a result of the merge or simply because Rails is a mature framework now and change is harder, but my gut tells me the merge played a part.

    That said, I still love Rails. The point was rammed home this week as my workplace gears up for a management inspired J2EE major vendor implementation. To make 1 Java class run, I had to code 2 xml files in seemingly random directories, use a Java GUI, a web GUI, an ant script on the server, eclipse for coding, and an ant script to get stuff onto the server. 1 Java class.

    Rails may not be as limber as it once was, and your point that comparing to the low bar is a bad way to measure yourself, but it is still important to recognize that bar is pretty low and the context of your post is a call to make good great.

    • #33 by Matt Aimonetti - March 1st, 2012 at 17:19

      I fully agree. I’m still using Rails every time I need to create dynamic HTML views server side. As a matter of fact, I started a brand new Rails 3.2 app this week.

      Regarding the merge, I think that it was a mistake but it doesn’t mean that Rails 3 is bad.

  24. #34 by Systho - March 2nd, 2012 at 11:15

    Documentation is not only “online documentation”
    Reading “Agile Web Development With Rails”, “Rails AntiPatterns” and “Crafting Rails Application”, and you will quickly learn a lot from beginner to very advanced topics.

    The tooling has also become *much* better than in the early days. Rubymine, for instance, is a full featured IDE which dramatically lower most of the obstacles when you come from another language.

  25. #35 by Carol Nichols - March 2nd, 2012 at 14:04

    Regarding testing before releasting/experimentation and making upgrading easier, it’s kind of a chicken-and-an-egg problem.

    In order to make sure upgrades go smoothly, the rails core team needs people to try out upgrading real world apps and let them know of problems. People running real world apps generally don’t have the time to spend upgrading to an alpha or beta and reporting problems, so the problems aren’t discovered until the official version is released. I’m not sure if there’s a solution for this.

    And FWIW, I’ve had wordpress upgrades break functionality I was using as well ;)

  26. #36 by Kevin Ball - March 10th, 2012 at 15:48

    Nice writeup Matt,

    I agree with you about the difficulty and pain with upgrading Rails apps from one version to another; I’ve fought that multiple times. That said, I think you’re underestimating the pain of upgrading wordpress… :P

    I think one of the big areas of question for me here is around the balance between staying on the cutting edge and providing stability. The technology world move so fast that if Rails were not rapidly changing, it would rapidly become obsolete… see a number of php frameworks… and yet, as you’ve pointed out, the pace of change and difficulty in upgrading makes it hard to stay up to date.

    Do you know of a platform/community that has walked this balance well that could be used as an example? I don’t know Django much at all; how have they done in this regard?

  1. No trackbacks yet.

Comments are closed.