Ruby Tuesday: Pitfalls of Prototyping in Rails
My last Ruby Tuesday post was pretty laudatory regarding prototyping in Rails. In this post I’m switching gears and exposing the pains and limitations …
The development team at my current startup is composed of engineers and designers, basically I make everyone on the team write code 😀 I understand that Rails’ benefit is in thinking from an MVC mindset. But because it integrates all components its requires that all developers have some knowledge of a high level language (Java, Ruby), front-end technologies (HTML, CSS), and an understanding of databases. While it doesn’t require them to have depth of knowledge I think the tight coupling makes it hard to separate the layers.
The following are the three limitations I’ve been experiencing with Rails:
- Integration – when it comes time to integrate HTML or design changes, designers and front-end engineers need to work in the same space i.e. the same .erb.html file. Yes I know it doesn’t require a painful and time-consuming compilation process like XMLC or Velocity. But its easier for the designer to change the look and feel using XMLC or Velocity because they have defined a set of DOM objects. With Rails designers have to understand views and partials.
- Convention over configuration – the speed of development with convention over configuration Rails seems to come at the price of normalization, meaning there is not foreign key construct in Rails. You as a developer are required to configure this yourself along with other database constructs like unique constraints and indexes.
- Deprecation – perhaps its just me, and I’m used to Java versions being released every year or two, but it seems like there are a lot of constructs that are deprecated between Rails versions. The book publishers can barely keep up with the changes. The other is that some of the constructs that are deprecated which I think are quite large i.e. scaffolding.
Despite these pitfalls I do advocate Rails as a prototyping platform. The learning curve isn’t steep, and convention over configuration improves the progress developers can make in a day. I’d also like to learn more about how people have addressed these pitfalls as their prototype matures. What have been some of your experiences and approaches to dealing with Rails as you transition and build out the product?
