Rails 3.1 is soon to be released, and with it comes two new abstraction libraries – CoffeeScript, and S(ass)CSS. These libraries are used to generate Javascript code, and CSS definitions respectively. While abstraction libraries are nothing new to Rails, the inclusion of two more got me thinking about the direction that Rails stack is heading.
CoffeeScript’s syntax seems to be to make Javascript as Ruby-ish as possible. It describes Javascript’s curly braces and semicolons as embarrassing.
SCSS aims to address some of the repetitive elements of CSS through the use of variables, nesting, and mixins. This feels more acceptable to me than CoffeeScript, but my first encounter left me burned.
A few other abstraction libraries of relevance: Haml aims to generate HTML without the use of HTML tags. Additionally, Squeel‘s (MetaWhere 2.0) aim is to remove all SQL from your projects.
So what am I bitching about? Abstraction is a good thing right? I see two categories of abstraction. The first being the “good” kind, that allow you to be completely ignorant of the underpinnings. For example, Ruby converting down into machine code.
The “bad” kind of abstraction are the substitution of a language with a DSL. This creates a lot of issues starting with development and debugging. In the case of CoffeeScript and SASS, you have to compile the DSL files into Javascript, and CSS files. I feel like this compile step is a step back from what we gain working with dynamic languages like Ruby, and Javascript to begin with.
Development in these libraries also requires that you understand both the DSL of the library, as well as being familiar with the language of the generated code. This additional skill requirement adds time to a project, and raises the entry bar for new developers. Its difficult to be proficient at a language, and a DSL that generates that language at the same time. A Ruby developer told me yesterday that he was surprised at how rusty his knowledge of SQL had gotten. Its shocking to me that a web developer would struggle with SQL, but I think its an accurate sentiment on which many Rails developers would agree.
Another casualty of abstraction is performance. Not only is the generated code sub-optimized relative to coding it by hand, it is also being run through through more system calls to get there. You can either compile up front (CoffeeScript, SASS), or you can incur this penalty on-the-fly (Haml, Squeel).
While none of the libraries are a requirement of web development, when working on a team that uses these technologies you are expected to produce consistent code. Even though these libraries let you execute “native” code, doing so is discouraged because of the availability of the DSL. The syntax for embedding native code (if its even allowed) is often cumbersome, and loses editor functionality such as syntax highlighting and parsing.
Since when did Ruby on Rails web developers stop working with SQL, CSS, HTML, and Javascript? I am beginning to feel like the Ruby camp is becoming the far left extremists of the web development world. The web is built on these core technologies, and the benefits of abstracting them doesn’t seem to outweigh the costs.
Zone of Mr. Frosti 
Squeel’s not for everyone, and you’re certainly entitled to your opinion, but my aim for it isn’t just to eliminate SQL strings from Rails apps. It’s to allow us to change the way we think about query problems, when it’s convenient to do so.
Interestingly, in early tests I found that depending on what kind of stuff you’re doing, Squeel can actually be faster than stock ActiveRecord.
I’m not sure that still holds true today, but I think it has some pretty major wins in terms of code readability. I don’t really think it enables people who don’t understand SQL to do incredible things, but I do think it helps those who do avoid dropping down to a string to do something as simple as a LIKE.
See http://metautonomo.us/projects/squeel/ for details (especially the section on Predicates).
LikeLike
@Ernie – Thanks for responding. There are certainly benefits to using MetaWhere, however I find myself in an awkward development pattern when using it. I find that I am writing out my SQL query, then transcoding it into MetaWhere syntax. When I see a MetaWhere SQL query, I transcode it back into SQL to understand it. I find this to be the case with the other abstraction libraries as well.
I question if this is the intended pattern, since you mentioned that one of your aims is to change the way we think about query problems. Perhaps MetaWhere’s use case is in smaller pieces of SQL that can be chained together (like scopes) for an aggregate effect?
LikeLike
@Ben — exactly. The idea is that this allows you to maintain the individual conditions of your query in hashes, for instance, while still accessing more powerful comparison operators. You can merge to them, maintaining the nesting level to traverse multiple associations, and know that the proper table name will be resolved for your conditions.
In short, there’s a lot of value in holding onto alternate representations of your SQL syntax until the last possible second, when it needs to be sent to the database.
LikeLike
Sweet fancy Moses! It’s as if you actually heard some of the things I said.
LikeLike
I completely understand extraction in the case of say active record, but when talking about something like CSS and JavaScript, the abstraction doesn’t make sense. Abstractions benefit in my mind is it makes the code work independent of the tool used below it. You could switch from MySQL to PostGre without major issue for instance. What do you swap out for JavaScript or CSS?
LikeLike
Pish posh. I know, I know, a java developer saying pish posh to that shit. You know what? I still write all that shit out. You know why? I tried fucking GWT which tries to do just about everything you mentioned. It’s a piss poor substitute not to mention freeking compile times.
Anyways enjoyed reading about it 🙂
LikeLike