Skip to content

Instantly share code, notes, and snippets.

@mpj
Last active October 24, 2018 15:19
Show Gist options
  • Star 16 You must be signed in to star a gist
  • Fork 2 You must be signed in to fork a gist
  • Save mpj/d37bb421efe1e3eda4a6da7e18864362 to your computer and use it in GitHub Desktop.
Save mpj/d37bb421efe1e3eda4a6da7e18864362 to your computer and use it in GitHub Desktop.
Templating critique

Thoughts on Templating languages

I get a lot of questions about what I think about Vue.

I won't comment too much on Vue in general because I'm not familar enough with it, but I'm very familiar with templating systems, and in articles praising Vue, the fact that it uses templating system instead of JSX is almost always cited as a reason to choose Vue. This drives me up the friggin' wall, because the negative side effects of templates are not communicated or discussed. JSX exists for good reasons. To me, JSX is a great simplification and clear improvement over templates.

Template languages are often sold on looking superficially good. I recently ran across yet another one of these articles citing the wonders of Vue, and especially templates. In this article, this JSX example is included:

render() {
  let { items } = this.props
  
  let children
  if (items.length > 0) {
    children = (
      <ul>
        {items.map(item =>
          <li key={item.id}>{item.name}</li>)}
      </ul>
    )
  } else {
    children = <p>No items found.</p>
  }
  return (
    <div className="list-container">
      {children}
    </div>
  )
}

The article berates that JSX example for being verbose, and then goes on to cite this Vue example as a counter example:

<template>
  <div class="list-container">
    <ul v-if="items.length">
      <li v-for="item in items">
        {{item.name}}
      </li>
    </ul>
    <p v-else>No items found.</p>
  </div>
</template>

This is very disingenuous by the author, since the first example is written in a very verbose way. Written in a more concise manner, it would look like this:

let ListContainer = ({ items }) => {
  <div className="list-container">
    {items.length === 0
      ? <p>No items found</p>
      : <ul>
        {items.map(item => 
          <li key={item.id}>{item.name}</li>
        )}
      </ul>
    }
  </div> 
}

I'm not sure if the author of the article is being intentionally misleading, or if he picked the JSX code from some React tutorial online. I'm going to give him the benefit of the doubt and assume the latter. If so, the original JSX above was probably written in a verbose way in order to demonstrate how things work to the reader - when explaning programming tooling, you don't want terseness, you want to explain things in clear ways with as little magic as possible.

The Vue example, however, doesn't explain much about HOW the heck it actually WORKS. I know how Array.map works, but what is v-for and what is that syntax in the attribute? Yes, it's easy enough to understand WHAT this indivudual template does, because it reads a bit like English, but when you actually have to start writing and working with these templating languages, you development speed will slow down to a crawl, because you will now have to spend time learning (and often extending) the templating langauge. Yes, it's not a big language, but it's still a bloody language that I have to learn. In JSX, there is very little to learn, and I can then exploit my existing JavaScript knowledge and tooling.

For example, let's say that I want to filter out items that are inactive. JSX is just JavaScript, so I just filter:

let ListContainer = ({ items }) => {
  <div className="list-container">
    {items.length === 0
      ? <p>No items found</p>
      : <ul>
        {items
          .filter(item => item.active) // <-- LINE ADDED
          .map(item => 
            <li key={item.id}>{item.name}</li>
          )
        }
      </ul>
    }
  </div> 
}

How to do this in the Vue template? I honestly have no idea. I wanted to provide an example here but 10 minutes of googling later I still cannot find how to do it. It might be possible to figure out somehow, but the point is that I already HAVE Array.filter! This knowlege problem exists JUST because we've invented an entire custom language to use here instead of just using JavaScript.

The entire PHP community learned this 10 years ago when most sane PHP programmers stopped using Smarty (http://www.smarty.net/) when they realized that PHP itself was excellent as a templating language.

JavaScript is no different here - it's perfectly good as your templating language, don't invent yet another niche language.

@danreeves
Copy link

danreeves commented Apr 13, 2017

That's an interesting point. I guess I would say JSX introduces low complexity up front but doesn't stop you introducing complexity yourself in your render functions. Templating languages introduce pretty high complexity up front but aim to limit complexity you can introduce through your templates (to varying degrees dependant on features of the language).

Seems like a tradeoff with no great answer. I can say from very real experience of digging through hideous Wordpress themes that simplicity in tools doesn't always mean simplicity of finished product.

@shortdiv
Copy link

I think the big issue with templates is debugging like what @alancampora ^ mentions. Debugging templates tends to be frustrating because you have to keep track of the scope of your template and how it gets called, which is a huge cognitive load.

@mpj
Copy link
Author

mpj commented Apr 13, 2017

@shortdiv @alancampora Debugging and testing is a great point. Line numbers in exceptions might or might also not be an issue depending on how good the Vue tooling is.

@btsheehy
Copy link

I naturally understand that I can solve it outside of the templating system. :)
@mpj

Well Vue 1 actually had built-in filtering and ordering functionalities to the templating language, but took them out for Vue 2 because @yyx990803 acknowledged that those things are better solved with pure Javascript. So I would say you're maybe asking the templating language to do things it's simply not designed to do. You are definitely correct that there are complex things you can't do with templating, but maybe it's just a philosophy thing. Vue prefers you do your complex logic in Javascript and says that your DOM should have nothing more complex than loops and if statements, whereas JSX allows you to incorporate your logic directly into the DOM. Both have advantages, but I think it's largely a preference thing.

(Worth noting that I'm a fairly new developer and am not actually qualified to speak on what Vue "prefers" you do. Just my perception. Also, big fan of your videos!)

@julienetie
Copy link

julienetie commented Apr 13, 2017

There's a very simple solution for templating...

  • Use functions as markup tags
  • Make those functions accept attributes and children in the exact same notion as HTML/ SVG
  • No logic: Use declarative functions and values only

Kind of like this...

// PRESENTATION
import { section, input, label, ul } from 'hypertext';

const mainSection = ({ todoList, toggleAllAsCompleted }) => {
    return section({ class: 'main' }, [
        input({ class: 'toggle-all', type: 'checkbox', event: { on: toggleAllAsCompleted } }),
        label({ for: 'toggle-all' }, 'Mark all as complete'),
        ul({ class: 'todo-list' }, todoList)
    ]);
}

export default mainSection;

JSX

render() {
  let { items } = this.props
  
  let children
  if (items.length > 0) {
    children = (
      <ul>
        {items.map(item =>
          <li key={item.id}>{item.name}</li>)}
      </ul>
    )
  } else {
    children = <p>No items found.</p>
  }
  return (
    <div className="list-container">
      {children}
    </div>
  )
}

Declarative.. (native JS)

// LOGIC
// controller.js
import {li, ul, p} from 'blabla';
// import listContainer from './view';
const list = (items) => items.map(item => li({key: item.id},[item.name]);
const children = items.length > 0 ? ul([list]) : p('No items found');
// export listContainer(children);

// PRESENTATION
// view.js
import {div} from 'blabla';

const listContainer = (children)=> div({class: 'list-container'},children);
// export default listContainer;

We simply leave logic in one place and presentation in another.

I made a version for virtual-dom which I may port to snabbdom / react etc.
Two more things to add:

  1. Declarative templates are the future, it's not something the language can enforce, but a discipline.
  2. For minimal use ES6 template strings are great, they do a fairly good job when used with something like DOMParser.

@panta82
Copy link

panta82 commented Apr 13, 2017

Not mentioned so far: vue's templating allows you to just plop in a vue.js script tag into any page and get going. No need for a build system.

With JSX, you need the entire babel compiler, which adds too much startup time. Or you can go with straight react, but who wants to do that? So, react is kind of limited to full-borne projects with a build system, which is a shame.

@kennygoff
Copy link

kennygoff commented Apr 13, 2017

I've been working in Vue for two months, after doing React and React Native for a few months. Although I like Vue, I still prefer the style of React, a lot of the reasons you said are the reasons why. I don't want to learn a templating language that does a lot of things "magically" when I can just write javascript.

I do have to note that your filter example is a bit off, and is pretty simple to do in Vue, although not in the template language itself.

<template>
  <div class="list-container">
    <ul v-if="activeItems.length">
      <li v-for="item in activeItems">
        {{item.name}}
      </li>
    </ul>
    <p v-else>No items found.</p>
  </div>
</template>

<script>
export default {
  computed: {
    activeItems() {
      return items.filter(item => item.active);
    },
  },
};
</script>

See here we're building a single-page Vue component, and describing a computed method, which automatically computes activeItems when items change. I wanted to show this example since I think it further exemplifies why Vue and templating have downsides in that they add hidden complexity to gain short-term simplicity. How does computed actually work? What constitutes a change in items for it to recompute? Does adding an item? Editing an item? Most of the issues I've run into with Vue are issues that stem from not understanding how things work under the hood, and myself (or open source contributors) doing things that aren't simple in Vue, and the second you walk away from things with simple solutions, you get quickly into confusing territory.

@arvigeus
Copy link

You are forgetting that React is relatively new language. Before that templating was the most popular way to do things. Lots of companies use Angular for example. Because of that, the language is hot on job market. This has nothing to do with its strengths/weaknesses. Similar is the situation with Rust - although it is supposedly better than C, majority of programmers still use C because it was around since forever. React is now catching up, but still there will be big companies using Angular v1 because rewriting entire codebase is too expensive. For the same reason we use ASP Classic at my work: not because it is better, but because VB was still a thing when the company started and now we have tons of ancient code.
I never worked with templating language in my life, so I see your point that they look weird. But I also do understand why people use them. Not to mention that many people might actually like them.

@billiegoose
Copy link

@mpj I've been using Vue for quite a while, so I gotta defend it. (someone is wrong on the internet)

First of all, @kennygoff wrote it right. That's the "Vue" way. Any non-trivial logic belongs in a method or a computed property. The point of having an HTML-like template language is it looks like HTML. HTML is much easier to reason about than JavaScript. It is also strictly less powerful.

And @btsheehy, I completely agree with your evaluation of "what Vue "prefers" you do". I think Evan You made it pretty clear when he did the unthinkable - he actually REMOVED features from his framework! (Imagine the uproar if NodeJS core did that!) As he hacked on VueJS he realized where its core strengths and weaknesses were, and taught us the lessons he was learning (and asked for feedback) and said "I'm going to take these features out of Vue, because they tend to lead to messy code / aren't worth the maintenance cost / we know better now."

Which brings me to my final point... Evan You is just a really great guy. I've watched as he developed his thinking, through talks and interviews and release notes and on Twitter, and I'm a better programmer as a result. I first learned about Flux from hearing him praise it and from learning Vuex. And he's just prolific. His Vue dev tools are great. He's successfully making it as a freelancer working on VueJS full time now, living the dream! He has been incredibly good about reaching out to the PHP community, particularly the Laravel community.

And he took on Google (Angular) and Facebook (JSX) and showed you can have the best of both of them. He's an awesome underdog story!

@billiegoose
Copy link

And I know this is repeated elsewhere, but Vue does JSX. It's right there in the docs. So it goes all the way from jQuery-like "just add a script tag from this CDN" to the create-react-app-like "use the vue-cli to setup a preconfigured webpack, single-file-components, babel-y project".

@billiegoose
Copy link

Aside: When people say "JSX is just JavaScript" I feel that's about as accurate/disingenuous as "CoffeeScript is just JavaScript". Like... yes technically they are correct... but in practice you need a compiler to get there.

@jnvm
Copy link

jnvm commented Apr 14, 2017

"...just javascript"

let render=({items})=>
	`<div class='list-container'>${items.length
		? `<ul>${items.map(item=>
			`<li key=${item.id}>${item.name}</li>`
		).join('')}</ul>`
		: `<p>No items found</p>`
	}</div>`

I guess that is a bit tedious.

@petmat
Copy link

petmat commented Apr 14, 2017

Thank you for this gist! I've been writing a web app with Aurelia and thought about the differences with templating languages and JSX a lot lately. Aurelia only uses templates and I don't have a lot of experience with JSX but have been reading enought about it to make me think if it would make developing easier. It's always great to drive yourself nuts thinking about something and then notice that some one else has the same headache 😄

@MVSICA-FICTA
Copy link

Templates are good enough for the large majority of UI tasks. An interface is the kind of artifact that gets constantly tweaked and thrown out as soon as the urge to create another one arrives anyways. Being able to draw a clear line between template, script and style the way Vue does is the most adequate.

If you are developing anything worthwhile its also a good idea to keep these well established boundaries in place and integrate them in a modular fashion. The JS business logic is what matters and keeping it out of tempest and forever evolving UI standards is the best advice, for any meaningful and scalable project.

IMO Vue shows the way. With the combination of CSS Grid, CSS Variables and templates and the proper techniques to bridge between the worlds of template, script and style, we have what it takes to put UI development on a better path than JSX did.

@pbastowski
Copy link

pbastowski commented Apr 14, 2017

@mpj Just wondering, when you said that you "already HAVE Array.filter", have you actually tried the following in your Vue template:

            <li v-for="item in items.filter(i=>/e/.test(i.name))">

That's pure JS, right? And it works :)
Perhaps you missed it?

And yes, I understand your point is about templates vs JSX. However, the nice thing I find about Vue, as opposed to, say, AngularJS for example, is that I can use plain JS in templates.

@smolinari
Copy link

To me looking at JSX is like, and I am taking the words from another dev, prying my eyes out with a spoon. I also know he and I are not alone in this subjective view of React and JSX. Granted, I come from a history of looking at a lot of PHP in my day and using templating systems. So, I am biased. My eyes have this methodology burnt into them. 😄

MPJ, you are right about PHP and it being a template system in and of itself. However, once you give people the ability to do more than they should, they will. Not because they want to, but because they simply don't know better. Calling a database in HTML is seriously bad PHP programming and I've seen people write PHP programs like that and I still run into questions with example code that gives me chills down my spine.

Going out a bit of a tangent, but humor me, what is one of the biggest reasons why Twitter is so successful? It's the fact that Twitter is constraining. And, as in texting, constraints in programming are actually good too, because they form boundaries. They don't allow the kitchen sink in places where it really shouldn't be. That is what Vue offers too.

In fact, Vue got even more constraining in terms of its "templating syntax" (which really isn't hard to learn for anyone) from version 1 to 2, because I believe Evan understands about constraints and about the separation of concerns between HTML for component structure and JavaScript for component behavior. This much clearer and cleaner separation also means people less experienced in JavaScript, can still manipulate component structure without seriously or irreparably breaking things. It also helps them to reason about the JavaScript code. This elegance, this constraint and separation of concerns in turn means Vue is much more open to beginners of front end programming and that means, its popularity will be greater than React's at some point. That is my own personal prediction of course.

Vue may not be more popular in the purely professional world right now, but it surely is within the hobbyist and PHP world. And these hobbyist are working with a pragmatic tool, which they can grow with to become professionals and build professional things with too. (because Vue can also do JSX). But, the good thing is, they'll learn to do it all properly from the start, because of Vue's constraints. JSX allows beginners to do many wrong things first, if they even get into it at all.

Oh, and there are a ton of professional programmers, who also think Vue is great and are building incredible things with it (like Quasar Framework or Weex).

So, looking at Vue from that tangent, if you are working on something where you want a much bigger base of users (professionals AND hobbyists), you'd have to admit Vue is the better choice and because of the template like system direction Evan imposed on it and its users. It is more pragmatic and elegant (in my eyes) and why I'm a real fan of Vue! 😄

Scott

@mpj
Copy link
Author

mpj commented Apr 14, 2017

Update note: I've updated the JSX example slightly.

@mikeq
Copy link

mikeq commented Apr 14, 2017

Beauty is in the eye of the beholder. Personally I think JSX is elegant and easy to get to grips with, but these are all subjective, just opinions.

If you need to break out of a templating system to use javascript or JSX plugins for certain things then wouldn't it be easier to just use JSX to start with?

@cgbystrom
Copy link

An often underexplored idea behind a more declarative approach such as Vue is that of editor-assisted workflows.
With the trend of putting templating and styling inside JavaScript code (imperative), you effectively block external tools to read/modify the templates.

When we think of visual editors / WYSIWYG, web devs often recall horror stories from Frontpage/Dreamweaver era.
Their approach turned out pretty naive but the core idea is not bad at all. You can design your templating language to be both tooling and human friendly. But it likely requires terms that allow good two-way syncing without distorting/losing information (aka something declarative).

@ivryb
Copy link

ivryb commented Apr 17, 2017

  <div class="list-container">
    <ul v-if="activeItems.length">
      <li v-for="item in activeItems" v-if="item.active"> // <-- 20 BYTES ADDED
        {{item.name}}
      </li>
    </ul>
    <p v-else>No items found.</p>
  </div>

@kaspar-allenbach
Copy link

I'm a designer so I don't really know much about these languages. I had a project with react lately with a fellow developer who was all over the place with react. What I found weird about this jsx thing:

In the end you have an empty html file and a huge-ass javascript file.
Isn't that very bad from a performance standpoint?

@mpj
Copy link
Author

mpj commented Apr 18, 2017

An often underexplored idea behind a more declarative approach such as Vue is that of editor-assisted workflows.
With the trend of putting templating and styling inside JavaScript code (imperative), you effectively block external tools to read/modify the templates.

This is an interesting notion to me, because I view this as a disadvantage of templates. What external tools are you talking about specifically, that support Vue templates? (Or any template language)

With templates I feel that I LOSE a lot of tooling support. With JSX many editors support it natively (partially because it's so popular, but also because it's relatively easy to build a parser for it since it's almost just JS). Since the tooling understands where JSX ends and JavaScript begins, all the power of ESLint, refactoring tools in the editor etc. are available to you. With templates, one is almost always at the mercy of the runtime checks of the templating engine.

@mpj
Copy link
Author

mpj commented Apr 18, 2017

In the end you have an empty html file and a huge-ass javascript file.
Isn't that very bad from a performance standpoint?

Interesting with a designer perspective. What you describe is good from performance standpoint, especially on 3G where latency is higher. Essentially, you want to keep the number of requests to a minimum because there is overhead on every request. An imperfect real-life metaphor that might help is to think of it as shipping packages to a customer - if you ship packages individually it will use more postage/fuel/packaging/packing time/unpacking time.

@gbezyuk
Copy link

gbezyuk commented Apr 20, 2017

You can actually use the same map/filter/whatever on the list, exactly because it's a plain JS. But JS can be placed only in proper places, keeping the rest declarative, which is very, very good. I guess you shouldn't blame the promising technology because of your taste next time, unless before getting really familiar with at least its basic docs.

@pvolyntsev
Copy link

@ivryb Perfect!

@mpj
Copy link
Author

mpj commented Apr 21, 2017

You can actually use the same map/filter/whatever on the list, exactly because it's a plain JS.

@gbezyuk I'm not sure I understand what you mean. The template language is not plain JS. Can you elaborate?

@mpj
Copy link
Author

mpj commented Apr 21, 2017

Not mentioned so far: vue's templating allows you to just plop in a vue.js script tag into any page and get going. No need for a build system.

With JSX, you need the entire babel compiler, which adds too much startup time. Or you can go with straight react, but who wants to do that? So, react is kind of limited to full-borne projects with a build system, which is a shame.

@panta82 This comes up often, but it's an argument that is foreign to me and I need a bit more context to understand. To be, having a transpilation/build step is something that you HAVE to add to an application, even pretty early on - at least the ones that are complex enough to need a virtual dom. I'm trying to understand here.

If you do not have a build step, you cannot:

  • minify the application for deployment, so the clients will get unoptimized JS
  • use any modern JavaScript features, and have to be extremely mindful of browser support all the time
  • use npm modules

Because of these things, it seems very strange to me not to have a compiler step because it provides so much benefit. I would love to hear a bit more about the realities of the people that pick Vue because they feel that React imposes transpilation on them, and how they work without transpilation.

Copy link

ghost commented Apr 23, 2017

@mpj You say you like JSX because it lets you use JavaScript instead of using a new syntax to do operations that already exist in JS. Then I think you would love Hyperscript since it's 100% JS and not "almost JS" like JSX :). Mithril is a library that uses Hyperscript to describe HTML and it's very easy to learn and use.

@westtrade
Copy link

westtrade commented Apr 25, 2017

let ListContainer = ({ items }) => {
  <div className="list-container">
    {items.length === 0
      ? <p>No items found</p>
      : <ul>
        {items
          .filter(item => item.active) // <-- LINE ADDED
          .map(item => 
            <li key={item.id}>{item.name}</li>
          )
        }
      </ul>
    }
  </div> 
}

excuse me, but it's look like crazy unreadable thing

@jefkoslowski
Copy link

@mpj The same way of thinking can be applied to ORM vs SQL?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment