SXSWi Report: One Application Codebase
By David McKelvey
While I love my iPhone as much as the next person — and perhaps even a bit more — the proliferation of smart phones, tablets, large displays, netbooks, laptops along with the old standby desktop has made developing an application able to serve many/all very expensive. Each device requires its own set of programming code in a language specific to that device.
Codebases are expensive.
Imagine this scenario, you want to build an application, say a new Source, which will of course be available as a website. But, we’d like to also display a similar view (technically) of campus news/events on the ten 42″ displays arriving on campus this summer, and what about having something available for tablets and smart phones? Creating a native application for major smart phones is three to four codebases alone.
With each new codebase, you will double the amount of time (at least) a single feature update to the application as whole takes — clearly not a great idea when you have a small staff, as we do. However, there is an alternative path developing. (It’s early, but right about the point where we can jump in and see benefits.)
You might have heard about HTML5 — dubbed the flash killer by some? Well, all flash versus HTML5 aside, HTML5 is simply the next revision of the standard structure that is used to create websites — nothing more or less. While HTML5 is not yet been finalized by the consortium writing it (and thus not fully supported by web browsers yet) some of it has already been implemented and gives us enough of a resource to begin using it.
The changes in HTML5 give us a great new toolset for developing robust applications that live in a web browser. If you’ve ever used Google Docs, GMail, or even OfficeLive, you’ve seen where we’re heading. The benefit here is that with the new features available to web/application developers, we can write an application in a single codebase and have it not only function, but be responsive to the device on which it runs.
This means that we can write one set of code that will work across all/many of the client devices which we choose and that gets us down to two codebases. Now, you’re asking yourself why two? I though we were down to one? Read on.
Server-side, client-side, what?
I’m going to get a little technical here, but promise to keep it sane. Stay with me.
This is the server-side.
Web servers are really just bigger versions of the computer that you tote around or that lives on your desk. Currently, the Lewis & Clark web servers run software that takes content stored in databases (like user information, news, events, etc.) and files on disk (like web pages) and depending on the location in the website, mashes these resources up to produce a webpage or structured data that is delivered to your web browser in under 1.5 seconds. I think that is pretty amazing. (Note: 1.5 seconds is our target minimum home page speed via broadband. Really, we like it to be under a half second.)
We use two primary languages on the web server to do this: PHP and Ruby on Rails. For instance, LiveWhale is written in PHP, the search engine is Rails. Both languages are open source and have been developed for a number of years. (I started coding in PHP a decade ago, when it was already not young.) This is the server-side.
This is the client-side.
- HTML is the structure — the content. If I were to anthropomorphize HTML, it is the part that says: “Here is a paragraph that says ‘Hello world.’ and after it, show a link to the home page athttp://www.lclark.edu/”
- CSS, or cascading stylesheets, is the design or styling of the page. It says: “Make that paragraph text align to the left, and make the font Helvetica Neue, 18 point” among many other attributes, including many that tell the paragraph where to appear on the page.
But wait, there’s more!
What’s more, rather than sending a subset of code to the web browser just to handle select tasks as we do now, we could send the entire application code. The application could then run in your web browser and be more responsive to your needs, only communicating with the web server as needed and only for data. (Sending/receiving data costs less than a whole web page.)
This is faster and better for you, in that the application is more responsive, and faster and better for newmedia since changes are now less expensive.
So what, if it’s not ready.