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.
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