Most people that build websites never think about Javascript on the back-end. But with it's server debut, Javascript on the servers will change web development (with more than just Javascript based Document Oriented Databases such as Persevere eliminating the model layer) – it will bring in the next generation of templates.
But first, let us do a quick walk through of the previous generations of templates.
Before templates
Before templates, the HTML is outputted right along with the same code that processes the data. Sure it may work fine for a relatively simple forms. But, scaling the site and later re-designs are painful.
Template 0.5
With the pain, people created functions that handle all the output generation. You first run the code to processes the data and then you pass the results to a template function. You still have to go into the application code to alter the output. Since it is still written in the language, this means that you have to translate the HTML mockup code into a bunch of print statements which is simply time consuming.
Template 1.0
Now comes template files. Instead of template functions being written in the programming language, the templates files are basically HTML files sprinkled with specialize template syntax. A big time saver.
Templates 2.0
In order to write less code, the page wrapper template and page content template are introduced. This way when an item is added to the navigation, only the wrapper template needs to be changed instead of all the templates.
Templates 3.0
But, there are problems with templates 2.0 as sites grow and designs get more ambitious. The biggest is the limitations of the top-down nature of templates – causing much frustration.
This is hard to summarize in a few sentences. But, if you already understand the difference of Procedural Programming and Object Oriented Programming paradigms, then you will have a leg up since it is very similar. For those who do, a 2.0 template is a function where you pass in data as parameters, whereas a 3.0 template is a class where you pass in data when you instantiate the class.
Using the content and page wrapper templates from 2.0, content templates create a single value that is given to the page wrapper template. As well, a content template is blind to what page wrapper template is being used. To make things worse, even though the page wrapper has the content output, it does not control what template is used to create it. This top-down nature introduces three main issues:
- A template can not return more than one value to its parent. Returning multiple values is useful if the output for the content is not all in the same region within the page wrapper. For example, each page could have a custom photograph for the background of the page header to go with the article.
- If more than one page wrapper is used for the site, the application has to keep track of which one to use when in addition to the content template. This leads to tighter coupling between the application and templates.
- There is still too much code duplication in the templates. Many content template differ in only a handful of ways which leads to the templates containing a lot of duplicate code.
With templates 3.0, the application only knows of a single template per page. This template (known here as the child template) gets to pick a parent template (page wrapper) - or not pick one because it is self contained. It picks by extending another template known as the parent template. The parent template defines replaceable regions that the child template can override. This also reduces duplicate code because the parent template can extend another template: blog post template → single entry template → page wrapper template.
And now…
Templates 4.0
With all of the previous iterations, the templates only live and work on the back-end. For web applications (and the line is blurry between web application and website), this means either the front-end has an entirely different template system or it passes everything through the back-end for generating output. This is where Javascript on the server-side can change it. Now the same templates can be shared between the back-end and front-end. The back-end side stay much the same except it can serialize a template object and send it to the front-end. Meaning, the front-end can request templates from the back-end and then use them.
Browser-side
// Data to update
var data = new Context({ firstName: user.firstName, lastName: user.lastName, user.bio, bio });
var t = app.getTemplate( 'bio.html' );
var output = t.render( data );
$( '#bio' ).replace( output );
Server-side
function getTemplate( file ){
send( new Template( file ) );
}
There are many things left to be figured out for this to work and to work well. It will take a while for things to change as shown by how many systems still using templates 2.0. Just giving you a heads up.