Not only does it mask the fact that the supposed non-programmer template designer would still have to understand HTML and CSS yet somehow not have even the most basic knowledge of JS, but they would still have to be able to use whatever build tools are necessary to actually render those templates, including version control and node.js (which is the de facto platform for client-side build tools these days). The target audience seem to be old-school "webmasters" who FTP their PHP templates to the live server yet we're talking about technologies requiring a workflow that already precludes them.

So we're talking about a scenario that only benefits people who already tick all the boxes for "front-end developer" except they apparently suffer from a nervous breakdown if they have to look at an if-block or understand a for-loop yet they'll be fine learning another template language that is typically based on JS expressions anyway (though Angular was guiltier of this than Vue).

Maybe these people exist. Maybe there are teams where optimizing technical decisions for these people results in a net benefit. But I strongly doubt that this scenario is so widely applicable that this design decision makes a framework inherently superior when the cost of JSX to a team of JS devs is practically nil.

HTML is a Markup language. I get those.

CSS is stylesheets and in my opinion very straightforward. The hard part is making designs that are functional and beautiful and making it cross browser compatible, but CSS has very few warts if the "wtf" variety

JavaScript and it's ecosystem is disgusting for me. It's not hard, I can write stuff in it, it's ugly. I just don't want to touch it if I can avoid it. Pure personal preference. Typescript and elm help me to minimise the work I have to do in that mindspace. Maybe vue aims at similar clientele with less taste for statically typed/functional programming

The stated goal of making templating accessible to programmers isn't to shield people who don't like JS, it's to shield non-programmers who don't understand programming languages. This is the absurdity I'm arguing against.

If it was just about making JS look different, there would be no need to use Vue in the first place.

OF course it meant you had to learn a new language, even though you were perfectly capable of perfectly suitable language already. But at least designers didn't have to learn "programming".

There's no way around this. Templates need logic, mostly for loops (or maps, same difference), or dynamic formatting.

Unless I completely miss the boat about how Angular/React/Vue/etc are supposed to be used. I only know from my previous years of seeing it done in the way I mentioned above, and every time, the work always ended up duplicated in the non-template code.

  > "make it easy for non-programmers to write templates"
  > I feel like that has been an illusory strawman from the start.

More seriously, I myself know HTML, CSS, and a few programming languages, but unless the page is very simple I still like to separate things into template files. I prefer Handlebars, but often I just use PHP's alternative syntax.

  > apparently suffer from a nervous breakdown if they have to look at
  > an if-block or understand a for-loop

  {{#if items}}
  <ul>
      {{#each items}}
          <li><a href="{{url}}">{{name}}</a>: {{description}}</li>
      {{/each}}
  </ul>
  {{else}}
      <p>none</p>
  {{/if}}

  <p>Any items you have will be listed below:</p>
  <? $q = pg_query('select * from items') ?>
  <? if (0 !== pg_num_rows($q): ?>
      <ul>
      <? while ($item = pg_fetch_assoc($q)): ?>
          <? if (userCanSeeItem($_SESSION['username'], $item['id'])): ?>
          <li>
              <a href="<?= h($item['url']) ?>"><?= h($item['name']) ?></a>:
              <?= h(ucfirst($item['description'])) ?>
          </li>
          <? endif ?>
      <? endwhile ?>
      </ul>
  <? else: ?>
      <p>none</p>
  <? endif ?>

I use templates not because I'm scared of all that. Instead it's sort of like the recently re-loved functional programming paradigm. Template files should have no side effects. I know that once I stuff the data into a template, then nothing else will happen besides output to the user's screen.

Exactly. It's that WTF moment of having database and HTTP queries spring from unexpected locations that you are trying to avoid.

The message is something like: "These concepts you understand and use all the time? We aren't going to make you abstract them away. We're going to use them as the foundation for a new way to build apps."

I've seen this reflected strongly in large companies on the east coast. Design staff is expected to know HTML/CSS, but aren't exepected to have more than a cursory understanding of javascript.

Design will often start with HTMl prototypes, then do a handoff to engineering who will using a JS framework to wire it into the real app.

Lately, though companies are swithcing to React, because JSX seems similar enough to HTML that people presume that design staff will be able to understand it.

(but I'm also working on a long Angular 1 project at my job, so I "may" be biased)

I REALLY like that Angular 1 allows you to simply make a mockup, then add the "programming stuff" behind the scenes. WITHOUT an enormous build chain (I have enough of that on the server side already, and the server is not Node for historical reasons - I'm not sure about node yet, and even if I wanted it, that just won't fly in my group)

I'm not done yet, but I'm doing a presentation on this in December at one of the local user groups: https://github.com/roboprog/ang-prog-enh

There are companies with stupid silos like this, but for the reasons I laid out I doubt they actually benefit from the "toy-language templates" approach -- even in the aforementioned company the non-developer designers would implement the entire layout as a mockup in HTML and then toss it over to a frontend dev who would cut it up and add the actual template logic (because although the template language was "easy" non-programmers couldn't be "trusted" to get the logic right).

I see Angular's directives as a pure convenience compared to most every templating engine I've used across languages, never considered it something that makes it accessible to non-programmers. I'd actually think someone who only knows html/css would be more thrown off from a page with random, unsanctioned (by W3C), tags and attributes that may or may not reveal what they actually do.

As a programmer I don't want to write long templates, I seriously prefer Jade/Pug for that reason. When I can't use them for a client I typically use them to do all initial work, compile them to HTML, then make whatever minor changes from there.

Consider ng-for:

  <div data-ng-for="y in x">
    <h1>{{y.title}}</h1>
  </div>

This PHP example seems more idiomatic, at least to me, yet takes more to write

  <?php foreach($x as $y){ ?>
    <h1> <? echo $y->title; ?> </h1>
  <? } ?>

  <c:forEach items="${x}" var="y">
    <h1>${y.title}</h1>
  </c:forEach>

  var body = document.getElementsByTagName("body")[0];

  [...].map(function(y){
  body.innerHTML += 
    "<div>"+
     "<h1>"+y.title+"</h1>"+
    "</div>";
  });

So, is the goal of a programmer to simply write more code? If so, then Angular is definitely not for programmers.

Is the goal of a programmer to solve problems? If so, Angular is definitely a tool for programmers.

    {x.map((y) => (
      <div key={y.id}>
        <h1>{y.title}</h1>
      </div>
    ))}

Need to output trusted HTML?

    <h1 dangerouslySetInnerHTML={{__html: y.titleHtml}} />

Angular and friends require context switching. Good luck if you're using non-standard data structures or need slightly more complex filter or iteration logic. And especially in Angular (1 more than 2) you also need to keep in mind the variable scope within the DOM tree and which variables, directives and components you can use where.

With JSX it's just JavaScript and the scope is just your local JavaScript scope. Instead of having to remember all the idiosyncracies of the framework's own implementation of a for-loop[0] you just have to know JS.

I'm not saying Angular is not for programmers. I'm saying the design goal of Angular1 was to make it easier for non-programmers to write views/templates. It's even in the name: as much fun as controllers, components, directives and two-way bindings may be, the raison d'etre of AngularJS resides between the angle brackets.

[0]: https://angular.io/docs/ts/latest/api/common/index/NgFor-dir...

    <h1> <? echo $y->title; ?> </h1>

https://www.facebook.com/notes/facebook-engineering/xhp-a-ne...

  <?php foreach($x as $y): ?>
  <h1><?= $y->title ?></h1>
  <?php endforeach; ?>

  <? foreach($x as $y): ?>
      <h1><?= h($y->title) ?></h1>
  <? endforeach ?>

But you are right, i am not sure to use a template system again. But the advantage is cleaner code, many people change quickly to spaghetti code in jsx (mix all together, ifs, loops, ...).

For the record, JavaScript can not be easily refactored, since it's a scripting language with no strong types and no compilation phase, so to conduct a complex refactoring you will have to load all code base in you head and that's far from being easily. TypeScript for example is another matter.

Also, no amount of compiling or strong typing is a sufficient alternative to regression testing when it comes to refactoring.

Don't loose the point, I was written about another thing, not about tests. Every time when fanboys of functional programming (and scripting) are trying to argue that functional programming is a silver bullet they do write about tests, it's not an argument, tests are exists for any kind code no matter the code nature. Tests won't help you a lot with code analyzing, automatic refactoring and tracking down from where things came (coupling). In case of scripting (and functional programming) you will have to load all the code base in you head and only then you will be able to make some architectural decisions or perform a complex refactoring. Tests just help you to not break the system logic doing refactoring, that's it.

> Also, no amount of compiling or strong typing is a sufficient alternative to regression testing when it comes to refactoring.

No one was saying that compiling or strong typing is alternative to regression testing, don't know where you have got that idea.

It looks like you can use JSX with Vue: checkout the code for the benchmark mentioned in the article:

https://github.com/chrisvfritz/vue-render-performance-compar...

Yes. No doubt.

> which React wins easily

I disagree. The old react docs were shite compared to Vue's. Not once did I feel the need to ask google. (Have yet to go through the ones released yesterday)

The tools that the team provides (router, vuex, resource, cli, ..) work perfectly.

Where react clearly wins is with 3rd party libraries and learning resources. Egghead is a perfect example.

Depending on what you prefer one might win over the other, but it's not _clear_ by any means.

> https://www.google.com/search?q=React.createClass+versus+ext...