Wednesday, August 1, 2007

Rails and I

This is absolute craziness. I cannot stop thinking about development in Rails. I work with .NET in my daily job, but Rails has occupied every other piece of my spare time. Now that I think about it, this is how web development should be. Now, I know that sounds like a fanboy-ish thing to say. Maybe you're right, maybe not.

My current job requires me to spend time in .NET 1.1. Before that, I had to work with .NET 2.0. While the latter is much better at helping out the web developer, it does not compare to Rails. Of course, all of this is documented elsewhere, so I want to just share my experiences.

Views to the max

The simplest example I can think of off the top of my head is building views (HTML ones, not database views). While Rails has a fairly well laid-out convention on how to build a view of data, such is not the case in .NET, especially 1.1.
I've recently had to learn a new data model, as well as re-introduce myself to 1.1 and I was shocked at how hard it is to set up a simple view in ASP.NET 1.1. While I was mucking around with DataGrids, DataGridItems, manually setting up DataSets, etc., I reflected on how easy it would have been to do this in Rails. Hell, I would have appreciated just the ORM part of it, if not the conventions and the MVC way of doing things.

Of course, a lot of this is the environment. Where I currently am, there is an over-reliance on stored procedures. I am not against the stored procedures per se, but if I see a 3 line SELECT query being bundled into a stored proc, I lose my mind. Not to mention that the 3-line SELECT query gets its data from a database view which consolidates a myriad of database tables. Even a query that simple takes over 5 seconds to run. UGH.
When I think about it, I come to the conclusion that these people NEED Rails. You see, since Rails enforces a default way of doing things, it's harder to f**k things up. Not impossible, mind you, but harder. There may be a bit of flexibility lost, but when I look at where the unconstrained lead developer's mind can take me, the misery it can cause me, I'd actually love to have him constrained to a set of conventions.

I love templating

Templating, is
to me one of the most important features of Rails. Again, speaking from experience, whereas .NET 2.0 has a template engine of sorts, it doesn't compare to Rails. As for .NET 1.1, well........put it this way, I've seen what a programmer can do when he needs a feature and thinks he's smarter than the people putting together a framework. Again, lack of standardized features within a web framework has caused someone to go off the deep end (and I mean, the deep end. This guy has managed to bypass how ASP.NET operates and replicate its rendering capability, all for the sake of having a template for web pages. I shudder every time I think about it.).

Can you say, Javascript integration?

JavaScript integration rocks in Rails, as well. Now, where I am currently, there is no such thing. The "template" created by someone here has the path to a JavaScript file hard-coded. Now, I'm not talking about a relative path, no, I'm talking about a nice absolute one.

However, I do have experience trying to integrate a JavaScript library at a previous position. Back then, we used a very early version of the Dojo JavaScript library (0.2, I think). Huge thing, this library. Also, our "clever" lead dev decided to freeze the library at that version, though as it matured, the Dojo library/framework really came into its own. That is beside the point, though. We experimented with different AJAX libraries in order to get the desired functionality. All of the libraries we tried (AjaxPro, Anthem.NET, even Atlas) did one thing good that the others didn't. So we ended up with 3 of them. Dropping Dojo into the mix to have file uploads without having to refresh the entire page, plus using its effects features, caused havoc, as it could have been expected. This is what impresses me about Rails. The core developers of Rails managed to integrate a fairly full-featured JavaScript library, AJAX-enabled and all, into Rails in such a seamless way that one does not need to think about whether or not JavaScript calls are going to work, but rather how to use this wonderful JavaScript library to his/her advantage.

Conclusion

Of course, there are whole lot more features that I have not covered here. As soon as I learn Rails more deeply and have a chance to compare its implementations to other frameworks/technologies, I will write about it.

Until then, I hope that you enjoy using Rails as much as I do. And if not, well, it's your loss.

Really.

No comments: