Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Deconstructing Single Page Applications

January 09, 2015

Deconstructing Single Page Applications

Presented at CodeMash 2015

I updated my slides for Ann Arbor .NET Developers , and updated them here as well. That presentation was 10/15/15. (Crazy how fast things in a js framework presentation can go out of date!)

The modern web has introduced new demands for performance that cannot be met solely on the server side, and Single Page Applications (SPAs) have rushed in to meet those demands. The SPA universe is full of choices (Backbone, Angular, Ember and more). What sets them apart, and how do you choose one? They all address the same problem set: rendering, routing, data-binding, event handling, composability and others. By dissecting how different frameworks approach these problems, we can investigate the quirks that set frameworks apart and gain a more intimate understanding of the SPA architecture itself. For beginners, ninjas and anyone in between, this talk can guide you further in the search for SPA enlightenment.


January 09, 2015

More Decks by Jeanette

Other Decks in Technology


  1. Jeanette Head Software Development Consultant Atomic Object @JeanetteHead17 [email protected] Harry

    Potter. Doctor Who. Skateboarding. Snowboarding. FIRST Robotics. Other things you can talk to me about:
  2. How does this work? I’ll take you through the following

    flow of a Single Page Application framework. We’re going to be switching frameworks a lot - so hold on tight! • Router • Controller • Event Handling • Data Binding • Components
  3. In Numbers (Jan 2015) Backbone Angular Ember Latest Version 1.2.3

    (1.1.2) 1.4.7 (1.3.8) 2.0 (1.9.1) File Size 23k (20k) 147k (125k) 430k (360k) GitHub Stars 23,156 (20,196) 43,228 (33,654) 14,887 (12,248)
  4. Let’s Get Started SkeletonApp = Backbone.View.extend(); TriangleApp = angular.module('AngularApp', []);

    FireApp = Ember.Application.create(); ReactApp = React.render(); MeteorItems = new Meteor.Collection('items');
  5. A defined route is hit That route’s data is loaded

    That route’s controller is loaded Repeat for all child routes
  6. Controller follows naming convention - named after the route Controller

    can create computed properties that are bound to the template
  7. • The template defines named actions to link to events

    • The controller or route handles the actions • Actions can be sent from both views & components
  8. 2.0

  9. The End? Which to choose? How do I keep up?

    What’s going to last? Which one is the best? What are the best practices? What should my full stack be?