Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Single Page Applications: Your Browser is the OS!


Published on

Single Page Applications have gained tremendous popularity over the past few years and have prompted the creation of several frameworks to support their development. Unlike traditional web applications, most of the heavy lifting for SPA happens on the client side in your web browser. These applications rely on hundreds of lines of JavaScript coupled with asynchronous web service calls to provide a desktop-like experience that is accessible from virtually any device.

Join Principal Architect, Jeremy Likness, to learn more about SPA, including how to determine when you should choose this approach, how SPA compares and contrasts with traditional server-based approaches including ASP.NET WebForms and MVC, and what frameworks and tools (such as jQuery, AngularJS, and Aurelia) make building SPA easier. Discover how single page applications powered by HTML5 and JavaScript transform your browser into a web-based operating system.

Published in: Technology
  • Be the first to comment

Single Page Applications: Your Browser is the OS!

  1. 1. Single Page Applications (SPA) Jeremy Likness Principal Architect @JeremyLikness
  2. 2. Our Mission, Vision, and Values
  3. 3. Our Solutions
  5. 5. OUR AWARDS
  6. 6. TODAY’S AGENDA 1. Why? Drivers behind adoption of SPA applications 2. What? Features that Make up a Single Page App 3. How? Frameworks make building apps easier 4. Q&A You have questions, we have answers
  7. 7. WHY?
  8. 8. Why? A Brief History (Pt. 1) 1995 • Complete pages are loaded from the server • Pages disappear, then reappear 1996 • Internet Explorer introduces the IFRAME • Dozens of websites adopt this ugly hack 1998 • Microsoft Outlook Web App introduces the XMLHTTP component 1999 • XMLHTTP elevated to ActiveX status • Mozilla, Safari, Operate implement XMLHttpRequest 2004 • Another web-based email app, GMail, pushes the envelope • The Ajax standard is born. Work on HTML5 begins (yeah, really!) 2006 • W3C standardizes XMLHttpRequest
  9. 9. Why? (A Brief History Pt. 2) 2006 • jQuery normalizes the DOM • Developers suddenly have a lot more free time 2007 • Silverlight released • Microsoft successfully distracts developers away from building SPA apps 2009 • First version of AngularJS is released 2010 • Silverlight 5 is released. It is almost immediately killed • KnockoutJS is released. BackboneJS is released a few months later 2011 • Last call for HTML5 specification • EmberJS is released 2015 • It’s simple. “We want to access any app, from anywhere, on any device.” And you’re responsible to make it happen!
  10. 10. DEMO: Before SPA
  11. 11. Disadvantages UX Reload Real-time Server Load Network Load Mobile
  12. 12. The Experience UX • Lacks responsiveness (click and wait) • Page abandonment • Amazon: 100ms slower = 1% lost revenue • Google: 500ms slower = 20% decreased traffic • Lots of manual effort, limited “one-click” experience • Real-time notifications and updates are difficult
  13. 13. Reloading and Round-Trips Reload • Server logic is often convoluted when trying to pull data from various areas to aggregate in order to render • Must remember state and re-render state each time (as opposed to state being preserved in the client) • Flicker/page freeze is disruptive
  14. 14. Support for Real-time Real-time • Only practical method without SPA is to POST on a timer • Notifications require rebuilding the entire page
  15. 15. Server and Scalability Server Load • Server must aggregate data from multiple places • Server now has to process everything again or resort to exotic cache methods to avoid re-processing on refresh • Server is responsible for the logic of taking data and transforming it into presentation, so 1000 clients = 1000x CPU- bound logic on the server
  16. 16. Chattiness on the Network Network Load Vs.
  17. 17. Mobile-Friendliness Mobile • Requires lighter payloads • Needs simplified model • Less processing (but less rendering is needed) • Less data when going over metered networks
  18. 18. Challenges DOM Standards Routing Security Modularity Testing Development
  19. 19. WHAT?
  20. 20. What? Typical SPA Features Data Binding Views / Components Routing Dependency Injection Data Services Testing
  21. 21. Data-Binding Support Data- Binding • Separate presentation logic from actual presentation • For example: “button click” vs. “my action” that can then be bound to a button, hyperlink, or other action • Validation • Data transformation • Leads to testability and scale • “Designer/developer workflow”
  22. 22. Don’t Repeat Yourself! Views / Components • Support for rendering to a part of the page • Reusable data transformations (i.e. filters, value converters) • Reusable components (i.e. grids, type-ahead, dialog boxes, etc.) • HTML5 standards (Web Components) • Responsive • Master/detail side-by-side on desktop • Master/detail separate pages on mobile
  23. 23. It’s Still the Browser! Routing • Navigation: I can browse to an area of the application • Bookmarks: I can save the hyperlink to a useful piece of information or workflow that I am a part of • State: I can persist my state between areas of the application • Journal: I can use the back and forward buttons on my browser the way I’m used to
  24. 24. Managing Large Code Bases Dependency Injection • Loosely couple JavaScript objects • Separation of concerns enables parallel development • Inversion of control enables testability and promotes reusability • Service location makes it easier to develop components with dependencies
  25. 25. Would You Rather This … Data Services
  26. 26. … Or This? Data Services
  27. 27. Given SPA When Test Then OK! Testing • Many frameworks come with their own test suites • Some have specific support for testing and mocking interfaces • All should expose a straightforward means to test • Best frameworks don’t require a dependency on a visible browser
  28. 28. HOW?
  29. 29. • “Normalize the DOM” • Most popular JavaScript library in use • One of the longest maintained frameworks • Many SPA frameworks can layer on top of this • DEMO: • Source: pages/examples/jquery/js/app.js
  30. 30. • Fooled you, this isn’t a SPA framework • Works well with many existing SPA frameworks • Helps “tame” JavaScript • Very useful for projects with scale (lots of code and/or many developers) • Page: pages/examples/typescript-angular/index.html • Source: pages/examples/typescript-angular/js
  31. 31. • Introduced in early MVC templates by Microsoft • Declarative bindings • Automatic refresh of UI • Relationships and computed models • Templates • Page: pages/examples/knockoutjs/index.html • Source: pages/examples/knockoutjs/js/app.js
  32. 32. • Model-driven • Idea of “entities” and “collections” • Views • Convention-based REST interface • Page: pages/examples/backbone/index.html • Source: pages/examples/backbone/js
  33. 33. • Focused on productivity • Handlebar templates • Common idioms / convention based • Page: pages/examples/emberjs/index.html • Source: pages/examples/emberjs/js
  34. 34. • Teach HTML New Tricks • Extensible • Dependency injection out of the box • My favorite framework to use, especially on large projects • Page: pages/examples/angularjs/index.html • Source: pages/examples/angularjs/js
  35. 35. • Web and Mobile • HTML5 and JavaScript focused • Layered on top of jQuery • Adapters for AngularJS and BackboneJS “out of the box” • Page:
  36. 36. Angular 2.0 • Embraces ECMAScript 6 • Built on TypeScript • Example: • Page: • Source:
  37. 37. • Convention-based • Built for ECMAScript 6 from the ground up • Former member of AngularJS 2.0 team • Examples:
  38. 38. DEMO: Todo SPA
  39. 39. Questions? • Demo Code: • A Different Angle: What is AngularJS? angle-what-is-angularjs.html • Let’s Build an AngularJS App! angularjs-app.html • iVision Application Development: development/ Jeremy Likness, Principal Architect @JeremyLikness