Visual Studio 2008 vs Ruby on Rails
I had the pleasure of attending an information session with Bruce Tate, CTO of WellGood LLC, a die hard Ruby on Rails fan, and before that a die hard fan of Spring and Hibernate in the Java World, and before that a die hard Java fan :-) To be fair, Bruce is about doing things quickly and efficiently and I agree Ruby allows you to develop simple websites quickly that are mainly CRUD applications. So I understand why Bruce abandoned the Java world for the Ruby on Rails world, I left the Java world in favor of ASP.NET because of many of the same reasons that Bruce jumped on the Ruby on Rails bandwagon. But there are some things about Ruby to Rails that still bother me.
About 2 years ago, I looked into Ruby on Rails, even learned how to use it (loved the Pragmatic Programmer's books on Ruby and Rails), but it was a pig to host and get up and running on anything other than the infamous http://localhost:3000/ and don't even think about hosting a high volume website at that time. Now, Bruce told us that most websites do not deal with the scale that would require a more powerful platform like ASP.NET, and I agree. But fast foward 2 years to today and I asked Bruce the question "what about hosting?". His response? "That continues to be a thorn in my side.... but I've written a book." Thanks Bruce, I don't want a book, I want an answer. I'm sure it's a good book, but it is still a very telling thing that it is hard to get a good hosting environment. ASP.NET may be "big, bloated, and have a lot of configuration files", but have you seen what Apache magic you have to do to get this RoR thing hosted? Sure Ruby on Rails itself doesn't have a lot of configuration files, but Apache does and so does MySQL (the choice among open source developers). With Windows 2008 server coming down the pipe with IIS 7, configuration is much simpler than it used to be and the fully integrated ASP.NET pipeline makes for a very fast system.
The second question I asked him was about design, there are currently no Ruby specific WYSIWYG systems out there, but you can design your look in Dreamweaver and then edit in the dynamic content. That is how I used to do it with Java / Tapestry, so it's not new to me. But I've gone to ASP.NET and I don't want to give up my WYSIWYG with all the wizards that make my design life easier.
Finally, I asked him to show us an actual Ruby on Rails scaffold. He spent most of the time, granted he had a very short time, praising the Ruby language and ActiveRecord. Both of which I think are great, I wish I had ActiveRecord in ASP.NET. He quickly showed us a scaffold and how it works and I was impressed (especially with the new migration capabilities of ActiveRecord).
So the question is: Are all the great things they are saying about Ruby on Rails really worth switching? I'm sorry Microsoft, but ASP.NET is awesome for complex websites dealing with heterogeneous data sources within a clustered environment where the ability to monitor and manage the application and it's performance is important and where the pages are more complex than a simple data presentation... actually... well done Microsoft!! Being that our company develops for the DotNetNuke platform, and Ruby doesn't have anything approaching a Portal platform with modular components and full membership management and granular security model (asked Bruce he couldn't think of any), we feel that Ruby on Rails answers a particular set of questions / problems that were the blight of the Java world and in same cases of the ASP.NET world as well, and when we do a project from scratch that fits the bill, we will definitely look at Ruby on Rails as a possible solution.
So some people who know me and know Bruce, may be asking "What is Bruce Tate, a big name Ruby on Rails person from Texas, doing in New Brunswick, Canada?" Well, it's simple. A local company switched their whole operation to Ruby on Rails and moved one of the big internet success stories from an ASP platform to Ruby On Rails. PropertyGuys.com, a For-Sale-By-Owner website franchise started here in New Brunswick, moved from ASP to Ruby on Rails. They looked at ASP.NET / C# for their system but found that Ruby on Rails allowed them the speed, flexibility and readability they wanted to quickly and easily prototype their new applications (more or less their words, I paraphrased it).
So do I think PropertyGuys.com was right to make the move? Faced with current technologies, Yes. Wait. Wait. Don't start throwing the rotten vegetables yet. Notice I said, faced with current technologies. Microsoft, despite many people's opinions, hasn't been sticking it's head in sand. They have been working towards Visual Studio 2008, which I think shows a lot of promise in answering the issues that Ruby on Rails raised. So let's look at them:
ActiveRecord
For those of use who have been subjected to DataSets, anything had to be better. I have quite enjoyed developing with NHibernate Object Relational Mapper (ORM) and a visual design environment from Puzzle called ObjectMapper. Since it is open source, I have "hacked" it up to better match my "brand" of development (mainly that it didn't support NHibernate 1.2). It allowed me to define the data model and produce the NHibernate code from the same visual model. It works great, but ActiveRecord and Bruce Tate are right. It's too much. ObjectMapper doesn't do everything I want (and sometimes gets it wrong), so I have to dig into the XML description file and make some changes by hand, recompile the Class Library and restart the application. That is too much work.
ActiveRecord on the other hand, simply looks like this:
class Item < ActiveRecord::Base
end
And you're done. That's all you need for a full fledged ORM. You can do things like Item.find_all_by_name, Item.find_by_id and ActiveRecord interprets (because it's a scripting language) what you mean and runs the SQL to retrieve what you want. You can even say Item.find_all_by_name_and_price, it's that good at understanding what you want. I have to admit that ActiveRecord is a hard act to follow. So how does Microsoft answer the challenge? LINQ.
What I like about LINQ is that fact that I can open a database connection, drag a table onto a form, see it visually along with all it's relationships, and have that generate the code for me. Yes, it's more work than ActiveRecord, no it doesn't have migrations (migrations are a feature of ActiveRecord that allows you to define the versioning of your database and roll forward and backwards based on what you need, adding or deleting columns, indices, whole tables). Yes, migrations are specified in Ruby code and require seperate files and properly named classes (How was I supposed to know that a file named 001_Create_Item_Table.rb should contain a class called CreateItemTable...), but they are a neat idea and make it very easy to upgrade a production database to the current version of the site. Oh, sorry. Back to LINQ. So though LINQ is no ActiveRecord, it is definitely far better than DataSets and probably better than NHibernate in many respects. The fact that you will be able to use LINQ with NHibernate is cool. (LINQ doesn't have any built in caching ability like NHIbernate, at least as far as I know). There is enough stuff out on the web about LINQ, I won't bore you with the details.
Dynamic Language
Ruby as a language is quite cool. It supports continuations, method objects, enclosures, dynamic type system, the ability to extend classes on the fly by adding mixins and new methods. I can't argue with the language. But a lot of the things that are part of Ruby are now in Visual Studio 2008 (except I haven't heard anything about continuations). It has lambda statements, delegates, variable type. The only big thing it lacks is the ability to redefine a class on the fly. And there are many things in the standard Ruby library that I wish were in .NET APIs. But for the most part, Ruby's benefits are being answered in one way or another in C#. Some may say "too little, too late". To those I say "Well, Ruby runs on .NET thanks to IronRuby". Yes, you can run Ruby on .NET. It's not a full implementation yet and it's not as fast as it could be, but it's not done yet. And being that it is fully backed by Microsoft, it will be the best it can be when it's completed. (I know, it is the same company that gave us Windows, but their development department is really quite good.)
Scaffolds
I admit, I like the idea of being able to say "Generate Scaffold Item" and get a complete CRUD system that just works, that is until you change the database and have to regenerate the scaffold.... At least with the GridView in ASP.NET it could dynamically regenerate the Grid (including edit forms) and Details View (so you could insert) based on the underlying database changes. And with the addition of Dynamic Forms to Visual Studio 2008, you get the power of scaffolds and Grid View combined. So Scaffolds are less of an issue compared to Visual Studio 2008.
DRY
Every where I turn with Rails, people are talking about Do not Repeat Yourself. That means "If you do something once, you shouldn't have to redo it again." I actually find that kind of funny coming from a system that doesn't really support componentized development. You generate a scaffold, then have to edit it to make look the way you want, rinse and repeat with every form you need. Yes, you can make reusable components in Rails, but in every place they tell you you can do it, they say "Don't do it!! It's too slow. They are hard to manage." Hmm... I like the fact that I can develop full components and place them into a DLL and simply by referencing the DLL, the components become available for WYSIWYG insertion and configuration. Again, Ruby on Rails answers a particular challenge and answers it very well. But when you don't want to completely rebuild a site every time you get a new project, you might want to look DotNetNuke. With DotNetNuke, we can build a site very quickly, easily, and visually. Yes it probably takes me longer to build a new component, but then the component is fully reusable. Yes, DotNetNuke is a framework on top of ASP.NET, but Rails is a framework as well. So let's just say that DRY is an over used word.
Code completion and compile time error checking
There is one big advantage with Ruby, no compiling. There is one big problem with Ruby, no compiling. When you don't precompile an application, you don't find the logic errors until the line of code is run. When you don't compile, you don't have the benefit of true Code Completion (or at least all the IDEs I've tried don't have code completion that works / works right / actually tries to narrow the options to the selected class!!) Yes, I know that Ruby on Rails comes with a great code coverage tool... but it needs it!! If you don't test every line of code you don't know if you've made stupid mistakes. Yes, I know code coverage is a good idea and that everyone should do it, but if you need code coverage to find semantic errors.... well, let's just say I don't want to look like an idiot when my co-workers run the code coverage tests to find I can't spell :-)
So all in all. If I had to make a choice today, I might choose Ruby on Rails for new development. But for existing development and for projects that fit the portal model, I will definitely stick to DotNetNuke/ASP.NET. When Visual Studio 2008 comes out, I might be less inclined to go for Ruby on Rails.....