[coldtea]

>This is a complaint I've heard often about React, and usually it's by someone that's never actually tried it (myself included before I first used it). But it's a visceral response. Until you sit down and give it a go, it's hard to believe that we had the separation of concerns wrong.

We didn't. And React doesn't change that either. React components are not logic code, they are UI code, and that has always went with view concerns (loop this times, show this button or that button depending on state, etc).

In the Desktop GUI space, where they don't have our HTML madness, do you think their UI components are not using code? Buttons, drop-downs, etc are not appearing by magic, they are created by code that does things like: draw a line of x length and y color, then another perpendicular to that, etc, then loop and draw some stripes, etc. That's the case even in Smalltalk, where MVC was invented. That still matches with "separation of concerns" -- which is about not mixing your BUSINESS logic with your UI code, not about not having code in your UI rendering.

In fact, compared to the classical way (foreach and other kinds of template instructions embedded in template strings, from PHP's Twig to Angular) it's even cleaner, because even though JSX looks like HTML it's actually compiled to Javascript instructions it's not just some ad-hoc language hidden in template tags to be interpreted at runtime.

And separation of concerns also applies to UI elements (encapsulation, re-use, etc) something which "logic free" templates like Mustache and so also miss (or, well, make harder -- of course if you try hard enough you can always fit a square peg in a round hole).

[TeMPOraL]

This.

I can't comprehend the very idea of "template languages". Especially in PHP, because PHP itself is a decent template language by design. But even outside - they always evolve the same. They start as a "lightweight" way to avoid putting code into view templates, but then they slowly accrue conditionals, loops, local variables, half-assed tools for defining functions, and before you know, your "no code allowed" template language becomes a Turing-complete and pretty crappy replication of PHP.

And all of that is orthogonal to the main insanity of this whole era - stitching HTML from strings. HTML is a structured tree format, and should be built out as a tree. Gluing strings together is the source of oh so many errors and security vulnerabilities...

Personally, I liked the CL-WHO approach - http://weitz.de/cl-who/.

[pasta]

And after you replicated PHP you come to the conclusion the templating language is as slow as hell. So you think: maybe we would need a compiler so we can cache the templates.

The question ofcourse is: why would people rather use:

  {for item in list}<li>{item.name}</li>{end for}

instead of:

  <?php foreach($list as $item) { echo '<li>' . $item['name'] . '</li>'; } ?>

And I think this goes deep. People are looking for more human ways to express themselves. And PHP is not a very beautiful language. So maybe my first example looks more 'human' than the PHP example.

[TeMPOraL]

Note than in PHP you can also rewrite it as:

  <?php foreach($list as $item) { ?>
      <li><?= $item['name'] ?></li>
  <?php } ?>

Or with shortened PHP tags and alternative control structure syntax:

  <? foreach($list as $item): ?>
      <li><?= $item['name'] ?></li>
  <? endforeach; ?>

Which at this point just differs in delimiters (<? and ?> instead of { and }) from the template language.

I don't have an opinion on this "more human way" to express oneself, but it seems that it would connect this case with the reason people seem to prefer curly braces to parenthesis in code too.

[Nullabillity]

And then, to avoid XSS, you'd need to replace that by:

    <?php foreach($list as $item) { ?>
        <li><?= htmlentities($item['name']) ?>
    <?php } ?>

Which is, IMO, the main problem with using PHP (or any other from of plain string concatenation) as a templating language. Escaping everything (and security in general) should be the default, not something that you have to opt into at every turn.

[TeMPOraL]

True, though as you note, this is essentially true of any form of plain string concatenation. Dedicated templating languages tend to fail at this too.

Escaping-as-default helps, but people sometimes forget escaping is a function of output context. For example,

  <script>
    frobnicate("{bar}");
  </script>

is a potential vulnerability if the default escaping mechanism for {bar} is one meant for HTML.

[gabordemooij]

you can actually 100% separate HTML from server (or client) side logic if you wish to:

http://stampte.com/

[braveo]

I've never understood why people use templating engines in PHP. I've been an on again off again user of PHP for atleast 7 years now, and I've never understood it for exactly the reasons you outlined.

[tbrownaw]

I've worked some with both WinForms and WPF, and so far I kinda like XAML. And is you're not only working in the windows world, I hear there's a similar-in-spirit JavaScript/HTML framework being used for "new hotness" style applications. Called "electron" or something like that I think?

[wildpeaks]

In short, Electron is a tool for running Node scripts in a real DOM in Chromium (so unlike PhantomJS, it can run things like WebGL).

You can also bundle it to generate distributable desktop applications (e.g. Visual Studio Code, Atom, or the desktop Slack client).

[TeMPOraL]

Electron is that thing that bundles the whole web browser with your application so that you can write your usual web code and have it look like a desktop app.