Skip to content

Instantly share code, notes, and snippets.

Embed
What would you like to do?
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.

@tasugo

This comment has been minimized.

Copy link

@tasugo tasugo commented Apr 13, 2017

Well, the PHP community abandoned Smarty but are now using others, such as Twig or Blade. The main advantage of those is no business logic in the view (no real PHP code, just printing stuff out).

Anyway, my feedback is that PHP userland does not use PHP for templating. Cheers.

@mpj

This comment has been minimized.

Copy link
Owner Author

@mpj mpj commented Apr 13, 2017

@mgthepooh that's very good feedback, I probably shouldn't use them as an example then. 10 years ago when I used PHP it was pretty much consensus that PHP was excellent as a templating system. I'm sad to hear that they have regressed into the old thought trap that you need to invent an entire language to keep business logic out of the render function instead of ... just not putting it there.

@gustavoisensee

This comment has been minimized.

Copy link

@gustavoisensee gustavoisensee commented Apr 13, 2017

I agree with you dude, amount of lines doesn't mean you have a better framework/library than others, the prove of that is you always can write a component in just one line, so about the v-for I've just found in its documentation https://vuejs.org/v2/guide/list.html#Template-v-for and I think it's really not possible to do it, you need to filter before you use this v-for magic thing.

@codingcampbell

This comment has been minimized.

Copy link

@codingcampbell codingcampbell commented Apr 13, 2017

I agree with a lot of this. I really like how JSX maps 1:1 to JavaScript expressions (and I don't have to learn some framework's particular DSL). That isn't to say alternative templating shouldn't exist - they do some really nice things like v-on:keydown.enter. But what I find very interesting about Vue is that it has both - either precompiling .vue templates or using the Vue JSX plugin will compile down to a render function. I don't think any other framework can say they have multiple templating languages that compile to a common format. This is especially interesting because I know there are some teams of people that have made their React/Angular choice based on the templating language - but Vue doesn't care!

@Moke-RS

This comment has been minimized.

Copy link

@Moke-RS Moke-RS commented Apr 13, 2017

At the end of the day what matters to me are two things:

  • Is it clearly, easy to reason about?
  • Is it easy to maintain?

I'll only bother myself with the number of lines if the language is verbose without any benefit.

@danreeves

This comment has been minimized.

Copy link

@danreeves danreeves commented Apr 13, 2017

To me, JSX is a great simplification and clear improvement over templates.

I think you're mistaking ease with simplicity. You already know JavaScript so JSX is easy for you. Conversely, someone that only knows HTML will pick up a HTML-like templating languages easier. See: Simple Made Easy.

Also, arguably, the whole point of template languages is to keep the templating as simple as possible through the rule of least power and separation of concerns (not separation of technologies! 😉 ).

I think the argument between templating and JSX is a false dichotomy and neither is perfect. There's a whole lot of subjectivity.

@dizko

This comment has been minimized.

Copy link

@dizko dizko commented Apr 13, 2017

I would argue that your use of the ternary expression makes the JSX code less readable than the Vue.js example. However I would argue further that the more verbose example is more readable than both examples. I generally agree with you though, don't add layers of complexity you don't need.

@mpj

This comment has been minimized.

Copy link
Owner Author

@mpj mpj commented Apr 13, 2017

I think you're mistaking ease with simplicity.

No, I really do mean simple. I understand what you mean, and you make a great point that it's easier to learn a templating language than JavaScript - but I really do mean simple in the "Rich Hickey way". When I'm saying simple, I mean that JSX is a relatively simple thing - it's just minor syntactic sugar, while a template language is a very big and intricate mechanism weaved into your application in comparison.

@btsheehy

This comment has been minimized.

Copy link

@btsheehy btsheehy commented Apr 13, 2017

I think you should be a bit more familiar with Vue before writing this critique. Filtering would be pretty simple. You could use "v-if" within the v-for loop, or you could use Javascript in the Vue instance to provide a filtering function or computed object.

You do have valid points about the pros of JSX, though. I personally prefer it when I'm doing more complex things, because I can use the full power of Javascript right in the DOM. However, if I'm just throwing together a quick app (which is most of my job), I find Vue to be much faster and simpler to understand at a glance.

I also think it's a bit dramatic to say you have to learn an entire language for templating. It's remarkable how little you have to learn. You learn like 3 or 4 attributes and that's it. For loops and if statements.

@mpj

This comment has been minimized.

Copy link
Owner Author

@mpj mpj commented Apr 13, 2017

I would argue that your use of the ternary expression makes the JSX code less readable than the Vue.js example. However I would argue further that the more verbose example is more readable than both examples. I generally agree with you though, don't add layers of complexity you don't need.

Yeah, this is a great point. I should probably backtrack up to a more readable example that is a middle-ground after showing the terse example.

@hendotcat

This comment has been minimized.

Copy link

@hendotcat hendotcat commented Apr 13, 2017

I totally agree with everything you say here about templating languages. To me, the thing where they make you learn a new syntax for basic stuff like conditionals etc is super annoying and probably a good example of the Inner Platform Effect. Last time I was using PHP, it seemed like Twig had emerged as the go-to template language, and get this: I liked that, and despite agreeing with you about templating languages, I still like that!!

It was for one very specific and important reason: XSS. You had to do some unbelievably long incantation to output a variable safely. It was something like <?=htmlentities($whatever, ENT_SOMETHING, 'then this string was the character encoding, right?', false /* can't remember what this bool does any more */)?>. That basic premise of "you're vulnerable to XSS by default every time unless you specifically avoid it every time" drove me to distraction. Just such a typically PHP way of doing things, and utterly guaranteed to go wrong 1 time in 10000 and get you owned.

JSX is the best of both worlds and I just love it so much I could die.

@mpj

This comment has been minimized.

Copy link
Owner Author

@mpj mpj commented Apr 13, 2017

I think you should be a bit more familiar with Vue before writing this critique. Filtering would be pretty simple. You could use "v-if" within the v-for loop, or you could use Javascript in the Vue instance to provide a filtering function or computed object.

I naturally understand that I can solve it outside of the templating system. :) You make a great point about the if though, I should use a more complex example that cannot be solved with an if.

@mpj

This comment has been minimized.

Copy link
Owner Author

@mpj mpj commented Apr 13, 2017

@hnrysmth eloquent as shit as always, I see.

@alancampora

This comment has been minimized.

Copy link

@alancampora alancampora commented Apr 13, 2017

Nice article mpj! Other big issue that I see, is how to debug and test templates ?
Now, in Vue 2, I think they are also supporting JSX!

@danreeves

This comment has been minimized.

Copy link

@danreeves 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

This comment has been minimized.

Copy link

@shortdiv shortdiv commented Apr 13, 2017

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

This comment has been minimized.

Copy link
Owner Author

@mpj 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

This comment has been minimized.

Copy link

@btsheehy btsheehy commented Apr 13, 2017

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

This comment has been minimized.

Copy link

@julienetie 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

This comment has been minimized.

Copy link

@panta82 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

This comment has been minimized.

Copy link

@kennygoff 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

This comment has been minimized.

Copy link

@arvigeus arvigeus commented Apr 13, 2017

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.

@wmhilton

This comment has been minimized.

Copy link

@wmhilton wmhilton commented Apr 13, 2017

@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!

@wmhilton

This comment has been minimized.

Copy link

@wmhilton wmhilton commented Apr 13, 2017

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".

@wmhilton

This comment has been minimized.

Copy link

@wmhilton wmhilton commented Apr 14, 2017

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

This comment has been minimized.

Copy link

@jnvm 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

This comment has been minimized.

Copy link

@petmat 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

This comment has been minimized.

Copy link

@MVSICA-FICTA MVSICA-FICTA commented Apr 14, 2017

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

This comment has been minimized.

Copy link

@pbastowski 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

This comment has been minimized.

Copy link

@smolinari smolinari commented Apr 14, 2017

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

This comment has been minimized.

Copy link
Owner Author

@mpj mpj commented Apr 14, 2017

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

@mikeq

This comment has been minimized.

Copy link

@mikeq 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

This comment has been minimized.

Copy link

@cgbystrom cgbystrom commented Apr 14, 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.

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

This comment has been minimized.

Copy link

@ivryb 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

This comment has been minimized.

Copy link

@kaspar-allenbach kaspar-allenbach commented Apr 18, 2017

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

This comment has been minimized.

Copy link
Owner Author

@mpj 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

This comment has been minimized.

Copy link
Owner Author

@mpj 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

This comment has been minimized.

Copy link

@gbezyuk 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

This comment has been minimized.

Copy link

@pvolyntsev pvolyntsev commented Apr 20, 2017

@ivryb Perfect!

@mpj

This comment has been minimized.

Copy link
Owner Author

@mpj 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

This comment has been minimized.

Copy link
Owner Author

@mpj 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.

@ghost

This comment has been minimized.

Copy link

@ghost 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

This comment has been minimized.

Copy link

@westtrade 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

This comment has been minimized.

Copy link

@jefkoslowski jefkoslowski commented May 8, 2017

@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