I’ve decided that I’ll use this blog for more technically oriented posts, though there may still be some games and anime related content here.

So with that, let’s get stuck into a fairly simple discussion about web applications. Last year Microsoft announced Windows 8 and its new developer platform, which is based on HTML5 and JavaScript, a decision which caused no small amount of criticism. But it is perhaps the most tacit recognition of the importance of web applications by a company which has traditionally not viewed the web with the recognition it deserved. Internet Explorer 10 is a significant step forward from the horrible days of Internet Explorer 6, infamous amongst web developers for its lack of web standards support.

But what prompted Microsoft to base their new developer platform on traditional web languages and markup formats? To answer that, we have to look at why web applications make sense for many purposes.

The Basics of Web Applications

Web applications can be usually divided into two parts: the front-end and the back-end. The front-end is what you can see, the user interface. By itself, it is pretty barebones. Almost all application front-ends are simply pages to show content, show links, and sometimes show forms to collect and send information. Essentially, the front-end only shows things, and lets you click on things to see other things.

The meat of the application is in the back-end. It is where the front-end gets the content it shows, and sends the information you give the front-end.

Not all web applications run this way, but most of them do. Some web applications, where responsiveness is primary, will run almost entirely in the web browser, with most of the application coded in JavaScript. An example would be deviantArt’s Muro.

An Example

To help you visualise how this separation of duties works, I’ll take an example from my own (somewhat crudely coded and work-in-progress) web application, Timetibble.

If you were to view a timetable in Timetibble, you would go to a web address that looks like this: “http://tt.forrestlay.com/index.php/timetable/view/XXXXXXXX”. Your browser sends a message to my web server requesting to view the identified timetable. The backend gets this message, and returns the HTML code that lets you see a timetable.

If you then decide you want to change what semester that timetable is categorised as, you would enter information in the form on that page and click on the “Update Timetable”. Your browser sends another message to the address “http://tt.forrestlay.com/index.php/timetable/update/XXXXXXXX”. My web server gets the information you put in the form, the backend updates the database that stores your timetable data, then returns you to the first web page.

Advantages of Web Applications

You can see from the example that the web page in your browser is essentially a remote control for a web application. All your computer does is send your inputted information and requests, and renders the result of your requests. All the grunt work is done by the web server.

Therein lies the first advantage. Popular web applications run on web servers consisting of many connected powerful computers. For processor-intensive applications, such as graphics editing or 3D modelling, users could benefit from having access to a server farm.

The second advantage is readily shared data and collaboration. Springpad, a web application that lets me take notes and set reminders, can take product data from Amazon.com and automatically generate a note from the product data. Google Docs lets tens of users work together on the same document, providing several tools to facilitate such collaboration. Perhaps the most useful form of this shared data are the OpenID/OAuth protocols, which lets you log into certain websites using your Google Account or Facebook account in as little as one click in some cases, and even let the website draw your information from those websites to complete registration in one click.

The third advantage is quick, small application updates. If developers want to update a web application, users won’t be required to download and install a possibly hefty update. Updates to the back-end are practically invisible to users, while updates to the front-end will simply show up when a user browses to the appropriate web page and downloads that page.

The fourth advantage is the wide availability of web browsers, and in particular, web browsers with high web standards support. From desktops to cell phones, most people have access to something that can render a web page within their grasp.

There are of course disadvantages (and other advantages) to web applications, particularly in relation to the security of data available on the internet (the popular maxim being nothing on the internet is safe). Web applications are not suited for all purposes, and these advantages and disadvantages will affect different applications differently, logically. But this field of software applications is expanding rapidly for good reason.

Insomniac Games: An Engine in a Browser

Insomniac Games provides a neat example for the first advantage (even if it is not a true web application), moving the front-end user interface for their engine tools to the web browser. For Insomniac Games, the benefits are even greater than for a typical consumer. Tasks that require intensive processing power now run on powerful networked servers rather than on individual workstations. The assets created by artists and modelers will be stored on network shared drives that are instantly available to level designers. Updates to the UI will be smaller and easier to distribute amongst hundreds of workstations, while updates to the back-end will only need to be distributed to the servers.

While having web interfaces for business applications is nothing new, having a web interface for something as graphically and CPU intensive as video game development tools is on a different level. It demonstrates the potential of web browsers which once struggled to play a video file without stuttering.

Bridging Desktop and Web Applications

While giving a desktop application a ‘web’ interface may not bring all of the above advantages, it brings enough to make it worth considering. This is especially suited for applications which would be augmented by integrating social features or by scraping data from online sources.

Battlelog: The First of Many

Last year’s Battlefield 3 was a great success, and a great addition to the Battlefield franchise. But it also represented an intriguing change in the potential that web applications hold for the everyday consumer. Battlelog for the PC version of Battlefield 3 is not only a stat-tracking website and a social networking tool for players, but the server browser and game launcher.

It is not perfectly implemented, it’s most significant omission being the ability to modify loadouts out of the game, but there are significant benefits in implementing a web interface for these out-of-game elements. DICE is able to issue small, quick patches to implement out-of-game functionality (such as increasing the number of filter options for the server browser). Access to the server browser and all other Battlelog functionality, and in turn to the game itself, is quicker than any in-game alternative could achieve. It is impressive in how Battlelog achieves it’s functionality through commonly used web technologies (apart from the use of a plugin to launch BF3 from the web browser and for voice chat capability).

Regardless, it is possible that soon we could see many applications move to a web-based user interface. Right now they would have to use plugins to interface with the executable that would process user interaction, but perhaps soon browsers will be able to natively handle protocols for accessing applications installed on the client-machine. Internet Explorer 10 may already possess this ability for Metro apps, though it remains to be seen whether Microsoft can design a standard that other organisations will adopt.

Sometimes, A Bad Idea

The stand-alone desktop application will almost likely never go away. Even if a browser was capable of showing a responsive UI for the full version of Photoshop or Premiere, there is a deeply ingrained perception that something in a browser will never be as responsive and/or fully featured as a stand-alone application. Which is okay, unless in the future Chromium OS becomes the number one OS (perhaps because of the scenario in .hack?).

But with the introduction of Windows 8, one should not dismiss the new HTML/CSS/JS-based developers platform without looking at the examples of Battlefield 3 and Insomniac.