9 June 2006 in .Net, Code | Comments enabled

Ruby On Rails

This post is intended as a discussion piece, if you have any thoughts about anything mentioned here then please add a comment. Don’t be afraid, it’s just some friendly open debate :) If your post on your own blog about this discussion let me know and I’ll update this post with links to your posts.

Recently I’d been hearing a lot about Ruby-On-Rails (RoR) and decided, like any diligent tech person, that I had better investigate it to make sure I’m not missing the boat on something new in the marketplace. I brought the books and did the tutorials. I also built a couple of basic sites on my own with RoR and they were fun to build. However, having come this far I’m finding it difficult to come up with a compelling reason why I would want to jump ship completely.

I thought I’d sum up with my top 5 concerns at the moment:

Issue one
The Rails framework has some compelling features like scaffolding however while that initially “hooks” you in and makes you think it’s fantastic you soon find that scaffolding up a solution is almost pointless because you nearly always have to write something considerably different to just CRUD pages. This initial development speed enhancement doesn’t actually end up helping you out that much. It harms people more than it helps them by having the misconception that scaffolding is actually a very useful feature of rails (it has its place, but it’s just not that important).
Issue two
Ruby’s performance just doesn’t seem to compare well with most other languages. admittedly you take a hit with any scripting language but the performance hits seem quite severe. Comparing Ruby’s performance to something like Java (I couldn’t find any .Net comparisons at the time of writing this) it seems apparent that Ruby is abysmal in the speed arena. You could argue that there are ways to optimise the code to run better or that you can just scale up your hardware but I just want a fast language. There seems to be so much code churn in the Rails framework that optimising for performance may be difficult to do until it has a stabalised feature set. Why is Ruby so slow? I think enough things on computers are slow enough these days without opting for something at the back of the pack. Can anybody provide evidence that Ruby isn’t so slow?

Issue three
IDE’s are lacking. I’ve used RadRails and I’ve a friend who uses TextMate and neither seem to provide anywhere near the functionality that I’d expect from a modern IDE. I’m always happy working with light weight IDEs but when I need to get a large application off the ground I’m always thankful when I have an industrial strength IDE to help me manage it.

Issue four
RoR seems to have new versions released often. Too often. Now, the geek in me loves the idea of having new features to play with every couple of weeks however from a business point of view it just increases the risk considerably. I remember the fallout from RoR being upgraded to a new version and all of the blogs based on Typo. You could freeze the version that an application worked against but it seemed like everything just fell apart for a lot of people when that version was rushed out. I’m all for the cool little team pumping out new features all the time but sparing a thought for the web hosts who have to test the framework before deployment, the people who deploy solutions on it and the developers who have to upgrade the version that their application supports constantly would be nice.

Issue five
All of the other issues are only really issues because of this point – I just cannot see how RoR scales up to develop truly large solutions. Perhaps it’s not really intended for more than basic websites? Some of the generators designed to save you time would simply hinder your ability to actually maintain large solutions nicely in my opinion.

These are some issues that have me feeling that RoR might not be as ready for the primetime as many would have you believe. Perhaps I’m wrong. Perhaps you know reasons why these points are not issues. If so, then please leave a comment about why you think so. Comparing these issues to my current web framework of choice – ASP.Net – I don’t think RoR stacks up well enough in my mind. I realise there are areas that it lacks that RoR does well however other vendors such as Microsoft are working hard to cover these areas as well (ATLAS, DLINQ etc).

Disclaimer: I do spent a significant amount of my time developing solutions using the Microsoft .Net Framework. I’ve not always been a .Net developer, I also have spent considerable amount of time developing in various other languages such as Java, PHP, C/C++, Delphi to name a few and of course dabbling with RoR :)

- JD

Links:

  • Andrew Peters makes his first ever post and pulls no punches :)
  • Tim Haines thinks I’m stirring and has some links to the WellRailed convo
  • John Lewis doesn’t take part in the discussion but brings his own perspective to RoR in general

Average Rating: 4.4 out of 5 based on 219 user reviews.


22 comments. Add your own comment.

Just Another Grumpy Developer says 9 June 2006 @ 10:02

RoR (like any other technology) has it’s place in the grand scheme of things. I think the problems with RoR are not with the technology, but rather the hype generated by passionate and well meaning (yet ill informed or narrow focussed) types who think RoR is the next panacea to all their web development problems.

I’m a cynic (and a c# developer as well), but I have read enough to see that applied to the right problems, RoR is great – just don’t expect it to be everything the hype makes it out to be. It’s time to shoot the tech reporters (actually any reports but thats another discussion entirely) who don’t think beyond the narrow confines of their current piece.

sitharus says 9 June 2006 @ 10:08

1. Scaffolding has a use when you’re trying to cook up a very basic app fast, but I agree that it isn’t much use for a complex app that does more than CRUD.

2. Ruby is slow, so was Java when it started. There are several projects to speed it up, including bytecode compilers and a project to make Ruby self-hosting.

3. Never found a need for an IDE, they just take up useful screen space with junk that’s faster to type.

4. Agile development. Release each feature when it’s ready, release fast, you can improve later later. The company I work for has had great success over the past 5 years doing just that. Customer tend to want something now, and they’ll wait for it to become great just so long as it works.

5. Scales requests or developer time? The first is through shared-nothing and clustered webservers. Caching helps as well, there’s a memcacheable ActiveRecord subclass out there. The second is from reduced code, the less you have to type the faster things happen. I know there aren’t pre-built table controls and things like that, but it’s all a matter of preference.

traskjd says 9 June 2006 @ 10:20

Thanks for the comment sitharus.

With regards to following points:

3. Would you still be happy to work without an IDE if doing a half million dollar project? What sized projects would you require before you though that RoR just wouldn’t be up to it?

4. Agile is good, but I don’t agree that it’s good when the foundation is changing constantly. Agile suits developing solutions but products/development languages don’t suit it. They need more structured testing and suit be stable for long periods of time.

5. I meant scaling in terms of both time and requests. I know there are a few very large sites running RoR but reading the effort they went to in order to scale it sounds like a black art. In terms of development time RoR maybe faster initially but when you have a truly large solution I find scripting languages break down.

– JD

sitharus says 9 June 2006 @ 10:30

3. Absolutely. I’d work closer with version control though, Textmate has SVN support in it as well. I wouldn’t say any size project isn’t suitable for RoR, the technical requirements would dictate that no matter what size. Eg if deployment to Windows is a must I’d go with .NET or something.

4. I’ll agree that some things change too much, but the app I’m working on at the moment simply doesn’t work in PHP 5, and in the Rails world a change from 1.0 to 1.1 is similar to that. PHP has broken things inside 4.0 releases, and I bet .NET 1.0 to 1.1 had issues for one or two apps – nothing’s perfect.

5. I hate the term ‘scripting language’ for Ruby, it implies that it works on external applications only, like VBA or Applescript. Ruby is a full programming language, it just happens that right now it’s interpreted rather than bytecompiled like .NET and Java. By that standard Python is a ‘proper’ programming language, as it’s byte-compiled, and there’s even an x86 JIT compiler for it.

However, I digress. Scaling RoR is easy, it’s exactly like scaling PHP. You store sessions in the database, make sure any cached files are synchronised and deploy more web servers running the app. If your DB won’t scale you still have problems though.

traskjd says 9 June 2006 @ 10:57

Just on point five, when is it expected that Ruby will be able to be “compiled” into bytecode?

– JD

sitharus says 9 June 2006 @ 11:04

Not entirely sure, it should be integrated in to a future version of Ruby when finished. You can get it now from http://www.atdot.net/yarv/ if you feel like compiling it. It’s very much in development though, various things don’t work right on it.

/ drew’s Blog » Blog Archive » On JD on Rails says 9 June 2006 @ 11:15

[...] JD has posted about five four problems he sees with RoR. In this post I’ll try to address each of his concerns. [...]

traskjd says 9 June 2006 @ 11:56

Thanks for the link Sitharus :)

– JD

Gabe says 9 June 2006 @ 12:03

1. I agree that people are being misled by scaffolding. But that’s not Rails’ problem. If you actually generate the code instead of just putting the declaration it’s informative about how several different parts of Rails works and provides a decent jumping off point for modifying the code if you are still uncomfortable setting things up from scratch.

2. 10 years ago people said Java can never replace C++ because it’s too slow. Productivity is more important than raw performance 9 times out of 10. Ruby being purely interpretted has a lot of room for improvement with the bytecode compiler. Certainly some features of Ruby certain optimizations impossible, but it remains to be seen how fast Ruby can get. Certainly you wouldn’t want to use Ruby for crunching massive data sets, but Ruby on Rails performance seems quite by my experience.

3. RoR removes a lot of the boilerplate code which make IDEs such an indispensable product for Java and .NET. I think you will see more IDEs emerge overtime, but personally I find the easy programmability of TextMate extremely useful in a Rails environment. Between the command-line tools (breakpointer, etc) and a good set of snippets and commands, there’s very little I miss from an IDE.

4. This is true, but also consider that Rails was only released 18 months ago. Version 1.0 was only release 8 months ago. It was essentially created by one man. You have to expect there to be a lot of areas that need to be fleshed out. Given the massive popularity, my guess is this will be a diminishing problem. Also, because Rails makes testing so easy, it’s similarly easy to automatically discover where breakage has occurred.

5. This one I just don’t get. Performance-wise Rails scales with a share nothing approach. It keeps its classes in memory using FastCGI, and it has a very easy-to-use caching system. You hear this admonition all the time, but there are some pretty large websites running on Rails. You never seem to hear any thorough analysis about why Rails doesn’t scale, it’s always from quick one-off reviews like this.

Development-wise have you looked at the output of the code generators in Rails? It’s all pretty basic readable stuff. In my mind RoR projects scale better than most other languages because of the low signal-to-noise ratio in the Ruby language. Using things like Ruby blocks, mixins and naming conventions to their full extent make RoR code lighter and more readable than their PHP or Java equivalent. In that regard I see RoR as being one of the most scalable solutions out there.

I think more pressing issues with RoR might be lack of support for unicode, many rdbms features aren’t given their due, lack of ruby bindings for some libraries, hosting availability / expertise, and general maturity. However having worked in-depth with Rails it just hits a huge sweet spot for web app development for me personally. Given the quality of the community and how its reached critical mass, I feel very confident developing websites using Rails. Maybe not quite there yet for million-dollar corporate projects, but I think it’s only a matter of time…

Michael Koziarski says 9 June 2006 @ 12:21

I responded to most of these on the WellRailed list, but a few quick words here.

While we dropped the ball with the 1.1 release, regular releases are not the problem. Just like j2ee developers stick jar files in /WEB-INF/lib, you can (and *should*) stick rails in your /vendor directory.

As for scalability, Penny Arcade is written in rails and handles traffic on the same scale as trademe (assuming alexa isn’t lying)

http://www.alexa.com/data/details/traffic_details?compare_sites=trademe.co.nz&range=6m&size=medium&y=r&url=www.penny-arcade.com

To me that says rails is fast enough, and sufficiently scalable to handle the vast bulk of projects you’ll ever come across. Scaling a rails app is different to scaling a .NET one, but both require work and both can be done.

traskjd says 9 June 2006 @ 13:21

Cheers for the very well written comment Gabe :)

Also thanks for your comment too Michael.

It’s good to be getting quite a few different opinions for various points in my post :) Remember to let me know if any of you blog about this and I’ll hook you up with some Google juice.

One thing I was surprised about is the comment that it doesn’t support unicode.

Cheers guys,

– JD

sitharus says 9 June 2006 @ 13:29

Well, Ruby by default only supports 8-bit text, but it comes with a library that enables Unicode support for some string operations. Regexp’s still don’t support unicode though.

It is quite surprising considering that Ruby comes from Japan, but development started in pre-unicode days.

Michael Koziarski says 9 June 2006 @ 13:45

Because ruby’s from japan, unicode isn’t particularly popular there. Han unification is a bit of a sore spot:

http://en.wikipedia.org/wiki/Han_unification

However it’s utf-8 support is included in the std library:

$KCODE=’u’
require ‘jcode’

Then all your strings will work fine.

You have to be careful with things like String#[] as numeric references into variable byte strintgs won’t behave correctly (under any language).

We support several non-latin languages with my clients app. Farsi, Hebrew and Chinese were just tested this morning. No problems at all.

traskjd says 9 June 2006 @ 14:38

Michael, are there any other things that people might not realise are not quite complete with Ruby/RoR? I only ask as I haven’t built a significant project in Rails and if there are simple fixes for some then people reading this might find those solutions useful.

– JD

Keith says 9 June 2006 @ 15:08

there are issues with any platform, but the bigger question to ask is….

Are you more productive with RoR?

thats the argument a lot of people who use RoR have for using Ror, its fast and fun…….

imagine if….

- your more productive using notepad and RoR than using a fancy ide and C#…

- Ruby is slow but is still fast enough for given te purpose…..a car is a much better way to get around a city than a jet is. But the jets faster.

- you need a few more webservers to deliver a soloution but you deliver much sooner than you’d deliver anything else….

The real question about RoR is, are these things true? can you be a lot more productive?

traskjd says 9 June 2006 @ 15:20

Valid points Keith but you’re talking to a guy who finds coding in raw MSIL fun ;) Although I must admit that isn’t exactly a fast way to code.

It seems on the point of hosting the general consensus is that you should expect higher hardware requirements than on other contemporary languages.

Personally I initially thought I was about equal in productivity with RoR until I started trying to do things “outside the box” and ran into problems – things that I knew I could extremely easily in .Net for example. As pointed out earlier – each person has their own preference though :)

Thanks for posting Keith.

– JD

Gabe says 11 June 2006 @ 05:06

My experience with RoR compared to PHP is that I’m about as productive as I imagine myself to be! But then when I go back to PHP I’m amazed at all the hoops I have to jump through and end up always taking longer than I thought. I’ve spend 6 years developing a lot of personal MVC-style conventions for efficiently writing PHP. Yet Rails is already faster for me when I know comparatively little about it and the Ruby language. Now I expect ASP.NET with an IDE is much more productive than raw PHP, but I’m really reluctant to go with a Microsoft platform because open source just seems a lot safer for long-term development purposes (to me). I’m also not interested in anything too enterprisey. I realize that J2EE can do a ton more stuff than Rails, but I don’t feel the need for the mental overhead and complexity (and verbosity). Enterprise developers are fond of calling RoR a toy. But answer me this: Would you rather be in a cubicle working on some arcane component that no human being outside your team will ever be able to understand? Or would you rather play with ‘toys’ all day? I’m not offended by the toy moniker, I’m just glad I can make a living with it!

As for going outside the box, I think that’s just a matter of familiarity. Personally I still have a ways to go to become as familiar with Ruby as I am with PHP, but so far Ruby feels like the most expressive language I’ve ever worked with. Looking at the available plugins is proof of just how outside the box you can go keeping with the spirit of Rails. With PHP and Java I feel like you just write APIs all day. If you need new functionality in a modular form, you write a class. One way to do things. In Rails though you can write a plugin that extends the existing functionality by means of mixins, or general methods that are specialized with blocks. It’s a new way of thinking about things, and takes some mental gymnastics to get up to speed, but the rewards are great. A good example is the file_column plugin for Rails that lets you turn a database field into a filesystem-stored file with a single declaration in your model. It processes uploaded files, stores the filename, and even allows multiple versions of images transformed by imagemagick, all with a single declarative line in your model. Not that APIs can’t do this just as cleanly, but Ruby provides more vectors to approach problems, and its accomplished relatively easily.

I think the perception that going outside the box is difficult with Rails is based on how easy it is to stay inside the box. But the opportunity to expand the box is there, and make more things just as easy. I think it all boils down to Ruby. If you can’t get into Ruby then Rails will never be comfortable. The reason I embraced Rails so readily is because I’d already been looking at Ruby for a while, as a well-designed alternative to languages like PHP and Perl. And Rails is very well-written Ruby.

traskjd says 11 June 2006 @ 15:16

Thanks for you thoughts there Gabe :) You’ve got a very easy to read writing style.

Rails certainly does have a lot of plugins available for it but this also presents a challenge to me. Often I would find a plugin or generator that looked useful only to find that it didn’t work on the current version of Rails. I didn’t look for too many but it was a mild annoyance. I do however like that there are generators and plugin libraries available even this early in the life of RoR.

– JD

Gabe says 12 June 2006 @ 09:28

Actually I’ve experienced a corollary of this which is that there’s a ton of content out there about Rails that is not marked with a version (and sometimes not even a date). I guess this is the flipside of “release early, release often”. Documentation for Rails is thin in so many areas that informal resources like blogs and unorganized Wiki pages end up becoming defacto authorities.

On the one hand it’s annoying when things change and break so often, but on the other hand it’s also annoying when legacy decisions prevent technology from reaching its full potential. PHP is a prime example of this though it’s an easy target because of just how bad the decisions really were.

It feels like Rails is stabilizing, but I seriously doubt whether it can ever rival the stability of corporate frameworks. There’s a fundamental value difference in large organizations where stability over time far outweighs productivity gains. If you’re talking about million-dollar systems with lives of 20, 30 or 50 years, initial development time pales in comparison to maintenance. Fortunately that’s not the field I’m in.

Marc says 16 June 2006 @ 18:39

Interesting thread. What’s a good book to learn Rails from for someone who’s a professional programmer already familiar with a number of languages, such as PHP and C++?

traskjd says 17 June 2006 @ 14:29

Marc,

More books on RoR are coming out but the best to start with is the second edition of “Agile Web Development with Rails”. Coupled with “Programming Ruby” which is a useful language reference for Ruby as well if you want to get a little deeper.

– JD

JD’s Weblog » Ruby on Rails, follow up says 27 August 2006 @ 18:18

[...] A week ago I posted a blog entry detailing my concerns about some elements of Ruby on Rails (RoR) and had a terrific response from a wide variety of people. Overall it would seem that most people agreed to an extent with most of the points but many didn’t see them as major problems but more things that needed to be worked on. Of course some people found some points not to be problems at all and that’s good for them. [...]

Leave a Comment

Name (required)

E-mail (required - not published)

Website

Your comment: