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

Enter HTML5.

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.

Once the page or data reaches your web browser, there are three technologies running inside your web browser that interact to render the webpage for you: HTML, CSS, and javascript. 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.
• Javascript is the functional layer of the page. It says: “When you click this button, you should make a popup area that shows a slideshow.” Javascript has become quite powerful and through the work of the web browser makers, now extremely fast, so we can now build full applications like GMail that actually provide an experience not unlike a desktop application.

So, when I say two codebases, I mean that we write code for the web server in PHP or Ruby on Rails to make it able to deliver the pages or data needed, but then to provide the richer experiences many of us have come to know over the past few years, we rewrite portions of each application in javascript to be able to function in the web browser to provide those experiences — thus, two codebases: PHP+javascript or Rails+javascript.

Wouldn’t it be great if we could do everything only in one language? However, no one runs javascript on a web server or PHP/Rails in a web browser. It doesn’t exist. Or rather, didn’t…

But wait, there’s more!

I do feel a bit like I am doing this as an infomercial — perhaps I’ll film this and put it on community access cable at 2:30 a.m.  Last year, I sat in on a session that talked about running javascript on a web server — wait: javascript on a web server? That sounds like an unholy mixing of server and client side doesn’t it?

But it was true. Running javascript on the server was right-out-of-the-box new then, so young and so not yet ready for us to use in a serious manner. (Bleeding-edge technologies have a higher cost in failures and code changes as the language develops more rapidly than once an acceptance threshold has been met and it becomes more stable.)

But javascript on a web server was oh so attractive. When developing a new application for Lewis & Clark, we could write it using just one codebase. The code that runs on the server, also runs exactly the same in any client web browser.

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.

As I mentioned, running javascript on a web server wasn’t ready last year. It was interesting, but too bleeding-edge to be useful for us. However, I took special care to follow up on it this year and I am happy to report that it’s time. There’s been huge growth in the project and so today I am installing javascript on one of our servers to begin building new and converting some of our existing applications.