This is an older slide deck I realized I never uploaded.
It is a slightly longer deck than the Night at the SPA deck. This features many concepts that are forerunners to the modern progressive web application.
There are slides related to web performance best practices, JavaScript architecture, responsive web design, touch and much more.
A Day Building Fast, Responsive, Extensible Single Page Applications
1. A Day Building Fast,
Responsive, Extensible
Single Page Applications
Chris Love
@ChrisLove
Love2Dev.com
2. Who Am I
• Front-End Web Dev MVP
• ASP Insider
• Internet Explorer User Agent
• Author
• Speaker
• Tweaker, Lover of Web, JavaScript, CSS & HTML5
• @ChrisLove
• https://love2dev.com
8. Its Not This
326 Http Requests
23 Style Sheets 80kb
84 Images 587kb
101 External Scripts 806kb
229 Primed Http Requests
76 seconds to fully load
Multiple Unminimized Resources
Speed Index 5949
12+MB of Content
Multiple 404s
Mostly Uncached Content
9. Performance
• Multiple Studies Show Correlation Between Conversions & Speed
• 57% Will Abandon a Slow Site After 3 Seconds
• We Have to Concentrate 50% Harder For Slow Sites
• 78% Have Felt Stress or Anger With Slow Sites
• 44% Say Slow Sites Make Them Anxious
• 4% Have Thrown Their Phone
10. Matt Cutts
"Also take a step back for a minute and consider the intent of this
change: a faster web is great for everyone, but especially for users.
Lots of websites have demonstrated that speeding up the user
experience results in more usage. So speeding up your website isn’t
just something that can affect your search rankings–it’s a fantastic
idea for your users.“
http://bit.ly/SPPB4k
11. Time is Money
• Faster Sites Have Higher Conversion Rates
• WalMart - http://bit.ly/S1fHSZ
• Google – http://bit.ly/WajJbB
• Amazon – http://bit.ly/S3UoAj
• ShopZilla - http://bit.ly/RIQMDM
12. WalMart
Folks at Walmart knew their pages were slow. As a for instance, initial
measurement showed that an item page took about 24 seconds to
load for the slowest 5% of users. Why? The usual culprits: too many
page elements, slow third-party scripts, multiple hosts (25% of page
content is served by partners, affiliates, and Marketplace), and
various best practice no-nos
http://bit.ly/WajJbB
13. Google’s ½ Second
Half a second delay caused a 20% drop in traffic. Half a second delay
killed user satisfaction.
The lesson, Marissa said, is that speed matters. People do not like to
wait. Do not make them.
http://bit.ly/TPPhUp
15. Performance
• Performance Matters
• It Must Be a 1st Class Feature in Any Application
• Not an Afterthought Right Before Deployment
• 80% of Performance Is In the Client, Not the Server
• Cellular Networks Make Page Load Even Tougher
• 500ms Inherent Delay
• Bandwidth Constraints
24. Introduction to Fluid Layouts
•Morph to Fill The ViewPort Space
•Rely on CSS
• Absolute Positioning
25.
26. DOCTYPE
Replace This:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
With This:
<!DOCTYPE html>
<html>
27. DOCTYPE
"DOCTYPEs are required for legacy reasons. When omitted, browsers tend to use
a different rendering mode that is incompatible with some specifications.
Including the DOCTYPE in a document ensures that the browser makes a best-
effort attempt at following the relevant
specifications." http://www.w3.org/TR/html5/syntax.html#the-doctype
30. Responsive Web Design
• Introduced by Ethan Marcotte 2010 - bit.ly/178an9e
• Web Design Approach To Create An Optimal Viewing Experience
Across All Browser ViewPorts
• Fluid Layouts
• Media Queries
• Minimal if any JavaScript Required
31. “this unspoken agreement to pretend that we had a certain size. And
that size changed over the years. For a while, we all sort of tacitly
agreed that 640 by 480 was the right size, and then later than
changed to 800:600, and 1024; we seem to have settled on this 960
pixel as being this like, default. It’s still unknown. We still don’t know
the size of the browser; it’s just like this consensual hallucination that
we’ve all agreed to participate in: “Let’s assume the browser has a
browser width of at least 960 pixels.”
Jeremy Keith
bit.ly/1bhH6rw
Responsive Design
32. “The emergence of ideas like “responsive design” and “future-friendly
thinking” are in part a response to the collective realization that
designing products that solve one problem in one context at a time is
no longer sustainable. By refocusing our process on systems that are
explicitly designed to adapt to a changing environment, we have an
opportunity to develop durable, long-lasting designs that renew their
usefulness and value over time.”
Wilson Miner
bit.ly/1fbq5lB
Responsive Design
33. “Any attempt to draw a line around a particular device class has as
much permanence as a literal line in the sand. Pause for a moment
and the line blurs. Look away and it will be gone.
Let’s take the absolute best case scenario. You’re building a web app
for internal users for whom you get to specify what computer is
purchased and used. You can specify the browser, the monitor size,
keyboard, etc.”
Jason Grigsby
bit.ly/KzJH9G
Responsive Design
34. “How long do you think that hardware will be able to be found? Three
years from now when a computer dies and has to be replaced, what are
the chances that the new monitor will be a touchscreen?
By making a decision to design solely for a “desktop UI”, you are creating
technical debt and limiting the longevity of the app you’re building. You’re
designing to a collective hallucination. You don’t have to have a crystal ball
to see where things are headed.
And once you start accepting the reality that the lines inside form factors
are as blurry as the lines between them, then responsiveness becomes a
necessity.”
Jason Grigsby
bit.ly/KzJH9G
Responsive Design
35.
36.
37.
38. Mobile First
• Determine The Most Important Information
• Expand From There
• Start Responsive Design Mobile First
43. Responsive Design Best Practices
•Start Small Screen First
•Forces Most Important Data First
•Easier to Adjust CSS Rules
•Let Data Drive Media Queries First
•Its Ok to Use Some JavaScript
•But Not Required
57. The Server-Side Story
• Provide Markup, CSS, JavaScript, Images
• API End Points
• Possible Legacy URL Redirects
• Deal with Search Engine Spiders and Legacy Browsers
58. The Modern Web Hour Glass
HTML5
JavaScript
CSS3
ASP.NET.IIS
DB – SQL Server/NoSQL
60. SPAWebViewPage
• Must Use it as Base for MVC View
• Extends MVC’s WebViewPage
• SPARenderPage
• Causes only Changed Content to be Sent to Client
• Works in Concert with Backpack to Cache Markup in localStorage
63. SPAModel
• The SPAModel provides a base for an ASP.NET MVC single page
application model
• The model has properties for the application's Title and Description
• The SetRoute function parses a SPA route to isolate the primary
root
64. SPAHelper
• The SPAHelper class is a collection of static and static ASP.NET MVC
HTML Helper extension functions
• SPALink
• LastUpdated
• HasEscapeFragment
• HasForceReload
65. _escape_fragment_
• Google’s Specification for AJAX Applications
• http://bit.ly/117sTgL
• Allows Routes to be Sent to Server Via QueryString
• Server Sends Google Fully Rendered Markup
• Good Core Site Solution
• Legacy Browser Version
• Andy Hume of the Guardian - http://vimeo.com/channels/smashingconf
66. Cutting The Mustard
• Feature Detect to Determine Browser Capabilities
• Never Browser Sniff
if (!('querySelector' in document) //at least IE8
|| !('localStorage' in window) //at least IE8
|| !('addEventListener' in window) //at least IE8
|| !('matchMedia' in window)) {//at least IE10
} else {
}
68. The Client-Side Story
• Things You Used to Do On the Server Now Live In the Client
• Routing
• Rendering
• Data Caching
• Need to be Conscience of How Browsers Work
• Critical Rendering Path
• Memory Management
• Leverage HTML5 Features
• Storage
• Animations
69. Press # For More
• Routes Are Not Sent to Server
• No Request/Response Iniated
• Must Respond to Route in the Client
• #! Is the Defacto Standard
70. Press # For More
window.addEventListener("hashchange", function (e) {
//swap the View Here
});
72. Common Problems
•Too Large
•Try to be everything to everybody
•Memory Leaks
•Many Brittle Practices
•Routing
•Virtualize Native Functionality
73.
74. The Love2SPA Way
• SPAjs
• Backpack/Mud Bath *
• DollarBill**
• Caching AJAX Layer
• HTML Template Engine
• Deeptissue
• Toolbar, Panorama, Other Small UI Libraries
* Under Development ** jQuery Compatible
75. The Love2SPA Way – Typical Stats
• 35-80kb minified, not gzipped JavaScript
• 20-35kb minified, not gzipped CSS
• 5-35kb minified, not gzipped HTML
• 3 Core Http Requests
• < 1 second Load Time
76.
77. The Love2SPA Way
• Extensible
• Scalable
• Maintainable
• Testable
• Deployable
• Have Tangible ROI
78. SPAjs
• Responsible for Routing
• View Switching
• Executes Animations
• Relies on Animate.css - http://bit.ly/1hayo4s
• Executing View Onload and Unload Functions
79. Backpack
• Stores View Markup & Templates in localStorage
• 1st Implemented by Google & Bing
• http://bit.ly/117puyn
• Implements an API expected by SPAjs
• MudBath a work in Progress
• Implements Same API
• Used IndexDB
80. AjaxPrefilter
• Caches Data in localStorage with a TTL
• 1st Implement by Paul Irish
• http://bit.ly/117p7E9
• Can be Used with Any AJAX Implementation
• Eliminates Unnecessary HTTP Requests
81. JavaScript Templating
• Merges JavaScript Objects with Markup
• Many Libraries
• Micro-Templating
• MUSTACHE
• Handlebars
• Generated Markup Appended to DOM
84. Create Modular, Extensible JavaScript
Application
• Functions 1st Class in JavaScript
• Functions are Objects
• var foo = {};
• All Objects have a Prototype
• new Keyword creates a new Object
• Many popular Patterns
89. Building Web Applications
• Just Like C# Applications
• Release
• Debug
• The Web Needs a Compiler
• 2 Great Options
• Grunt
• Gulp
90. Building Web Applications
• Grunt & Gulp Are Node Modules
• http://gruntjs.com
• http://gulpjs.com
• Both have great eco-systems
• Add To package.json
• Run npm install
• Create gruntfile.js
• Grunt.cmd
92. Going Offline
• Leverage the AppCache
• Create a Manifest File
• Don’t Let it be a Handicap
• http://bit.ly/117q27A
• Makes Sure Your App Will Work Without Connectivity
• Good for Caching Images and Resources
• Makes the Browser look Local Before Going to the Server
93. Developing with AppCache is a PITA
@{if (HttpContext.Current.IsDebuggingEnabled)
{
@:<html lang="en">
}
else
{
@:<html lang="en" manifest="app.cache">
}
}
94. Manifest File
• CACHE
• lists all resources that should be downloaded for offline use
• NETWORK
• identifies any URLs that require the device be connected to the network
• FALLBACK
• lists replacement URLs for network URLs to be used when the device is
offline
95. How AppCache Works
• When the browser reads the manifest file it downloads the
specified resources locally
• Those resources are referred too instead of making a
request to the server
• Resources are refreshed if the manifest file has been
updated