templates and the single-page app of the future (updated)

Templates and the single-page app of the future! @garannm -
http://garann.com 1

a sht histy 2

timeline ☞static content ☞“classic” asp, php, et al ☞decoupled server-side
templates ☞ajax & dom manipulation ☞single-page apps and client-side templates 3

ye old templating 4

remember this: <html> <head> <% sub vbproc(num1,num2) response.write(num1*num2) end sub
%> </head> <body> <p>Result: <%call vbproc(3,4)%></p> </body> </html> 5

templates circa ajax server client server page ajax template template
template template template template template template template ajax 6

templates post-ajax ☞sending JSON, not html ☞rendering via dom manipulation
☞decoupled server-side ☞fallback for non-js clients ☞tied to request-response 7

templates post-ajax 8

yeah, but.. ☞too much dom manipulation makes a mess ☞it
was really slow ☞lots of duplicate code ☞rendering coupled to user interaction 9

templates post-post-ajax 10

the contenders 11

verbose logic ☞can use pure data ☞mimics classic server-side templates
☞less parsing required ☞initial implementations pretty ugly ☞modern implementations among the fastest 12

logic-less ☞needs presentation-ready data ☞decouples presentation and code ☞easier for
designers? ☞template is a dumb renderer ☞which is safer 13

remember this? <html> <head> <% sub vbproc(num1,num2) response.write(num1*num2) end sub
%> </head> <body> <p>Result: <%call vbproc(3,4)%></p> </body> </html> 14

what everyone’s so upset about <html> <head> </head> <body> <p>Result:
<%= num1*num2 %></p> </body> </html> 15

string concatenation ☞how it’s (mostly) done ☞fast ☞flexible ☞output not
really reusable ☞have to search for individual elements 16

dom elements ☞not common ☞engines using html attributes may not
return a dom ☞allows “data view” type control ☞references to elements and their relationships 17

non-template-tag format ☞most template engines don’t care about format ☞can
be used for things besides html ☞some rely on html ☞some assume haml (or similar) 18

a little help? 19

typical sitch ☞mustaches {{...}} ☞some logic (conditions, loops, partials) ☞pre-compilation
for reuse ☞server- or client-side ☞string concatenation for speed ☞format agnostic 20

rendering vs. manipulation 21

simple template <h1>Welcome back, {{username}}!</h1> <h2>Your friends:</h2> <p> {{#friends}} <a
href=”/user/{{name}}”>{{name}}</a> {{#if online}} <span class=”online”>online</span> {{/if}} {{/friends}} </p> 22

data var userObj = { username: “tmplM4st3r”, friends: [ {
name: “1337tmpls”, online: true }, { name: “hbars4lyfe”, online: true }, { name: “belieber42”, online: false } ] }; 23

rendered <h1>Welcome back, tmplM4st3r!</h1> <h2>Your friends:</h2> <p> <a href=”/user/1337tmpls”>1337tmpls</a> <span
class=”online”>online</span> <a href=”/user/hbars4lyfe”>hbars4lyfe</a> <span class=”online”>online</span> <a href=”/user/belieber42”>belieber42</a> </p> 24

loading ☞most template engines will accept any string ☞script tag
with non-rendered type ☞external file loaded via ajax or a loader ☞string concatenated into js during build ☞more fragile 25

loading & compiling var $container, myTmpl, userObj; $.get( “templates/user.tmpl”, function(
tmpl ) { myTmpl = Handlebars.compile( tmpl ); $container.html( myTmpl( userObj ) ); }, “text” ); 26

loading & compiling function renderUser( cb ) { if (
myTmpl ) { cb(); return; } $.get( “templates/user.tmpl”, function( tmpl ) { myTmpl = Handlebars.compile( tmpl ); cb(); }, “text” ); } renderUser( function() { $container.html( myTmpl( userObj ) ); }); 27

uh oh.. socket.on( “friendOffline”, function( friend ) { var friends
= userObj.friends; $.each( friends, function( i, f ) { if ( friend.name === f.name ) { f.online = friend.online; } }); renderUser( function() { $container.html( myTmpl( userObj ) ); }); }); 28

alternatively socket.on( “friendOffline”, function( friend ) { $( “a[data-name=” +
friend.name + “]” ) .next( “span” ) .remove(); }); 29

But what if.. <h1>Welcome back, {{username}}!</h1> <h2>Your friends:</h2> <p> {{#friends}}
<div data-name=”{{name}}”> {{> friend }} </div> {{/friends}} </p> 30

defining a partial Handlebars.registerPartial( ‘friend’, ‘<a href=”/user/{{name}}”>{{name}}</a>’ + ‘{{#if online}}’
+ ‘<span class=”online”>online</span>’ + ‘{{/if}}’ ); var friendTmpl = “{{> friend }}”; 31

and so! socket.on( “friendOffline”, function( friend ) { $( “div[data-name=”
+ friend.name + “]” ) .html( friendTmpl( friend ) ); }); 32

composition choices ☞how much dom manipulation is needed? ☞how likely
is re-rendering? ☞how difficult is it to find the child element? 33

client-side architectures 34

mvc ☞view and template often synonymous ☞in practice, need a
view-model ☞controller determines when to render ☞need non-mvc concepts ☞rendering container ☞event handlers 35

a “view” ☞the template ☞its container/rendering target ☞view-model/transformation logic ☞event
handling? ☞actually a bunch of stuff 36

abstracted rendering ☞a complete view should only need to be
told when to render ☞everything may not be a complete view ☞e.g. partials ☞everything may not map perfectly to a model 37

templates filling in gaps ☞non-application parts of the page ☞pieces
of proper models ☞non-data input structures (e.g. confirmation) ☞sub-views within proper views 38

templates without mvc ☞map to states, not data ☞generic renderer
or tight coupling ☞triggered by event, object.observe() ☞may need more partials ☞more data potentially hard-coded 39

with subscribers function Renderer() { this.render = function( data )
{ data.container.html( Handlebars.compile( data.tmpl )( data.obj ) ); }; return this; }); Renderer.subscribe( ‘formInit’, this.render ); Renderer.subscribe( ‘formInvalid’, this.render ); Renderer.subscribe( ‘formSubmitted’, this.render ); 40

with observers UserData.prototype = { get value() { return this._value;
}; set value( val ) { this._value = val; this._container.html( Handlebars.compile( this._tmpl )( val ) ); }; }; 41

in any architecture ☞decouple markup from code ☞reduce need for
dom manipulation ☞move rendering to an abstraction 42

node.js 43

not dissimilar from client 44

server-side uses ☞initial load ☞full-page rendering ☞server-side compilation (hogan.js) ☞rendered
html snippets 45

dumb views ☞server-side mvc is different ☞more models ☞more controllers
☞less views ☞view is single-use ☞user interaction not relevant 46

presentation logic ☞still needed for rendering ☞does this belong on
the server? ☞is it necessary? ☞can it be shared? ☞isomorphic view-models and validation 47

type of template matters ☞may be better for haml et
al ☞server-side dom pointless ☞except for scraping/crawling ☞performance matters less ☞but are you only using templates on the server? 48

full-stack templates 49

the good stuff ☞use the template for initial load ☞reuse
it to render new data ☞same template for: ☞server-side controller (url) ☞client-side controller (location.hash) 50

shared access ☞easiest to use same loader ☞e.g. Require with
text plugin ☞no need to create two versions 51

managing partials ☞can be difficult depending on template engine ☞argues
for larger templates ☞namespaces work differently ☞scope unreliable 52

solutions appearing 53

full-stack frameworks ☞reuse the framework, reuse the templates ☞not there
yet ☞but people are working on it ☞express, geddy use templates available on client ☞meteor, derby use their own 54

where that leaves us ☞client-side templates: check ☞complex client-side apps:
check ☞reuse on the server: check ☞one unified do-it-all solution: ..to be continued! 55

thanks! @garannm - http://garann.com 56

credits ☞ http://www.flickr.com/photos/ndayla/5531142284/ ☞ http://www.flickr.com/photos/ndayla/5559712259 ☞ http://www.flickr.com/photos/10567940@N05/2692285853/ ☞ http://www.flickr.com/photos/reebob/3294745178/ ☞
http://www.flickr.com/photos/jeckcrow/4407422983/ ☞ http://www.flickr.com/photos/legends2k/5410967229/ 57

templates and the single-page app of the future...

templates and the single-page app of the future (updated)

More Decks by Garann Means

Other Decks in Technology

Featured

Transcript