Ruby on Rails development seems to be stalled, with no substantial release since March and many show-stopper bugs in the current version, 2.3.4, such as the claimed Ruby 1.9 support which does not work, meaning that the official Rails gem doesn’t run on the only version of Ruby that doesn’t leak memory like a firehose leaks water. Freezing to edge is broken and has been broken for months. Needless to say, that’s because master is now Rails 3.0pre which is in a totally unrunnable state.
The seems oddly low-volume, considering 2.3.5 is over a month late and 2.3.4 has so many problems. Working patches to fix critical errors languish unmerged for months, constantly needing to be regenerated to keep up – not that there’s anything official to keep up with, since there’s no real 2.3.5 target and master is fixated on the faraway 3.0. The Lighthouse tracking system is itself a hopeless, unnavigable mess.
So what’s going on with Rails? With the historical core developers absent or tied up with reinvent-the-world expeditions like the 3.0 rewrite, the projects appears directionless and adrift. Meanwhile the shine fades and word leaks out that all is not well in Railsville.
What happened? Two causes.
Firstly, the shoot-for-the moon total rewrite for Rails 3, leaving Rails 2 languishing for the better part of a year now and Rails 3 in a totally unrunnable state.
Secondly – well, this is just my opinion. But one of the reasons Rails was great at first because it was written by people who actually wanted to use it to make actual proper web apps. And then it became famous, and then it attracted another type of developer – people who just wanted their membership in Rails Core on their resumé – but they weren’t going to actually use it for real-world projects. So instead of getting fixes to seven-month-old show-stopper bugs, we get Engines and RESTful Resource Mapping and Application Templates, none of which are much used or useful in the real world.
Rails is looking sicker by the month. And since Core has bet the company on Rails 3.0, it better blow the world away and fix everything, or I have a feeling a lot of Rails devs are going to start looking for the next big thing. Or actually, the next small thing. I would trade off 90% of Rails’ useless bloat and feature creep for a minimalist framework that actually works, has developers who care, has a readable codebase and a clear direction. Basically, what Rails used to be before DHH got tired of saying “NO!” and it turned into a stumbling monster.
Sinatra? It’s possible but it’s a little too unstructured; great for a tiny API but I’d be worried about trying to use it for a large project. Django is by all appearances in even worse shape than Rails. Ramaze? Looks very interesting.
Update to turn down the tone a bit and correct some links. I will follow up with some constructive posts later; it is actually possible to run Rails on 1.9, just takes some work.
Tags: rails
November 17th, 2009 at 7:55 pm
Hi,
I’d like to learn why Django is worse?
November 17th, 2009 at 9:25 pm
Hi mengu, I didn’t mean to say that Django is worse than Rails – only that I feel the project lacks direction and motivation. I mean, it took *3 years* to move from 0.90 to 1.0.
Plus – not that I’m an expert but I get the feeling Django is not the flexible, cut down solution I’m hoping will emerge to solve the problem. It’s too CMS-y. And furthermore, I like Ruby better
I feel like we need a new paradigm in how these projects are organised. Both Django and Rails try to force an MVC structure on a website project but most developers know that structure just flies straight out the window once you implement anything more complex than a blog. I feel that MVC may be inappropriate for the web full stop and we should stop even trying to jam this square peg into that round hole.
But I’m getting off topic. I guess I don’t see Django as a step up from Rails, is all. It’s a step across and it’s just as much of a straitjacket.
November 18th, 2009 at 3:32 am
Hi Sho,
No worries, I’m a Rails lover but i also like Django. I am using Rails for my own projects but using Django for projects of my clients since it has a very nice admin helper and I really don’t want to deal with it. I think you get the feeling “CMS-y” for Django because of it’s admin side however Drupal or Joomla is a CMS but Django is too far away from them.
If you worked with Rails and then tried Django, then you won’t like it because it is not flexible as Rails is. You have to deal with many things that you don’t with Rails however it is really a good framework. Worth a second shot.
November 18th, 2009 at 4:14 am
Agreed with you that the development effort really seems to have run out of steam. (I wouldn’t actually say “stalled”, but it is certainly “limping”.)
It was always the risk with the planned “leap foward” to Rails 3 and the merger with Merb. In reality these gigantic “leaps” never work well and the the best way forward is always through ongoing, incremental improvement. I think as developers we all know this from our own experience. Often (always even?) turns out that going slowly (small steps) actually gets you there faster.
A less “exciting” road map consisting of 2.3.5, 2.3.6, 2.3.7, 2.4, 2.4.1 etc releases would work much better, but evidently couldn’t possibly compete with the marketing wallop of “Rails 3.0″; but you know that marketing has always been a little too important to the people driving Rails. And I fear that in the end they’ll get sick and tired and rush out a 3.0 release before it’s really properly baked.
Out of interest, what do you propose as an alternative to MVC?
November 18th, 2009 at 12:10 pm
Yeah, I agree that the “giant leap forward” never works and is probably the real issue.
Well, I’m not really sure what would replace MVC. In fact maybe it doesn’t need to be replaced, but just used in a different way. It certainly needs to either be separated more cleanly or adapted in some way; the current situation is ridiculous.
It’s a complex topic and this is just off the top of my head, but the problem as I see it is twofold. Firstly, modern web pages can be very complex and a single page can draw on information from multiple sources. Think of a news page, for example, with the main story in the centre, the user’s login status up the top right, the weather up the top left, and a list of top stories in the centre right.
Which of these multiple resources should be considered primary? Obviously the news story, so we would perhaps use the “stories” controller for this page. What, then, serves the other information? In my opinion it should be written to the view by appropriate controllers – weather/current, perhaps and stories/top. But instead, the only practical way to do it is to put calls to the model directly in the views. So the controller is completely short circuited and acts as a glorified router, basically.
The other biggie I have in mind is caching. Caching in Rails is best done directly in the view with fragment caching, or at the whole-page level with page caching – but still of the views’ output. Either are writing to a global data store which is outside of, but can be accessed by both, the controller or model. Indeed, the model should be able to invalidate the cache of the view directly for most efficient operation. There could be two or more cached items for any one page. Again, the controller is out of the picture as the Model directly reaches into the views’ caches, expiring at will.
How is this sane? Again we have the confusion of roles, with powerful views and models going over the head of the anaemic controller. Once again the controller is a glorified router, at best getting a couple of words with the request before it heads off to where the real action is.
Rails, and perhaps the web environment in general, turns the view and the controller on their heads. Do you remember that ridiculous “best practise” to not put calls to the model in the views? This is of course total fiction. Indeed, there is no place else to put them. But trying to stick to the “ideal” of putting them in the controller can lead to some truly hilarious contortions, such as this one I saw recently (edited a little for simplicity):
# in the controller def day if params[:day] = Day.new_from_id_arr params[:day] end ||= Day.new = lambda { |division| Media.all_for_day(day) } end # and then in the view <% cache(.cache_key) do %> <% = .call() %> <% if !.empty? %> <% .each do |item| %> <%= render :partial => 'media/single_story', :locals => {:item => item } %> <% end %> <% else %> Nothing found for this day. <% end %> <% end %>Now if that isn’t a perversion of everything MVC is supposed to mean then I don’t know what is. But that’s the way you do fragment caching.
How to solve these problems? Well, I’m not sure. I have some ideas I’ve been playing around with over the last year or so. I envisage a much more modular system, with routes in the controllers where they belong and muvh more “active” view fragments able to load data from their controllers on demand. Caching would be a first class citizen and done only at the view fragment level where it belongs. No abomination of a routes.rb file. Proper use of public and private. No framework subclassing in models. And a partridge in a pear tree!
Ah, who knows. Anyway I’m going to check out some other frameworks. Problem is everyone expects Rails these days; if you want to play around with something else it’s on your own time with your own projects. Ah well, maybe I’ll have a shot anyway.
November 19th, 2009 at 2:14 am
There’s much to like in 3.0, but I agree that the focus should be stable code, bug fixes, and solving the memory issue. I realize that the memory issue is due to Ruby not Rails, but if I think about the Ruby/Rails ecosystem as a whole, I’d trade fixing the memory issue via REE style modifications in 1.8.7 for any (and all) new features.
November 19th, 2009 at 2:32 am
Well, Ruby’s memory problems are largely solved in 1.9.1, so what I’d really prefer is that Rails Core focus all their efforts on getting 100% compatibility with that.
December 15th, 2009 at 11:59 am
Nice call out there. Hopefully they’re right about Rails 3, but maybe it just ends up scaring off some of the ‘poser’ developers you mentioned.