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.

@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