The main dlang web framework, vibe.d, uses a 1:1 copy called "diet" templates (You can insert D code to be run on the server, with the arguments given to the HTTP request/response). This works very well IMO, mainly because D is a very good programming language, so you can mix very fast / expressive D code with your regular JS for client side work.
Oh god, no. I don't know if I'm missing something but pug has been single handedly the worst templating engine I've ever seen. Why would you want to write some cryptic template that somehow gets turned into HTML?
Similarly Nim templates (they are called filters in Nim) are very good. It's just Nim code with markup code interspersed, it works very well but I do admit that it could still be improved.
What I like most about it is that i can just use Nim code in my templates. I can't say the same for Django templates or (I guess) Jinja.
I'm a huge fan of Pug. Out of the various view engines I've used, it's been the most intuitive and productive for me. Pug, with it's indentation defined blocks, seems like a good fit for Python (less context-switching), though I've mainly used it with Node.js.
One peeve: managing multiple partials for a single page with mixins seems a little more complicated than necessary.
JSX is kinda nice, once you get used to it. Primarily because it's just HTML and/or your custom components, with arbitrary code execution in { } blocks.
When I see JSX in a project I can't help but notice how similar it is to PHP pages that inline all the applications logic with the template making it unreadable. When it comes to react I think JSX is even worse than PHP when javascript objects are passed in and out of JSX directives. It is so hard to debug, and a nightmare to read.
That is true, but it is somewhat alleviated by the fact that react restricts what you can (or should) do in a component. A good component has one-way data flow and behaves like a pure function (modulo some AJAX, or interfacing with non-React code, but you can isolate that pretty nicely). Yes, it is not enforces, and JSX can be a footgun. Also, the separation of concerns is along a different line (not markup / behavior / style, but between components. If you want to "theme" your website, its kind of hard). I'm not a diehard functional fan, but I find if you go with it it can actually be pretty maintainable and clean. Tooling is also very good, especially with TypeScript (TSX).
I haven't tried redux with tyepscript yet. One thing that doesn't seem to be typed correctly is immutability-helpers (it catches some errors, but some stuff seems to be `any`).
It is impressive though how often you have types when I wouldn't expect it.
It's really not that, and I think the general perception that it is causes a lot of people to look at it with suspicion or reject it outright.
JSX is a data structure with a syntax similar to XML. The angle brackets are quite similar to brackets around any other data structural literal in any other syntax.
The tag names are references to either in-scope variables/constants (when capitalized), or references to a static set of HTML element names specified by React (when lowercase). This is different from HTML or even XML because they are evaluated at runtime (plain JSX->JS compilation) or validated at compile time (e.g. TypeScript).
The attributes names are keys in the data structure's props, and the values are either static (if specified as string literals) or dynamic (if specified between curly braces). These too can be checked at runtime (with PropTypes) or at compile time (e.g. TypeScript).
By specifying dynamic props (or conditional children), the component will re-render as the values change.
I'm not aware of any other HTML-like or XML-like template language which functions the same way.
Edit: I forgot to mention, dynamic props are also exactly JavaScript/JSX expressions. Basically JSX is a macro that turns the XML-like stuff into React API calls.
Not quite true. Just because JSX resembles XML, it doesn't mean it can only output XML. Plenty of non-XML render targets exist for React: canvas, terminal, Sketch (I believe the file format is JSON).
The primary restriction is that your output can be modelled as a tree in some way, and what you find is that nearly everything falls into this category. I don't know if anyone's done it yet, but a plain-text renderer is certainly possible, I imagine it would be very similar to a terminal renderer.
No, I'm saying that JSX isn't XML, it just very loosely resembles it. It can't even naively output XML because it (currently) mandates a single root node, and XML has a doctype node as a sibling to that.
JSX transpiles down to a tree of function calls, it's literally nothing more than that, the only time it might be considered XML is in the final rendered content. Syntactically, JSX isn't even valid XML.
>This is also why "templating languages" in PHP were a special kind of foolish; PHP is a templating language.
Any PHP project of any reasonable complexity will either use an existing "templating language" (by which you probably mean a framework) or be forced to create some sloppy, ad-hoc version of one, because while yes, PHP is a templating language/framework, it's also a terrible one.
In my time with PHP, I never found a PHP templating language better or more effective than using PHP itself. At the time, the big ones were Smarty and Twig; both are stump-dumb tools designed to make easy things annoying and hard things impossible.
Emitting HTML is no different from any other functional programming task. State in, HTML out. (You had to be a little clever because you had to ob_start/ob_get_buffers/ob_end, but whatever. Still better than the alternatives.)
>both are stump-dumb tools designed to make easy things annoying and hard things impossible.
What hard things, specifically? I've used Twig a lot and never found it to get in the way of anything else I was trying to do.
>You had to be a little clever because you had to ob_start/ob_get_buffers/ob_end, but whatever.
By the time you have some general abstraction to push "state" into and get "HTML" out of, and deal with output buffering, header management, etc, you've started building an ad-hoc framework.
It's been a while, but I found Twig (and most mustachealikes) just super confining. I don't want to go write a function to transform my state and then expose it to Twig, I want to write a function. (They are pure functions, of course, because...well, competence, y'know?) Just stuff like that. It all gets built to PHP, but with limiters I don't need and (IME) teams that understand functional (in the pure-function sense, not the typeclasses-and-shitting-on-people-who-don't-write-Haskell sense) programming don't either.
> By the time you have some general abstraction
Sure. It's about a dozen lines long. And the language is the actual language I'm working with, not something that needs its own parser to give me less functionality in the spirit of mollyguarding on behalf of people who make mistakes of classes I categorically refuse to allow in my systems. (Please don't mistake this as me saying "I don't write bugs." I write many, many bugs. But I structure programs such that some bugs are very, very hard not to make obvious and to avoid.)
For similar reasons, this is why almost all of my web stuff these days uses a Node backend and a React/JSX or React Native frontend. Consistency across the whole thing, buttressed by tools that encourage good practice without chopping you off at the knees.
>And the language is the actual language I'm working with, not something that needs its own parser to give me less functionality in the spirit of mollyguarding on behalf of people who make mistakes of classes I categorically refuse to allow in my systems.
Ok. But to be fair, Twig's parser is extensible, whereas PHP's isn't. And it lets you use array shorthand in PHP versions that don't support it (which is not as much of a problem as it used to be, but to me, more than worth never having to type "Array()" again.)
Have you tried the XHP functionality in Hack? It treats XML as objects and understands it in context (which is something PHP should do natively, but can't.) It seems to solve many of the footgun problems that PHP template languages do, within native code.
I'd argue that it's better to use a markup-generating DSL than a templating language to begin with. Then you simply get to use native language constructs to accomplish your goals and take advantage of the natural lexical scope of your view code to inject data into your markup. Plus, it lends itself to generating an intermediate representation, which is what enables things like virtual Dom.
I actually like Mustache/Handlebars for the sake of separation of concerns, but we're using it primarily for small simple templates for email notifications and confirmation screens and the like and not full-page stuff.
It's another tech that renders just as well on the client as the server.
