The other day I had an informal talk with a friend about a project we had been offered. I can’t divulge much about the project but I can say that it has, structurally, a lot in common with an ecommerce app. Users shop a class of product and check out, they’ll also be able to use common coupon codes like the ones found on websites like Raise. Work has already been done on this app. The “MVP” that has been built has a wholly decoupled “thick client” browser-based UI built in AngularJS. I have a decent amount of experience with AngularJS as well as the other, similarly popular (possibly moreso) javascript MVC framework Ember.js.

I have seen a trend firsthand in the last several projects I have been offered – and a couple that I have taken on – toward the use of these javascript frameworks and decoupled, thick client architectures. Stunningly, in every one of these cases, the architecture is unambiguously more burden than benefit (much more, in fact) in respect of both development load and user experience.

Good Old-Fashioned Websites

When I talk about “websites”, I’m really talking about web applications, but those whose whose workflows are multi-page and form-based. This is in contrast to Single Page Apps, which are web applications that are piped to the browser as giant concatenated javascript files packaged with all the templates that comprise the UI and that implement workflows by passing data back and forth over the network to the server (generally passing data as JSON documents to a REST API) in such a way that your browser never refreshes. Below are some examples of each methodology in action.

Excellent Websites

…again I acknowledge my use of the term “website” is a stretch – I mean server-rendered, multi-page web apps with form-based workflows. Anyways, here are some exemplary applications built with this structure…

• GitHub
• Basecamp
• Coinbase
• Gilt
• ZenPayroll
• amazon.com
• gov.uk

Excellent Single Page Apps

…and here are some excellent Single Page Apps that exemplify the most suitable use case for a thick client architecture:

• Google Spreadsheets
• Duolingo
• Prezi
• MontageBook.com
• SoundCloud

Defining the Problem

The problem here is that most applications built as thick client apps have no need to adopt that architecture, and are, in fact, much poorer off both in respect of complexity and development load and, more importantly, in respect of user experience. There is a generation of developers who, I think, are learning web development with tools like AngularJS and Ember and so bring these tools to projects by default, even when they are completely unsuitable.

These tools and architectures have a definite use case. In my experience, though, this use case is represented by maybe 20% of projects – mostly those that present a desktop-like UI like Prezi and Google Docs do or those that, like SoundCloud, GrooveShark and similar apps, entirely break user experience if a page refresh occurs.

It’s my hope that if you read this and you are not already doing so, you will, on your next project, give deep consideration to what sort of application it is you are building and whether a thick client architecture really makes sense.