Friday, June 19, 2015

SPAs Should Be Used Less Often

I've been building Single Page Apps (SPAs) for the past two years. I think they definitely have their place, but I think I, and many other developers, have used it a little too much.

Some developers (myself included) have said that any web application should be a SPA. WordPress type sites are fine as they are, but anything more complicated should be a SPA. There are quite a few good reasons including responsiveness, server side load, dynamic content, ease of porting to PhoneGap, client side load.

These are all great reasons, but I think they are often over stated. There are well known solutions for many of these for classic MVC (whether MS MVC, RoR, django, etc.) apps. These have been proven to work, and are solid.

When we go to SPA, we typically are granted a lot of "freedom". These freedoms are things that we often take for granted like:
  • loading bar
  • history
  • right click - open in a new tab
  • sharable URL
  • loading panel
  • error logging
Each of these things are things I had to reinvent for myself when doing SPAs. This is on top of SPA specific issues such as SEO, long initial page loads, and page full of spinners. The browser handles many of these things for classic MVC apps, but SPAs have the option to implement these or not. Many times, these are features that SPAs would like to have, but must reinvent or pull in a package for.

I think there should be a mix of JS heavy pages and classic MVC pages. We shouldn't throw out MVC on the server side just cause we can do it on the client.

The boundary I would like to draw is to leave routing on the server side, and have the client do dynamic things only on one page. Yes, there are things that I would love to have persist across pages, e.g. toasts that stay forever or user notifications that stay forever, but I would rather pull in one or two packages for these features rather than all those other features.

This would leverage most of the browser's features while giving us the flexibility to use a lot of JS to have dynamic content. Most pages I have done have few JS features that cross pages anyway. Within a single page, there is often a lot of dynamic content, but not many cross the page boundary.

I am hoping that soon there will be a framework out there that will solve this issue. It looks like most frameworks are still stuck on basic components like the best way to do binding, write web components, and decorate HTML with functionality. Hopefully there will be a clear winner in the next wave of web frameworks. Until then, I will be going back to MVC.

Thursday, June 18, 2015


The 4 major browsers have come together to create WebAssembly (, a binary compilation target for the web. This is very exciting news.

I see this as something like JVM for browsers. While not everyone loves Java, most people have really good things to say about JVM. You can compile your language down to Java bytecode and have it run everywhere. A major limitation of many languages is that it only runs where there is a virtual machine built for it. By compiling down to Java bytecode, the language can run anywhere.

JavaScript is the standard language of the web, but it is truly lacking. I firmly disagree with anyone who thinks JavaScript is a great language, but there are, unfortunately, no alternatives. TypeScript has gone a long way to fix many of JavaScript's issues, but there are still many things not fixed. I am hoping that WebAssembly will fix some of these issues. At the very least, it will let us cover over these issues with a better language. This is something I am eagerly hoping for.