Build Web Applications In Static HTML
September 15, 2009 — Code
If you enjoy writing small web applications in web microframeworks like Sinatra or web.py, consider this: no matter how quick and easy it is to write and deploy, your app will never be as quick and easy as no app at all.
Every feature you implement means more code to maintain, and frequently you use the same feature for many web sites, resulting in a lot of duplicated code. You can package a feature as a plugin or gem for easy propagation to all of your sites, but upgrades may still require adjustments to database structure or application code, and you still have to re-install the plugins or update your gems manually which can be very time consuming if you have 20 or 40 sites sharing the code.
What if you could forget about writing web applications entirely and just deploy some static HTML files, like in 1995 before you learned Perl?
Programmers have been using services like Pastie and Gist to add syntax highlighting to their sites which, like this one, could be implemented with static HTML. There are also services which offer entire customer feedback and discussion systems like Uservoice.
In addition to pulling data into a site, we can push data out for processing and possibly for re-display at a later time. You’ve likely heard of Google Analytics, which collects and analyzes web page usage data in this fashion.
These are third-party solutions so the providers own your data. What I’d like to see, and what I suspect we will start to see soon, is open source versions of this type of service which would give us back our data, as well as control of the interface. Rifgraf is one such open source web service which will collect and graph whatever numeric data you send it (like a simple, generalized Analytics).
Interface-Oriented Design is a book published by Pragmatic Programmers which discusses many of the problems involved in designing such services. I recommend it to anyone conteplating getting involved. It’s an oldie but a goodie (still relevant, and will remain so for a while since it’s about design principles rather than specific technologies).
The Big Caveat
However, I believe—and this is very unofficial—that Google will eventually index this type of content. I have seen evidence of their spiders on my own sites poking at AJAX-only URLs. Repeat: I have no evidence that this means anything, I am simply guessing. If I were Google, I’d be working on it.
If you’re still with me on this, let me be more specific. I believe that Google will index content added automatically after a page is loaded. This includes all of the technologies I’ve discussed so far which simply fetch content as they are rendered by the browser. I am not as hopeful about content that is added to the page after a button or link is clicked (such as with AJAX pagination).
I encourage you to consider the idea that functionality, and even data, can live outside of your web appli…I mean HTML files. We’re accustomed to avoiding code duplication within a project, but what about code duplication within our portfolio? By considering all of our sites as a unit I hope we can lessen the pains of maintenance and prevent long-running sites from turning into un-upgradeable relics that we “never want to look at again.”
If planned carefully, I think we can use this kind of distributed application design as a way to simplify our sites, even if we don’t go all the way back to static HTML.
More CodeNov 06, 2008 Form Builders in Rails
Oct 06, 2009 Simulate Has Many Through HABTM
Dec 09, 2009 Single Table Inheritance in Rails
Jan 18, 2010 Anatomy of a Ruby Web Application
Mar 09, 2010 Sending Email From Your Web Site
Apr 13, 2011 What the ɊȱɁͲ Is UTF-8? A Character Encoding Primer
Jun 29, 2009 Punting on Feedzirra Dependencies
Sep 21, 2009 How to Cause Useful Accidents