Web Design World Buzz

Ruby on Rails

The Web world has gone nuts for Rails.

I'm somewhere between early adopters and early majority (?) on this one, I've been working with Rails since just before the first Slashdot article on it (which was just a mirror for the ONLamp article), but I was aware and watching since Jason Fried & co. started talking about Basecamp on their blog.

What is Rails? Rails is a framework for building Web applications.

What's a framework? Honestly, that's a good question.

Hang on, let me back up a second.

Much of the attention devoted to Rails on the blogs so far has been from a "sophisticated" Java developers' perspective. Or, from the perspective of someone who's never developed a Web app before.

I'm somewhere in between.

The first "application" I ever used in a Web context was a wee bitty perl script "visitor counter" program. (Everyone had these in the late 90s, it was a fad.) It was a major pain in the asphalt to set up. The server had to be configured just right; it wouldn't work the same on Windows as on Linux, you might have to — eeep! — re-write the code a little.

And that was basically it, for a long time. A few years later, though, and I'm working with the Dispatch and they're having too-much-work/not-enough-employees issues. Most of the problem was that they were doing *everything* the hard (manually copying-n-pasting) way. I knew about PHP (it was the trendy new app back then) and started putting PHP to work. It all started with a little script to put the current year in the copyright line at the bottom of the page. Then something to add a "last updated: Apr 5, 2005" line at the top of the page. And it grew from there...

Today, I'm building much more sophisticated systems: shopping carts, content management, little blogs, etc. Like any "good" programmer, I've started building a collection — a library, if you will — of useful snippets of PHP code that I use everywhere. For example, a very common thing in Web design is a little form where you enter data (User Name: _______). And a very common application function is to fill in that form with some default information. But not just any default information. Say this is one form in a long page, and the user has made an error of some sort ("Invalid credit card number!"), whatever you do, you don't want to lose the hard work the would-be customer has done entering in his name, phone number, etc. So, you need a little function that (in pseudocode) says:

default = (if (doIHaveUserData?)) then (UserData) else (blank)

And you do this all the time. Every little field. So, I wrote a little re-usable code (its called "inputmaker") that handles the "hard work". I just have to tell "inputmaker" what to do, and it does it. I have similar code for connecting to databases, reading data from files, and sending email. Most programmers do this. And, most programmers solve the same problems. (This is why, in part, I think, the Open Source community works as well as it does.)

So (at least, on one level), a framework is just a collection of these little code tools. Usually, I hear about "frameworks" in the context of a language that wasn't really designed/intended to be used in Web development. Which makes sense here, Ruby is/was a general purpose language, not a Web tool. Rails makes it much easier to use Ruby on the Web. PHP, on the other hand, was (at least, as far as the urban legend of PHP would have it) designed from the start to be a language for Web development. Things that some other languages have to add on in frameworks are actually part of the native PHP base code.

But that isn't to say that PHP is perfect. (See my "inputmaker" example above, whereas Java and Microsoft's .Net include something similar in the framework already.) In general (and I think this theme will come up again and again as I use Rails), Rails takes a lot of the "hard work" of Web development and whisks it away. The degree to which this is a "good thing" will depend on how successfully it handles the work, and how much control you want to/need to have of the way your app works. For me, I was really comfortable in "PHP mode", I knew where things were and how to use them. And as a fairly long-term Web guy, I tend to think in Web terms. PHP feels closer to the bone, so to speak, than Rails does.

For [a rather technical] example, in Rails, you get user input from something called @params, whereas in PHP, user input comes from $_COOKIE, $_GET, $_POST, or $_SESSION, depending on where it came from. Rails' @params is nice, in that you don't have to "worry" about where the data came from, but I'm used to it already that I don't think I spend any extra brain power figuring it out. (Yeah, okay, every now and then, I get burned by a GET/POST problem, but it's sufficiently rare.)

Okay... but that's not all. Rails is also another kind of framework: An established system of "best practices". Basically, Rails also provides a structure for how one ought to program for the Web. Rails strongly enforces a Model/View/Controller pattern, which is, pretty much, the only pattern worth bothering with on the Web. (Stateless system, yay!)

In a way, I'd already begun marching in this direction on my own, with PHP. The shopping cart system I built at work is used on two different sites, and it "just makes sense" to lay them out in a similar manner. And new projects I've built have followed a similar pattern. I also fell in "love" with Apache's mod_rewrite (and short, sexy URLs) long before I met Rails — and using mod_rewrite really encourages using M/V/C.

On the other hand, though, I often find Rails' use of M/V/C to be stiflingly strict. Some part of it is my work lately: I haven't worked on a "Web team" in a little while; it's just me right now. I think M/V/C would work really, really slick in a larger team, where different individuals or even groups of developers were responsible for each M, V, or C. On my own, though, it's often a headache just to delineate whether some new function belongs in the Model or the Controller.

In a larger sense, part of my adaptation to Rails, is getting used to its way of "seeing" the Web, and the role of the scripting language on the Web. From my perspective, coming from "visitor counters" and PHP, the Web site server "pages" to the user and the scripting language makes the pages "smart". Someone who's cut his teeth on Rails alone is more likely to see the Web as "software" that takes "user input" and responds with formatted output.

Oh — one more thing. Rails offers another interesting (and highly touted) feature called scaffolding. Set things up just right, type a few words at a command prompt and boom! Rails automagically builds a fairly functional database-backed Web app. For ridiculously simple Web sites (simple blogs, cookbooks, etc.) you could theoretically have a working app in about five minutes. At least, that's what Rails' blog-powered hype-machine wants you to believe.

Except... It's not really all that. I'll grant, it's pretty slick. I like. And I'm sure I'll be making use of it, at least in small doses, over time. Rails takes away a lot of the tedium of making Web sites. But it doesn't take it all away. I find that Rails' scaffold-produced sites are functional, but just enough. Making a really nice site still takes hard work and design, and there's little that magic scaffolding can do about that.

All in all, I am working to learn more of Rails. At the very least, I'm picking up on some good ideas on how to build/layout code — even if I end up working in PHP again in the end. And I do like working in Ruby — its a sleek, sexy language if ever there was one. Most of my issues will probably disappear with familiarity, but... honestly, if I weren't being sucked into the "great new thing" (and, actually, if I didn't have an app in mind that Ruby would be perfect for) I think I'd be sticking with PHP. Smarter, more organized PHP, but... I guess that "close to the bone" thing is more comfortable, for me.

Ajax

The other big buzz word right now is Ajax (named by Adaptive Path's Jesse James Garrett in the above link, though the name is still controversial).

If you've been to Google Maps, you've seen Ajax.

If you've ever tried Google Suggest, you've seen Ajax.

If you have a GMail account (and if not, ask me, I can invite you), you've seen Ajax.

So, what is Ajax? Ajax is the name the designosphere has given for a sleek combination of browser-side Javascript and server-side XML that produces sleek, fast, highly interactive Web sites.

In a "normal" Web site, when you click on a link, your browser sends a request to the server, which then sends a response, which the browser transforms into the site you see. It can take time to make the round-trip, though, where you, the user, see a blank screen and a message like "Waiting for..."

Ajax attempts to shorten the wait. When you click on a Google Map and drag the screen around, Javascript sends a request (in the background) to the Map server, and fills in the map with an image when the server's response comes in. Meanwhile, you've got the screen in front of you the whole time; no waiting.

Ajax's primary role in the new world it's exploded into, seems to be making stuffy Web sites more interactive and engaging. There's a potential here for new guys, with the new interface, to get a jump on the old battleships of the last Internet age. Mapquest had the stranglehold on online mapping and directions for ages; Google blew them out of the water with one shot: Faster. Okay; maybe two: More interactive.

How about interactive eBay? Counts down the time remaining in the browser window, shows the bids ticking up as you watch?

What about interactive CNN? Updates news headlines while you watch, without reloading the page? (Ever had the page re-load just as you were about to click on a link? Never again!)

What I wouldn't give to never see another embedded Java applet. Ajax might make that dream possible.

I think Ajax is great stuff. I've got a couple of ideas of how I can use it, here and there, but — frankly — I think the designosphere's reaction is hyperbolic. I don't think this will significantly change the Amazon experience; I don't think you'll see all-new shopping experiences (remember how VRML was supposed to open up a new era in 3D shopping malls online?)

I do, however, think you'll see some Web apps that most designers wouldn't have thought possible a few years ago. Ajax isn't so much a new technology, but old technologies packaged up into a very convenient, organized collective. (And, did I mention that Rails now has Ajax functionality built-in, out of the box?)

(Oh, and for the record: I do kinda hate the name [cleaning product], but if it helps the discussion to give it a name, that's just fine. Rolls off the tongue and all, too.)

Permalink • Posted in: web, design • Comments (6)