single page apps
JS MVVM Frameworks

Mac Newbold


SkiPHP - 2014-01-18


A Brief History of Web Development

What is a Single Page App?

Why switch to Single Page Apps?

Okay, so what are the possible drawbacks?

A few Case Studies


Who am i?

I'm a long-time* PHP web developer

I work with an awesome team of developers
at Vivint, making mostly internal tools
(and we're hiring)

I'm relatively new to Single Page Apps,
but have quickly become very
attracted to their benefits

* Without giving details, I've been around
long enough to have experienced most of
the Web Dev history lesson myself

In The beginning

On the first day (~1974), the IP was created,
and the TCP was divided from the UDP 

On the second day (~1989), the HTML and 
the HTTP were created

On the third day (1991), the WWW was divided 
from the Telnet, FTP, Usenet, and Email

Let there be light

On the fourth day (1993), the Mosaic 
was divided from the Lynx

On the fifth day (~1996), the weblogs 
were divided from the search engines

On the sixth day (~1997), the PHP 
was divided from the Perl/CGI

The modern era

And on the seventh day, everyone rested.

And we're kind of still resting...

How many web sites still deliver content in 
primarily the same way we did in the mid-1990s?

Server-side generated dynamic content,
typically using a database like MySQL,
with HTML/CSS and maybe some JavaScript...

Sound familiar?

15 years of Web Dev

In about the last 15 years, there have been
some major trends, but the core really is
extremely similar to 1997.

We have newer versions of HTML, CSS, JavaScript,
web browsers, and internet-accessing devices,
but really it's usually done in about the same way.

The most significant innovation seems to be 
XmlHttpRequest (XHR), later known as AJAX,
coming on the scene around 1999,
growing into things like Gmail by about 2004

Single Page Apps

As AJAX/XHR gained in popularity, we started seeing
a major reversal: instead of 
"dynamically-generated static web pages"
 we started seeing some
"statically-generated dynamic web pages"

This gave birth to something new: 
serve simple static content and do all the
dynamic stuff with JavaScript.

In theory, you could run a whole app with
a single page load...

What is a SPA?

Single Page Applications (SPAs) are simply
a web app served up as a single HTML/CSS
page that performs all the cool stuff with JS

You probably use them every day... 
Gmail, Twitter, Facebook, and more.
What other sites do you use that work this way?

Single Page App is a philosophy for building
web applications that seems to be the next
phase in the evolution of web developent

How are they made?

There are a few key characteristics that 
distinguish the Single Page App style:

  • One initial page load of HTML
  • Dynamic features via JS/XHR/AJAX
  • Database interaction via web services

Many SPAs are built with a client-side MVC/MVVM
library or framework (Backbone, Angular, Ember)

Any web services can be used, but REST services
with JSON output are common and work well

Big changes?

These aren't your grandpa's web apps:

  • Say goodbye to server-generated HTML
  • Back-end language agnostic
  • Front-end can be plain JS or compiled to JS
  • Apps usually driven by data and events

It really is a different way of thinking about 
your application and its world.

Why use SPAs?

Different people do it for different reasons,
but I think it is usually a combination of these:

  • Performance
  • User Experience
  • Decoupling/testability
  • Easier to build/maintain
  • Heavy JS lifting, lighter back-end work
  • Easier to provide offline operation

SPA Performance

SPAs can improve performance in several ways:

Load time: 1 file each of HTML, CSS, JS,
static files not dynamic

Less data transfer: XHR calls only send
raw data, not HTML markup

Load distribution: dramatically less load
on your server, by distributing it to clients

Caching gets a lot easier and more beneficial

Spa User Experience

AJAX and SPAs have raised the bar 
for user expectations

Besides actually being faster, JS interactions
make apps feel more responsive

Immediate feedback on click

Smaller data transfer means faster responses

Better error handling, easier retrying

Stuff devs like

There are some great benefits for you too:

Decoupling of back end web services and front end
provides great points to insert unit tests 

Build tools like Grunt turn your well-organized 
JS files into a single minified compressed JS file

Clean REST APIs make life better

Maybe use CoffeeScript, Dart, TypeScript, or
any compiled-to-JS language on the bulk of your app

Offline Operation

Try operating in offline mode with your typical
server-side generated web application...

With appropriate use of local storage and
decisions about how and when to sync
data changes to and from the server,
you can provide a rich offline experience

 Apps in offline mode can make local data changes
update the local view even before they're saved,
then when the connection is restored, 
seamlessly sync local data with server-side data

Potential Drawbacks

Anyone who tells you something is awesome
without telling you the "less awesome" parts
is trying to sell you something...

  • Depends on browser to run JavaScript
  • More coding in JS, less server-side/PHP
  • Debugging JS can be harder
  • One JS error can stop all further JS execution
  • SEO generally needs #! URLs to work right

Nothing insurmountable, but "know before you go"

In case you missed it:


There's just one slide of potential drawbacks

Checkpoint Reached

Before we move on, are there any questions,
concerns, comments, etc. at this point?

My SPA experience

When I started working with SPAs, I was skeptical, 
but it has been great so far, and I'm hooked

For over a year now we have worked with SPA, 
transitioning about 30 devs to a new way of thinking

About 8 live apps, several others underway,
and several more in the planning and design stage

We've tried a few different ways, and have
found some methods we really like

Making the switch

For a long-time PHP guy like me, it can be hard
to want to build a lot of JS and very little PHP

You'll almost surely want some kind of 
JS framework like Backbone, Ember, or Angular, 
and that has some learning curve

If you aren't accustomed to JS debugging,
you will be soon...

And then there's the transition period,
as you start building things in a very new way

Real-world Transitions

Several of our apps had to make a transition,
and we found a few patterns that worked

SPA as a page in a larger app:
Works great IMHO, if you can't SPA everything

SPA with non-SPA parts in iframes:
Not my favorite - feels wrong, but works

Fully SPA:
Ideal when you can get it, but not always practical

Evolving your App

Most of us already have an app or site
up and running and need to transition
to the new style without major interruption

If you haven't already REST-ified your back end
services, you'll want to do that first

After that, I've had good success with gradual
replacement of old-style areas with new-style
components. Since they share the same
DB/backend, the data stays consistent

And now some examples

I have several real world examples to discuss

They are non-public internal apps
belonging to my employer,
so I can't speak completely freely

But the general aspects are more helpful
than the specifics would be anyway

I'll be able to add more detail off-line,
if you're interested in a demo or something

Case Study #1: Draft

Our first attempt. A small island of SPA in
a sea of traditional PHP-based application

Users view a map with various overlays
and statistics to create a list of
favorite geographic areas

We tried Backbone - not bad
It is definitely a library, not a framework

To the rest of the app, it's a single page
that makes some AJAX calls

Case Study #2: T.I.

Our first fully SPA app, and our first go with Ember,
while it was still in the early beta stages (pre-RC)

We wanted a full framework, and selected 
EmberJS and it has been awesome

Client-side MVC uses observers to keep 
the view in sync with the data models, 
and we liked EmberData for managing 
synchronization with the server side

Maintenance needs have been low to zero

Case Study #3: FSPro

This app needed the opposite transitional 
approach: SPA with pieces of old-style

About 4 of the SPA views started out 
as iframes of the prior PHP system

Over time, they get replaced with SPA views

We've found that the two parts coexist
surprisingly well, and it was able to
go into production earlier than
if we waited to fully SPA it

Case Study #4: A.M.

Similar to #1, another SPA island in the
same PHP-based app, but with EmberJS.
Lots of drawing boxes on maps, subdividing, 
managing groups and assigning people to areas.

With a few attempts under our belts, the SPA
aspects went very well. Biggest snags were
map- or mobile-related issues, not SPA

The project proceeded ahead of schedule until we ran into issues with Leaflet, and a few of the now-resolved pre-1.0 bugs in Ember. Overall, it turned out awesome.

Case Study #5: R. Tool

The R. Tool is another SPA in a PHP app,
built with EmberJS and EmberData

This tool was more data intensive, and is
comparable in scope/size to a typical
content management system or CRM tool

By this point, we were using Ember 1.x, and
comparing EmberData and the new 
Ember Persistence Framework (3rd party)
for managing our data transactions

Cases #6,7,8: WoL, IC, RM

All three are fully-SPA tools for internal users

WoL: animated data viz for a wall display

IC: Interactive tool for request tracking, 
integrated with data from our task tracker

RM: Ecomm-like tool for reps working
with customers during renewal process

Moral of the story: Now that we're used to it,
we spin up a new SPA any time it makes sense

Lessons Learned

At this point, we're happy with where we're headed
and we've learned a few things we want to continue:

  • Use a framework like Ember or Angular
  • Plan your APIs carefully before you start
  • Build and test incrementally
  • Establish some "mentors" on the team

We have started using QUnit for JS unit testing,
and may add CasperJS for UI tests, and 
we're working on automated unit testing 
for the web service APIs with Jenkins


So now how does one go about building 
single page apps in the Right Way?

The biggest secret to success is to apply 
back-end techniques to client-side code.

On the server, we all do MVC, and it is Awesome.

On the client, they call it MVC, MVVM, MV*, 
but it's the same kind of thing, 
and it can be Awesome too.


MVC = Model, View, Controller

MVVM = Model, View, and "View-Model"

MV* = I don't want to argue with you 
about the name and acronym

"View-Model" is a really odd choice to me,
but it connects the data (Model) with the
rendered output (View), like a controller.

How it all fits Together

Top to bottom:
View-model / Controller
--- client/server boundary (REST/JSON API) ---
MVC or other web services provider

In short, the client-side MV* is a lot like 
your server side MVC, but getting data from a 
web service instead of directly from a database.


We have reached our next stop... 
any questions/comments?

MV* Tools

There are a plethora (yes, a plethora) 
of MV* tools out there now. 

I'll focus on The Big Three:


Disclaimers: I'm biased, and I'm not an expert


Backbone is a library (not a framework)

Key features: Models, Collections, Views,
some event handling sugar, and
some glue to bind it together

Drawbacks: Doesn't have everything a 
framework has, but you can add on

Uses: jQuery, Underscore, and whatever you want

Others in this category: Spine, Knockout


Angular (ng) is an MV* Framework, 
probably most popular of all

Provides all the tools from the 
models up to the views

Most bindings are done with HTML 
annotation via custom ng-* attributes

Doesn't seem to have a strong 
data sync/persistence back end (yet?)


An "ambitious" MV* framework from
folks like Tom Dale, Yehuda Katz, etc.

Seems to have a more Rails-like approach,
and a stronger data sync/persistence offering
(part of why we chose it)

Used to get knocked for having poor docs
during the pre-1.0 days, but much better now

We have liked the strong structure it provides,
and find it works great if we use "the Ember way"

Which one to choose?

Really, it's up to you...
It boils down to personal preference

I heartily recommend Ember, we've loved it

I know some Angular fans, most of whom
have not tried Ember AFAIK

Personally, I prefer having the functionality
in the code, rather than in my HTML
markup with the ng-* pseudo-attributes

A Practical Approach

So if you're convinced enough to want
to give a SPA a try, where should you start?

I'd start with TodoMVC, and try out at least
AngularJS and EmberJS for starters

If you're the early-adopter type, there's growing
hype and mindshare surrounding React too

If you think you've picked your framework,
try out their tutorial from the docs too

Your first project

Some folks like to do a real project for their first
go with a new framework, others don't

There are benefits to making your first effort
be one that you can throw away

But I'd recommend it's at least important enough
and complex enough to be a "real world" scenario

In either case, be ready to play around with it,
and be willing to try refactoring a few times
so you can find a groove you like

Getting started

There are an abundance of "getting started"
tools and guides for both Angular and Ember

Ember App Kit is definitely something you'll
want to look into if you choose Ember

For Angular, it appears that Angular Seed
is what you'd want to start with

Both include some great built-in best practices,
like build/minify tools, CSS preprocessors, 
unit testing, and much more

Careful, it's addictive

If our team's experience is any indicator,
single page applications can definitely
be very habit-forming. Use with discretion.

That said, I highly doubt you'll regret 
your new SPA addiction

SPA is best with Friends

Along with your new single page app methods,
be sure to mix and mingle with other great ideas:

Responsive Design

Continuous Integration

Test-Driven Development

REST/JSON Service-Oriented Architecture

And many more...

What now

What does the future hold?

I think we'll see much more growth of SPA and MV*

Combine them with responsive design, 
and maybe a wrapper like Cordova, and
you have a very potent web/mobile app

Instead of web devs being back end guys 
who can do JS, or HTML/CSS guys 
who can do JS, you will see more and more
hardcore JavaScript developers

Paradigm shift

In addition to the Single Page App paradigm shift,
there is another similar shift when working with
a framework like Angular or Ember.

You're no longer building a page, then 
adding JS to make it more dynamic.

You architect a system, bind your data/models
to your HTML/view, and it runs itself.

These shifts seem to be the biggest hurdle
to the widespread adoption of MV* frameworks.

Change can be good

Overall I think we're headed in a great
and exciting direction, but there are bumps

Jumping in with both feet was probably
the number one thing I think we did right
when we adopted this methodology

Questions, etc

Questions, comments?

Thanks for coming!

Feedback welcome:

Slides at:

@macnewbold /
Made with