2009-03-10; published 2020-07-20
Postgrails is a sniglet I created to describe my journey as a developer.
Postgrails means that I’m done looking for the end-all in web frameworks. I want clean, light, fast, efficient tools for doing the work of web development that don’t try to mother me, don’t “abstract away” the underlying technologies, and generally stay out of the way as much as possible.
I have been specializing in web application development for several years. In the beginning, I had read Philip and Alex’s Guide to Web Publishing and responded by diving in with the OpenACS web framework. ACS was one of the earliest “full stack” web frameworks, and it still performs admirably, powering such sites as photo.net and .LRN.
Then, I moved to Python (because I like Python a lot) and began working in mod_python/Apache to create my own “full stack web framework to end all others” which, like every other individual project of the kind, died with a whimper rather than a bang.
About that time, I ran into Ruby on Rails and said, “Hey, looks great!” and dove in. That was around August 2006. Rails is a great framework in many ways, and it taught me a ton of things that I needed to know about web development and good practices. And with it I have gotten some nice projects off the ground.
I recently had an eye-opening experience, however: I deployed in staging an application that I have been working on for quite some time, on a public server but protected under a login until it’s ready for production. A couple of days later, I received an autogen email from my virtual server hosting company telling me that my usage for the month was going to cost more than the pre-pay level that I am at. I did some sleuthing, and found that Rails is using an enormous amount of resident memory (RAM), which is very pricey in the shared VPS world.
Rails loads everything including the kitchen sink, whether you need it or not. That makes it possible to do all the neat magic that they do. But it sure is expensive when it comes to deployment.
Magic. That’s at the heart of it. Many web frameworks try to do so much magic that the developer doesn’t really know what’s going on under the hood at all. When there’s a problem, I get a stack track a mile long. It’s always a problem in my code, a testament to the quality of the Rails team. But sometimes it’s really hard to figure out what’s going on, because the magic hides the implementation from me rather fully. That’s because Rails is an incredible abstraction on top of Ruby, HTTP, SQL, HTML, and Javascript. As an abstraction, sometimes it’s leaky. It’s also an expensive memory hog.
Most web frameworks, in pursuit of magic, seem to create a more-or-less thick layer of abstractions over the underlying technologies. Rather than defining database tables in SQL, you define them in Ruby and then let Rake generate and execute the SQL. Rather than interacting with the database in SQL, you use Ruby code. Rather than writing Javascript in Javascript, you write it in Ruby, which generates the Javascript. And you never even see HTTP directly. It’s all abstracted away.
To develop applications in a particular domain, you have to learn the technologies that are appropriate for that domain. For web development, that currently means that you generally have to learn (X)HTML, CSS, SQL, and Javascript. You also need at least one server-side scripting language to use in programming the server to interact with both requests from web browsers and with the database.
What web frameworks like Rails try to do is to get you writing everything in the language of the server scripting language. That’s a big mistake. It doesn’t absolve you from learning the other technologies — you need to understand all of those languages in order to develop for the web. If you learn those languages and technologies, you can use them in any framework. With a thick abstraction layer, you have to learn a bespoke language that isn't portable and doesn't help you understand what is happening under the hood with HTTP, SQL, etc. It does make it seem easy to learn, but it actually makes things harder in the long run.
Instead of doing magic and providing thick abstractions, a web development platform should provide functional tools and as thin a layer of abstraction as possible to enable developers to get their work done.
When maturing as a developer, one gets tired of the be-all solutions, the magic and the abstractions, and just wants a good toolkit that helps one to develop fast, efficient applications. That’s what Postgrails is all about.
Editor's Note: This post was originally published elsewhere on March 10, 2009. Now it's ten years later, so I've lightly edited it to bring it up to date. However, I haven't revisited Ruby on Rails since then, so it's possible that the things I criticize here have been improved. —SAH