Andre's Blog

Personal blog of Andre Perusse

JavaScript: Rise of the Single Page Application

Last month I wrote about the current state of HTML application development and how it has changed drastically over the past five years. In that post I mentioned a lot of technologies that have evolved, but one area in particular that is in the midst of an amazing sea change is where the user-interface logic is executed.

Historically, most web applications have used a server-templating model where an application server such as Microsoft's ASP.NET processes data and emits it as HTML which is rendered on the client. If the user clicks a button or link on that web page, an HTTP POST or GET operation is performed on the application server and a completely brand-new HTML page is returned to the client browser to be rendered again. The problem with the server-templating model is the annoying screen refresh that occurs between postbacks and page re-draws, and the amount of time required to re-render the new page, often when very little actual data on the page has changed. AJAX techniques can aid immensely with this problem, only updating the areas on the page that have changed. However, this is only half of the solution and a further step must be taken to bring a truly rich user experience to a web-based application.

Enter the JavaScript "single-page application" (SPA). This is a relatively new technique (well, Google's GMail has been using it since 2004 but it's only now starting to catch on in the mainstream) where only a single HTML page is downloaded to the client browser and all further updates are performed by JavaScript code. In fact, the single page that is downloaded is often no more than a shell used to bootstrap the JavaScript application. Once initialized, the application runs completely in the browser with no further HTML pages generated by the server. Instead, the JavaScript code is responsible for creating the HTML DOM elements and binding data to them. This reflects a truer image of the client-server architecture that has existed for decades and is the model most frequently used in Flex and Silverlight applications that run in a browser plug-in (no HTML).

This is not to say that the application server no longer serves any data, it simply no longer wraps that data in HTML. That is the job of the SPA running in JavaScript code on the browser. JavaScript will issue a remoting call to the server for data, which is most often returned in JSON format. Using a client-side databinding framework (such as Knockout.js) this data is then bound to an HTML construct. Any changes are sent back to the application server, once again in JSON format, where the server then performs operations on the data, such as updating a database. The result is a more responsive user-interface that works much like any other rich application developed in more traditional client-side technologies.

From where I'm sitting, 2012 is shaping up to the be the year of the SPA. There has been a tremendous explosion in the number of JavaScript libraries and frameworks designed to provide more power to the client-side developer. Which is truly fantastic - front-end developers have more capabilities at their fingertips than ever before, and it just keeps expanding every month. However, the exploding popularily of JavaScript components is also part of the problem. Many, like me, have no idea where to start. There certainly isn't a clear winner in the race to establish the de-facto framework, and in fact many existing frameworks are happy to just provide what they believe is necessary to fill a given need. Assembling all the pieces to create a complete framework for a web application project is still a task left to the developer.

Which is not so much a bad thing, but compare this with the RIA frameworks of Flex and Silverlight. Using these rather completely-featured frameworks, you may wish to incorporate the odd component or pattern and maybe some additional UI controls, but JavaScript SPA developers have many more choices than that to make. One of the big problems with JavaScript in the browser is that it was never designed to house large applications. Modularizing your JavaScript code involves a peculiar set of work-arounds to address the fact that JavaScript is more object-based than object-oriented (though some may disagree), and requires the use of closures to achieve some degree of modularity. Among other things, this often leads to what can best be called namespace-collisions since all variables defined outside of a function in any script file are invoked in the global namespace. So when you bring all these pieces together in your application you will often find conflicts that you must resolve yourself.

Despite these challenges, the SPA is emerging as the preferred methodology for developing rich and responsive applications in a browser (in no small part because Flex and Silverlight aren't supported on increasingly popular mobile devices). User-interface control vendors are now beginning to offer commercial JavaScript control libraries that have no particular server requirement at all - they consist only of client-side JavaScript code. Developer productivity is still a challenge in this environment as IDEs still have a difficult time with the dynamic nature of JavaScript. But advances are being made and the SPA space is absolutely electric with increasing developer interest and daily news on technique improvements. Indeed, it will be very interesting to see and participate in the SPA revolution over the next couple of years.