Rails - The Good, The Bad, and The Ugly
Before we start, so you all know where I'm coming from and don't think I'm picking on anyone, I'll give you the following summary of other web frameworks out there (and this is all first-hand experience):
OK, so now let's talk about Ruby on Rails.
The Good
Based on my analysis of the Rails framework and using it, this is a framework that is optimized for single developers or (very) small teams. I say this because it provides tools to build all layers of the application (data, middle/server, and client) from within the Rails environment. It is built to be your everything for building an application.
Rails is great for prototyping a system or for bringing someone who's new to web development up to speed. It has a tightly structured framework that is well thought out. It also promotes good coding practices via the integrated testing framework.
The design of the RESTful API and routing are top-notch. It is also the first web framework I've seen that provides clean and tight integration hooks for client-side javascript libraries. In every other platform I've used the client side hooks are bolted on as an after though. And they feel like it.
Rails provides a console for dynamically testing the objects. Just create one, invoke it's methods, and have fun. In fairness, .Net provides this with the kick-ass new PowerShell, but doing things this way is not common practice (tho we probably should).
You get gems, which is a kick-ass Ruby thing for installing and updating all sorts of components. Picture Eclipse's add-on functionality, but without the bother of constantly having to manually add new repositories. Find a new cool tool you like, type $> gem install watir.
Rails Engines are a totally sweet idea. Instead of using wizard builders for functional blocks like Visual Studio does, you install and configure whole functional blocks -> user logins, etc.
The Bad
Rails is built to be your everything for building an application. This means it does some things fairly to exceedingly well, and other things exceedingly poorly. Unfortunately, since it is a tight stack, Rails will fight you if you try to use another tool/technique for an aspect of your application.
What does that actually mean?
Well, for starters it tries to be smarter than you for common tasks. Often it is, but your code ends up inefficient. The has-many :XXX / belongs_to :YYY makes it quick to wire object data relationships up, but it leads to tremendously inefficient code. Common reference tables wired up this way will be constantly queried as you use the objects.
Rails treats the database engine as a second class citizen. This may seem counter-intuitive to many people who have read some of the Rails docs about "why ActiveRecord" or are relatively new to ORM frameworks. And it is. Counter-intuitive. That Rails doesn't leverage the database engine in a very intelligent way. The bulk of the meta-data is ignored, or worse, discarded leading to - what's the phrase... - shitty database design.
OK, so what do I mean? Well, if you use the Rails format for managing database creation all of your foreign keys will be thrown away. Data integrity anyone?
Migrations are a nice idea. In practice they suck balls.
Let me see if I can explain it in layman's terms. Problem: Database design changes with the growth/implementation of a project, requiring developers to sync their data models.
Rails Solution: Auto-gen database differences and prompt devs to apply them over the course of the development cycle. Real Solution: Be able to rebuilt/redeploy database at any point from script, both in new state and in "since last checkpoint" state. The problem with migrations is that they are not just a "least common denominator" solution for supported databases, they are a subset of the least common denominator (ever heard of a bit data type?).
This is an immature platform. No great IDEs are available (although Aptana/RadRails is pretty good). Oh, and to anyone who says IDEs and the people who use them suck I can only assume you are joking or have never worked on an application of much complexity or size. Try managing 250,000 lines of code with vi. The "Rails uses fewer LOC" argument only goes so far - you don't see over 90% code shrinkage. And those benefits are greatly exaggerated as well. You end up giving back much of the gain in the form of increased testing required by the lack of a compiler and type safety.
The Ugly
Ruby on Rails is not thread safe and runs single threaded. WTF!!?!?!?!?!?! I just about crapped myself when I heard this. This alone is enough reason to never, ever, ever, ... ever write anything other than a prototype or toy app in RoR. Hopefully this will be addressed soon, but it's doubtful given some of the comments in DHH's blog. Who in their right fucking mind would write a single threaded web framework. Anyone remember why Session was so evil in classic ASP? It's because it had to run single threaded. Oh, and Rails community, I have yet to see a problem solved with a single thread that cannot be solved with multiple theads and critical sections.
Check out this informative slide show on how to scale Rails. Basically they have created a platform that cuts your coding down by 20-30%, but increases you deployment and maintenance by 80-150%. As many studies have show, lifecycle costs of any software system are predominantly in the maintenance, whereas initial development costs usually account for only 30% of a a system's total lifetime costs.
The Rails community seems to be largely composed of ex-PHP developers. As a result you have a dearth of trained computer scientists. This results in asinine solutions to complicated problems. Not that you don't see dipshit implementations of things in every single other framework on the planet, it's just that these sub-optimal designs don't become part of the respected lexicon.
As a final note all this fawning over David Heinemeier Hansson (the initial creator of Rails) is a bit unseemly. I'm all for PDAs of hot man-love, but usually I expect to see it outside The Cuff on a Thursday night, not in some drunken rant-blog surreptitiously about programming.
- Asp.Net: C# is a great language, but Postback controls suck balls. In fact the entire Postback model is bankrupt and should be thrown in the garbage.
- JEE: Overly and unnecessarily complex for 95% of real world problems. Pain in the ass to get a new environment up and running.
- Java/[framework of choice]: Too many options and starting to show it's age.
- PHP: Just a bad and buggy implementation of classic ASP.
- ColdFusion: ColdFusion is a sick joke. Use this only if you don't know how to write code and like server crashes.
OK, so now let's talk about Ruby on Rails.
The Good
Based on my analysis of the Rails framework and using it, this is a framework that is optimized for single developers or (very) small teams. I say this because it provides tools to build all layers of the application (data, middle/server, and client) from within the Rails environment. It is built to be your everything for building an application.
Rails is great for prototyping a system or for bringing someone who's new to web development up to speed. It has a tightly structured framework that is well thought out. It also promotes good coding practices via the integrated testing framework.
The design of the RESTful API and routing are top-notch. It is also the first web framework I've seen that provides clean and tight integration hooks for client-side javascript libraries. In every other platform I've used the client side hooks are bolted on as an after though. And they feel like it.
Rails provides a console for dynamically testing the objects. Just create one, invoke it's methods, and have fun. In fairness, .Net provides this with the kick-ass new PowerShell, but doing things this way is not common practice (tho we probably should).
You get gems, which is a kick-ass Ruby thing for installing and updating all sorts of components. Picture Eclipse's add-on functionality, but without the bother of constantly having to manually add new repositories. Find a new cool tool you like, type $> gem install watir.
Rails Engines are a totally sweet idea. Instead of using wizard builders for functional blocks like Visual Studio does, you install and configure whole functional blocks -> user logins, etc.
The Bad
Rails is built to be your everything for building an application. This means it does some things fairly to exceedingly well, and other things exceedingly poorly. Unfortunately, since it is a tight stack, Rails will fight you if you try to use another tool/technique for an aspect of your application.
What does that actually mean?
Well, for starters it tries to be smarter than you for common tasks. Often it is, but your code ends up inefficient. The has-many :XXX / belongs_to :YYY makes it quick to wire object data relationships up, but it leads to tremendously inefficient code. Common reference tables wired up this way will be constantly queried as you use the objects.
Rails treats the database engine as a second class citizen. This may seem counter-intuitive to many people who have read some of the Rails docs about "why ActiveRecord" or are relatively new to ORM frameworks. And it is. Counter-intuitive. That Rails doesn't leverage the database engine in a very intelligent way. The bulk of the meta-data is ignored, or worse, discarded leading to - what's the phrase... - shitty database design.
OK, so what do I mean? Well, if you use the Rails format for managing database creation all of your foreign keys will be thrown away. Data integrity anyone?
Migrations are a nice idea. In practice they suck balls.
Let me see if I can explain it in layman's terms. Problem: Database design changes with the growth/implementation of a project, requiring developers to sync their data models.
Rails Solution: Auto-gen database differences and prompt devs to apply them over the course of the development cycle. Real Solution: Be able to rebuilt/redeploy database at any point from script, both in new state and in "since last checkpoint" state. The problem with migrations is that they are not just a "least common denominator" solution for supported databases, they are a subset of the least common denominator (ever heard of a bit data type?).
This is an immature platform. No great IDEs are available (although Aptana/RadRails is pretty good). Oh, and to anyone who says IDEs and the people who use them suck I can only assume you are joking or have never worked on an application of much complexity or size. Try managing 250,000 lines of code with vi. The "Rails uses fewer LOC" argument only goes so far - you don't see over 90% code shrinkage. And those benefits are greatly exaggerated as well. You end up giving back much of the gain in the form of increased testing required by the lack of a compiler and type safety.
The Ugly
Ruby on Rails is not thread safe and runs single threaded. WTF!!?!?!?!?!?! I just about crapped myself when I heard this. This alone is enough reason to never, ever, ever, ... ever write anything other than a prototype or toy app in RoR. Hopefully this will be addressed soon, but it's doubtful given some of the comments in DHH's blog. Who in their right fucking mind would write a single threaded web framework. Anyone remember why Session was so evil in classic ASP? It's because it had to run single threaded. Oh, and Rails community, I have yet to see a problem solved with a single thread that cannot be solved with multiple theads and critical sections.
Check out this informative slide show on how to scale Rails. Basically they have created a platform that cuts your coding down by 20-30%, but increases you deployment and maintenance by 80-150%. As many studies have show, lifecycle costs of any software system are predominantly in the maintenance, whereas initial development costs usually account for only 30% of a a system's total lifetime costs.
The Rails community seems to be largely composed of ex-PHP developers. As a result you have a dearth of trained computer scientists. This results in asinine solutions to complicated problems. Not that you don't see dipshit implementations of things in every single other framework on the planet, it's just that these sub-optimal designs don't become part of the respected lexicon.
As a final note all this fawning over David Heinemeier Hansson (the initial creator of Rails) is a bit unseemly. I'm all for PDAs of hot man-love, but usually I expect to see it outside The Cuff on a Thursday night, not in some drunken rant-blog surreptitiously about programming.
Labels: rails sucks, ruby on rails
posted by nitpickable at
11:13 AM
0 Comments:
Post a Comment
<< Home