single page apps
and
JS MVVM Frameworks
Mac Newbold
Vivint
SkiPHP - 2014-01-18
Roadmap
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
Discussion/Questions
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
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
HOW TO SPA
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/MVVM/MV*
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
View-model / Controller
Model
--- client/server boundary (REST/JSON API) ---
MVC or other web services provider
Database
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.
MV* Tools
There are a plethora (yes, a plethora)
of MV* tools out there now.
I'll focus on The Big Three:
Backbone
Angular
Ember
Disclaimers: I'm biased, and I'm not an expert
Backbone
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
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?)
Ember
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