And Then There Weren't Templates

Ever bought that one super-fly outfit that, for the three days post-purchase, you didn’t take it off once? Not even to sleep or shower or anything. You looked so good on Friday, so you wore it on Saturday, and by the time Sunday rolled around, you were making plans based on who hadn’t seen your outfit yet. Forget about what you actually wanted to do… This outfit! It’s more important. Remember that outfit?

That’s templates.

Remember how awful web development was before templates? And then batManVC swooped in and cleaned up our Spaghetti Gotham codebases. It was awesome. So awesome, in fact, that we never really stopped to think: does this actually make any sense? Because I distinctively remember scratching my chin when I got to the part about templates and saying, “is there a silent T in here somewhere?” It didn’t make sesnse. So you went back to the part about views and all it said was: “Weeeeeeeell, it’s not really a page, but just think of it as one.” Remember how that didn’t make sense? The whole V business seemed fishy. It wasn’t a page, but it was. Plus it was a template…. And is it any coincidence that villain and view both start with V? No. But that villainous side of views didn’t become obvious until recently.

And it was just like your shiny, new outfit. It wasn’t until years later, when you looked back through your Facebook pictures with fingers crossed, thinking, “Please don’t have on the technicolored windbreaker, the aviators, and the Loudmouths. Please…” that it hit you: your outfit was stupid. YOU were stupid.

Which is just like now, when you’re navigating a new codebase and saying, “Please don’t have meaningless, shitty templates. Please don’t.” But it always does. It never fails. Yet somehow we never piece it together, that maybe… just maybe… the system is flawed.

I mean, what do views/templates do in the first place? They make up a page, right? Sort of. Not really. But even if it is a page… that brings me to the question: in the age of single-page apps, what’s a page?

We still have indexes and details and update pages and so on. But in the sidebar, there’s all kind of things going on. There’s modals (God, are there modals). There’s stuff in the footer. You can log in from the header. You can post selfies right to your Facebook from the header! And you can even look at your dumb-ass technicolored windbreaker in the footer if you want to. But you don’t want to.

There’s an infinite possibility of “pages” you could be on, on any one “page”. So why do we still have “views” when our “pages” are mostly a collection of mini-views now?

And what about our friend Silent T, the template? He can lay low and render a single list item, or do it big and render the entire layout, or anything in between like the header or the user details, or whatever you feel like, really. And why can Silent T do all this? Because templates don’t make any sense either.

Why Do We Have Templates In the First Place?

Remember the first time that special someone was coming to the crib? Your room was a wreck. Sweaty gym clothes piled up in the corner, empty Russian Standards littered the floor, and there was pizza sauce all over the ceiling. So what did you do? You threw everything you could into the bathroom, and plastered your favorite Marilyn Monroe poster over the marinara.

And did that really solve anything? No. When your date showed up, you realized you forgot about the macaroni and cheese by the door, and you’d gotten so used to how bad your roommate’s ankle braces smelled that you forgot to drop a Fabreze Bomb. And of course, guess who went straight to the bathroom to tidy up?

And this is exactly how templates came to be. Somebody was going through some shitty PHP and said, “You know… what would make this file look a lot better is if I put all this shitty HTML somewhere else.”

And sure, all that “cleaning” made the bedroom look better, but the dorm room as a whole… it didn’t improve. It was just a facade. And it couldn’t even fake-out someone failing English 98.

So the fact that we had shittily organized HTML wasn’t really fixed at all by just moving it somewhere else. We didn’t address our shittily designed HTML, we just put it somewhere new. And that, my friends, is how we got the view. The V. The villain.

So Templates Suck. What’s Better?

The data guys must be the smart guys. Because they looked at the model and said, “You know… one letter isn’t really adequate here. We need DAOs and DTOs and maybe a DSL just to interact with the storage engines.” Most MVCs shipped with an ORM from the get-go.

And controllers… any framework that was any framework had a routing framework.

But for views, us front-end guys, we just kept smashing our face on the V key, and hoping that if we split our templates up enough, maybe we’d end up with chicken parm.

But that never happened. No matter what ingredients we put into the pot: quinoa, oyster, hummus… it was always the same. Spaghetti every time. We started off with lots of logic in the templates, we tried out logicless templates (lol). We tried presentation layers. We tried everything… except getting rid of templates.

So maybe it’s time.

And why is this? Because templates don’t correspond to anything meaningful in a single-page app. Pages are made up of mini-views, Components if you will.

Think like MVC. What are the templates for an autocompleter? Easy. 1: autocomplete.html.hbs. Oh, but what about JavaScript? There will be JavaScript… we also have: autocomplete.js.

<!-- autocomplete.html.hbs -->
<form>
  <input type="text" />
  <select>
    <!-- suggestions will go here -->
  </select>
  <input type="submit" value="search" />
</form>

// autocomplete.js
$("[type=\"text\"]").keyPress(function(ev) { /* ... */ });
$("select").change(function(ev) { /* ... */ });
$("form").submit(function(ev) { /* ... */ });

Let’s think like an Object Oriented Programmer instead. We have a textfield with a lot of logic: when the user enters so much text, we want to run a query. We have a dropdown list of suggestions with a lot of logic: when the user updates the querystring, we want to filter out what’s no good while we await our autocomplete ElasticSearch responses. And maybe each of these dropdown suggestions has a lot of logic: maybe they each show an image of some purchasable item, and maybe a link to that item, and to the manufacturer as well… Maybe you want all your suggestions to slowly turn into Nyan Cat. I don’t know!

// searchbar.jsx
var Searchbar = React.createClass({
  on_key_press: function(ev) {
    //
  },

  render: function() {
    return (
      <input
          type="text"
          onKeyPress={this.on_key_press} />
    );
  }
});

// suggestion-list.jsx
var SuggestionList = React.createClass({
  on_change: fundo we still have
  render: function() {
    return (
      <select onChange={this.on_change}>
        <!-- suggestions go here -->
      </select>
    );
  }
});

// suggestion.jsx
var Suggestion = React.createClass({
  render: function() {
    return (
      <option value={this.props.value}>{this.props.text}</option>
    );
  }
});

As you can see, before we had our markup separated from our code. But why? Because it looks better? Sure, if you want to keep doing that, fine. But, remember how cool that windbreaker was at 17? This type of separation is the same way… it’s separation for the sake of it. The unquestionable thing here is: it’s better to think of HTML elements as objects. It’s better to think in terms of components than in terms of templates.

I mean, when’s the last time you went through Github and found a template for your webapp? Never.

But with a well-designed component, that’s possible.

So why are we still stuck on templates? Why are we covering up pizza on the ceiling with a Some Like It Hot poster? Why don’t we actually clean up the mess, think of elements and the events attached to them, and come to the logical conclusion that it’s all probably one object that belongs in one file, as one object?

Or are we going to wear our Loudmouths to the grave?