Javascript templating conversations

Classic HTML for the people. This clearly organizes the content into a structure we can all understand and agree on.

For anything other than a basic article (like the internet was, to begin with), you’re probably going to need some other elements for layout and other attributes to help further describe things for the developers to use and to apply things like CSS, assist screen readers, and make available data that might be used to interact with the application.

You might develop a lingo with the other designers and marketing people. They’ll say things like, “So, in the in season section – I’m thinking we switch out those flower images” (and people will actually know what they mean) (because you’ve collectively tagged these things).

This isn’t a huge problem. But it leaves a lot of room for error. And what if you decide you want to update the HTML to include an ID fir each flower or re-arrange the order of the elements in each flower? So, it would be nice to somehow not have to do that.

The other reason we might want to template things is because we don’t actually know what the data is yet. We can’t type it all out by hand if we don’t know what to type. Maybe the visitor has gone to the flower page – and that GET request to the server plants.com/flowers has asked for “all the flowers.” We don’t know what those are. Or, it might have asked for flowers in season plants.com/flowers?filter=inseason. Those might have changed just yesterday or today.

If we had to choose, likely, the ability to programmatically take a set of dynamic data and get it on the page is the biggest reason we need templates. They are blueprints for how the HTML should be created based on what information we retrieve from the database.

It feels silly to say, but “templating” is about making a reusable template. Sometimes people say ‘templates’ or templating languages so much they don’t really let that sink in and it’s just part of their practical work. And that could certainly lead to a long conversation about data modeling, but that’s for another time.

Not to make this more than it is, but for some people – seeing these as placeholders or inputs to be filled out by the computer is helpful. However you need to work it out – do it. Draw out some pictures. A template for making a dress, a template for a model airplane kit, a paint-by-numbers,

This is the kind of code that scares most new people away — or that they look at and create a blurry mental model that “programming is crazy and hard.” Unfortunately, they’re usually learning things in a bad order and moving too fast. Not you though, right?

And people can write some really ugly code if they want to (or by accident). So, it also just comes down to how you choose to use the language. This code is actually very clear if you know what an element is and what the DOM is and how to add a thing to a thing. But it certainly doesn’t look like that lovely HTML we have been discussing. It’s like you’re writing the HTML but in some totally different way.

jQuery was a lot more than this, but here’s an example. You’re still imperatively modifying the DOM

[2006ish]

… a shift to Declarative Templating. Easier to read and write. Still just a string though.

[2010ish]

[2010ish]

[2013ish]

Real DOM nodes .. but required cloneNode, so barely used by common developers (more useful behind the scenes). These are building blocks – but it’s up to us to figure out how to use them.

This is certainly a lot nicer to author and read than using document.createElement(). But it’s separated out so that you have to decide where something will be put – and have those functions separate. It’s a very welcome addition to the language and you can totally create full/complex apps like this (we do it in DFTW). But if you have a team of people who know HTML and CSS well, then it sure would be advantageous if they could all author things the same way.

Note that these are purely string-based, so they aren’t actually creating real DOM elements. Depending on your situation, that might matter. If you were creating a fancy library for user interfaces, you’d likely still use createElement and those things behind the scenes.

[2015is]

[2016ish]

What do you think? Is this a nice way to write it?

We think it’s great. But it does come with the overhead of a behind-the-scenes system that could break or have errors and that would need to have clear error notifications and messages to help you when it does. With PHP, that’s already built-in, and because it’s just there in the LAMP stack – we tend to take it for granted (but it’s still a stack of software and dependencies making everything possible).

You could imagine that this HTML is read like a string. A function accepts the string and replaces anything it needs to based on a set of rules (the delimiters and the data {{flower.name}}). But they don’t all work the same. PHP will do that and then create a baked HTML page to serve back to the browser. Classic JavaScript embedded in an HTML page – will swap out the data after it’s been loaded into the browser. So, there are templating systems for the server-side of things and then for the client side of things. You could think of a database schema as a template, too. And the things that make the rules and make it all happen are what they call templating engines. You can look at the JS in these last few Pens to see some crude examples.

[2016ish]

Generally note that it’s not only about the templates / but also reusing and composing the components as a whole.