Single Page WebApp Architecture

Single-Page-WebApp Architecture 程墨Morgan Cheng @morgancheng

Traditional Web Server Browser Web Page Page HTML Navigate Web Page Page HTML

Single Page WebApp Server Browser Page HTML Web Page Navigate XHR Response Navigate XHR Response

Bookmark-able Navigable Search-Engine-Friendly, if necessary

Squeeze Bits for Better Experience

Frequently Navigated Page Partial Difference Among Pages Performance Critical

Now we totally depend on JavaScript

"The secret to building large apps is never build large apps. Break your applications into small pieces. Then, assemble those testable, bite-sized pieces into your big application" -Justin Meyer, author JavaScriptMVC

Singe Page App = Client Side Routing Client Side Rendering +

Multiple Framework Choices https://github.com/addyosmani/todomvc

Why YUI3.4 app framework doesn't allow to use hash style URL for all browsers? It was very important to make doing the right thing easy and doing the wrong thing hard. Ryan Grove

Server Just Render HTML Skeleton

Define Routes varcontroller = new Y.Controller( { routes: [ { path: “/”, callback: onHomePage }, { path: “/user/:guid”, callback: onUserPage } ] }); onHomePage is invoked when route “/” is triggered

Dispatch on DOM Ready controller.dispatch(); Trigger route according to current page URL

Save on Navigation Y.delegate('click', onNaviLinkClick, 'body', '.navi-link', this); function onNaviLinkClick() { … varnewPath = currTarget.getAttribute('href'); if (controller.getPath() != newPath) { controller.save(newPagePath); } } Trigger route according to newPagePath

Page Load & Page Navigation Routing Module Page B Page C Page A

Page Load & Page Navigation Routing Module Page B Page C Page A Widget X Widget Y Widget Z

Page Load & Page Navigation Routing Module Page B Page C Page A Widget X Widget Y Widget Z Event System

Logic-less Template: Mustache http://mustache.github.com/

Ask Again： Why to Single-Page?

近身== Download It Fast 发力 == Run It Fast

function loadJS(path) { varscript = document.createElement("script"); script.type = "text/javascript"; script.src = path; document.getElementsByTagName("head")[0].appendChild(script); } Insert into <head>

… </head> <?php ob_flush(); flush(); ?> <body> Flush for browser incremental rendering

Position Inline JavaScript http://www.stevesouders.com/blog/2009/05/06/positioning-inline-scripts/

function loadJS(path) { varscript = document.createElement("script"); script.type = "text/javascript"; script.src = path; varfirst = document.getElementsByTagName(‘script’)[0]; first.parentNode.insertBefore(script, first); } Insert before first <script>

Position Inline JavaScript Before External Style Link

Caching: Better Than Downloading

Cache AJAX Inline Script Data Source Widget

JavaScript Execution is Not Free

Client-side Rendering Depends on CPU & JS Engine

Mustache Performance Suffers From Nested Data

Performance is Not Good { pid: ‘123’, entities: { images: [ { image_medium: … , image_small: … , image_big: … , } ] } }

Twice faster! { pid: ‘123’, entities_images_0_image_medium: …, entities_images_0_image_medium: …, entities_images_0_image_medium: …, }

Twitter Approach The first page response is just HTML skeleton Web is a client of its Open API The page is initialized with multiple AJAX response

Facebook Approach The first page response is HTML Skeleton with tailing inline JavaScript Init data is flushed in tailing JavaScript block It is called BigPipe The sequence of module rendering depends

Google+ Approach The first page response is complete HTML

Which is Better? Twitter Approach Facebook Approach Google+ Approach

Take-Away Leverage Framework Make decision according to app requirement Watch the Performance

Single Page WebApp Architecture

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (20)

Similaire à Single Page WebApp Architecture

Similaire à Single Page WebApp Architecture (20)

Plus de Morgan Cheng

Plus de Morgan Cheng (13)

Dernier

Dernier (20)

Single Page WebApp Architecture