Software in context

Tags


Evolution of the Single Page Application — Part 2 of 2

28th October 2014

Recap. Part 1 of this series introduced the concept of the Single Page Application: a new approach to designing fast and efficient web applications that require just a single page load in a web browser. In order to tell the full story of how the SPA has come to be, we're surveying the history of web development. We started with the creation of the modern Internet in the early 1990's, and continued to the advent of JavaScript, server-side sophistication, and primitive single page apps.

Temporally that brings us into early 2000s, after the dot-com crash, a time of limited innovation in the browser…

It's a technology! It's a language! It's..AJAX!

In the early 2000s, a little-known API called XMLHTTPRequest (aka XHR) is making its way into web browsers. It offers a programmatic way to issue HTTP requests to web servers and deal with responses. Although the name implies that XML is the intended data exchange format, many data types—including JSON and HTML—are supported. Here's a primitive example using JavaScript:

var request = new XMLHTTPRequest();  
request.onload = function() {  
    alert(this.responseText);
};
request.open('get', 'endpoint.php');  
request.send();  

While this functionality seems trivial today, the advent of its support in the browser opens a world of possibilities for millenial web developers—browsers and web servers can now hold conversations outside of the standard web of hyperlinks and clicks. But as powerful as XHR is, it's not until 2005 that its implications for the Internet are publicized in the form of a whitepaper from Adaptive Path's Jesse James Garrett entitled Ajax: A New Approach to Web Applications.

The paper coins the catchy term AJAX as shorthand for Asynchronous Javascript + XML, but as the title hints, AJAX isn't a language or a technology, it's just a novel way of designing web applications using various existing technologies. The AJAX craze is unstoppable, and while certain falsehoods are propagated (e.g. that AJAX-style applications can only use XML), so is Garrett's main theme: use XMLHTTPRequest to asynchronously talk to a web server "in the background" while running a breathable user experience within the browser.

These techniques had already started to crop up in commercial projects, most notably GMail, Google Groups, Google Suggest, and Google Maps. But Garrett's paper and its new AJAX give them a viral vehicle. There's a raft of new literature and methodologies, and people start to think differently about coding for the web. Behind this glossy and bandwagoned term is the first real public articulation of the single page application.

Doug Crockford

The AJAX craze is a win for JavaScript because folks realize they can and should be using it to create full-fledged user interfaces for the Web 2.0. But there's also a drawback: JavaScript wasn't designed for software engineering. It's a dynamically typed language with forgiving syntax, oddball prototypical inheritance, and no official means of packaging code. What started out as a scripting language for decorating HTML pages is now being used more than ever by large teams of developers and cut-and-pasters alike. The result is a lot of opportunities for broken websites.

Doug Crockford

It is much harder to write correct programs if you do not understand what the language actually does. Doug Crockford

In the mid-2000's Doug Crockford is wryly pointing out that it's really easy to write bad programs in JavaScript, and arguing for rigourous thinking about program design and the language itself. Doug fights for the rights of JavaScript as a legitimate programming language, using common sense and humor to help us write better code. Here's his shortened CV:

  1. JSON (2001) — JavaScript Object Notation is now the most popular data-interchange format on the web. Doug based it on JS object-literal syntax.
  2. JsLint (2002) — A JavaScript code quality tool, and the predecessor to the still-popular JSHint.
  3. JsMin (2003) — A minifier for JavaScript. Minification can drastically reduce the size of JS files, making websites load faster. It's also called uglification because it's harder to read afterwards.
  4. JavaScript: The Good Parts (2008) — Not a language manual. The best O'Reilly book I've ever read, because it has a thesis and a conscisely argued point that left me with a holistic understanding of JavaScript. Check out the book or watch Doug's tech talk by the same name.

Diversification: JavaScript Libraries

With JavaScript gaining steam as a language for engineering consumer-grade applications, the development community starts to respond in turn with a diversity of open-source libraries, toolkits, and frameworks. Just like the server-side of the web grew up in the mid-nineties, the mid- to late-2000s are characterized by the rapid growth of the client-side. I divide this period into two phases:

1. The Pre-GitHub Era

Before open-source is fast-tracked by GitHub later in the decade, a number of JavaScript web development libraries are seeing widespread use:

  1. Dojo (2004) — One of the first JavaScript libraries. Included a general toolkit and a collection of widgets.
  2. Prototype (February 2005) — A collection of useful JavaScript functions. Originated for AJAX support in Ruby on Rails.
  3. jQuery (January 2006) — Probably the most well-known JavaScript library to date (Oct 2014). Primarily an API for selecting and manipulating DOM nodes.
  4. YUI (February 2006) — Yahoo!'s framework for building front-end applications. Includes core utilities similar to jQuery and Prototype, but also comes with developer tools like a YUICompressor and a JavaScript profiler. Sunsetted as of August 2014.
  5. MooTools (September 2006) — An object-oriented JavaScript library.

Some common themes here: (1) utility functions that enrich JavaScript, (2) cross-browser DOM manipulation, and (3) some scaffolding for UI components like drop-down menus, carousels, data tables, etc. YUI is the most ambitious as far as offering a holistic framework for web app development.

2. The GitHub Era

While many of the tools above are healthy open-source projects, the advent of GitHub in 2008 ignites an explosion of new JavaScript frameworks. To demonstrate the explosive quality, here's the growth of GitHub users and repositories from the GitHub blog in 2012:

GitHub Growth

An image from redmonk.com earlier this year shows that JavaScript repositories represent the strongest sustained growth among popular languages on GitHub.

New GitHub Repositories

An interesting feature of the JavaScript GitHub era is not so much the quantity of libraries, but their diversity. GitHub lowers the cost of quality code projects enough that specialized tools and "micro-frameworks" can crop up immediately to meet the needs of a rapidly-changing front-end web. A small sampling, by specialization:

  1. HTTPjQuery.ajax(), YUI IO Utility, Google Closure XHRIo
  2. Partials — jQuery.load, HoganJS
  3. StorageAmplifyJS Store, jStorage
  4. TemplatingUnderscoreJS, MustacheJS, EJS
  5. RoutingHashChange, YUI History, CrossroadsJS
  6. MVCBackbone.js, SproutCore, KnockoutJS

The sheer variety of *JS libraries and their purported benefits are causing developaralysis and leading to social commentaries such as HTML9 Responsive Boilerstrap JS. While many developers are cutting through the noise to create the next generation of web applications, the Single Page Application isn't yet commodified. All the disctinct evolutions have occurred and stabilized, but haven't learned to work together yet.

Conscious Life: JavaScript Tooling

Believe it or not, JavaScript has existed on the server since it shipped as SSJS with Netscape Enterprise Server in late 1994. But it's not until 2009 when NodeJS sends JS to the server that this concept is also sent into the public consciousness.

The oft-touted advantage of NodeJS is that it allows JavaScript programmers to write server-side code. Without discrediting this point, I'd argue for an equally as advantageous effect of Node: it brought Linux-style engineering tooling to the JavaScript programmer. An out-of-browser runtime for a language that grew up in the browser requires a whole new class of tools for organizing, packaging, and sharing code. These tools have existed for canonical server-side languages for decades, and NodeJS sets the table for their JavaScript analogues:

  1. Code organizationAMD, RequireJS, CommonJS. JavaScript was not designed with an official way to "namespace" or contain code, like Java has with packages. In the browser, everything runs by default in a big global soup. If JavaScript was to see long-term growth on the server, it needed specs like AMD and CommonJS, and successful implentations like Require and Node, respectively.
  2. Code sharingNPM, Bower. Python has Pip, Ruby has RubyGems, Java has Maven and Ivy. JavaScript has nothing until Node provides NPM—a package format and command-line utility for easily containerizing and sharing code. And what NPM does for server-side JavaScript, Bower does for resources that run in the browser.
  3. AutomationGrunt, Gulp. These tools allow automating the build processes behind complex projects, e.g. pulling in dependencies, syntax checking, code minification, running test suites, packaging, and deploying.

At the turn of the decade, NodeJS is bringing some much needed software engineering rigour to the JavaScript ecosystem. JavaScript now recognizes itself as a legitimate engineering tool. In parallel with the rapid sophistication happening in open-source JavaScript, the stage is set for the birth of the modern Single Page Application.

The Modern SPA

Below, a modern SPA:

Modern SPA

This decade, front-end developers are becoming more certain that apps based on hyperlinks and HTML documents are outdated, and are using the best that open-source JavaScript has to offer to create fast and robust user experiences for the web. To me this looks like the best libraries, practices, and features in the JavaScript world coalescing around the Single Page App concept. And programming terms previously foreign to the front-end are providing some structure to the emerging organism:

  1. Declarative Programming — A coding style that values specification over process.
  2. MVVMMVVM stands for Model View ViewModel, and is a development on plain MVC that is a better fit for making user interfaces. The ViewModel is conducive to data-binding.
  3. Data Binding — Automatic consistency between a view and a model. When combined with declarative programming, an MVVM + data-binding setup can seriously mitigate typical spaghetti JavaScript that references the DOM all the time.
  4. Promises — A promise is an object-oriented formulation of an asynchronous callback that makes for cleaner code.
  5. Dependency Injection — A software design pattern that outsources the provisioning of code dependencies, thereby increasing testability.

Some frameworks at the forefront of the SPA emergence are Backbone with Marionnete, EmberJS, AngularJS, and DurandalJS (built on KnockoutJS) . I personally think Angular has done the best job of combining the required software engineering principles with SPA features such as templating, partial-loading, routing, and AJAX calls. I've written a comprehensive overview of Angular here:

Honorable Mention

As it goes with history, there are innumerable variables that influence an outcome. Here are some additional factors contributing to the evolution of the SPA:

  1. Moore’s Law — If it weren't for the steady improvement of personal computers over the decades, we simply wouldn't have web browsers that could keep up with the demands of full-fledged single page applications, which tend to have much greater memory, CPU, and GPU requirements than their old-fashioned counterparts. The evolution of the front-end is really the story of a focus-shift from the historically priviledged server to the commoditized client.
  2. RESTful Web ServicesREpresentational State Transfer is an architectural style over plain HTTP that encourages a predictable API for web services. Single page apps naturally require a clean separation between client and server. Unlike the old days when servers would generate and send complete web pages, HTTP endpoints are increasingly used for providing and processing data in a structured format like JSON. REST is really helping to formalize this new relationship.
  3. Browser Wars — Competition among browsers has accelerated the specification and availability of SPA-enabling features. Here's a cool visualization of new technologies and their adoption across the A-grade browsers.

Conclusion: The Next Mutation

DNA

"Angular is its own beast, beholden by none." — Anonymous message-board poster

It seems that the Single Page App train has left the station. At the time of writing, AngularJS is one of the most popular repositories on GitHub—across all languages. Numerous companies (including mine) are re-writing their enterprise UIs to be single page applications. So what's next?

Single Page App

Web browsers have come a long way. Modern ones offer a variety of APIs that enable the creation of the best user experiences software has to offer:

  1. WebGL — Use the client machine's GPU to render graphics.
  2. Web Audio API — Advanced creation and manipulation of sounds in the browser.
  3. File System API — A filesystem for your webapp to use.
  4. Web Workers — True multi-threading for JavaScript.

These are all leveraged by the best SPA frameworks and applications to create experiences that are indistinguishable from their "native" counterparts, from graphically-intensive games to collaborative document editors. But the work of ensuring an experience is a single page application still falls on the developer.

My wild speculation is that browsers will catch up with the way apps are now being designed. Recall that the "Single Page" in SPA is only there because the web wasn't designed for such richly interactive apps, it was designed for inert HTML documents strung together with hyperlinks. Today's apps aren't matched well to the environment in which they run; this is why there's such a smorgasbord of JavaScript app frameworks. The core building blocks of the web (HTTP, URLS, HTML) are probably here to stay, as they've proven to be a strong foundation for several generations of webapps.

It's up to the browser to absorb this latest shift. I think this will look like major SPA concepts such as routing, partial loading, and data-binding, migrating upwards into the web browser. This is already underway with Web Components: a collection of browser primitives that include DOM encapsulation, HTML templating, custom elements, and HTML imports.


This concludes the Evolution of the Single Page App series. It always helps me understand a thing better when I can see where it comes from. Again, a lot of this is based on Internet research about things that happenned when I was very young, so corrections are welcomed. Thanks!

Related posts:

Caleb Sotelo
AUTHOR

Caleb Sotelo

I'm a Software Engineer and Director of OpenX Labs. I try to write about software in a way that helps people truly understand it. Follow me @calebds.

View Comments