Ugh, Jinja is not an "excellent" templating language. It's a terrible broken mix of pythonisms and arbitrary-feeling restrictions and oddly missing pieces. It becomes hard to read very quickly and some of the looping idioms are just nuts. Sorry I don't have anything constructive to say here but I'm genuinely taken aback that there are apparently big fans of Jinja.
> It was never documented that you can override variables from higher scopes
But you could, and people did... because that's what people do: they try stuff that seems reasonable and if it works they use it. And then someone "fixed" it in a minor release and things started breaking. BTW the error message is
KeyError: 'undefined variable: 0'
Fun way to spend an afternoon, I can assure you.
I used Jinja2 happily for years on a web app, but that thing pretty much just styled a page for flash to sit in and drew some forms and menus. I use it now via Ansible and have come to despise it through and through.
The other day I was debugging an Ops issue only to find that it originated in a python-based executable. I soon found out it was a feature unfinished and buggy.
There is a github issue that documents it, it has been around for no less than 10 years. 5 people offered PRs that got rejected for style and they are still discussing how to fix the bug in the most pythonist way.
I'll try to find it again.
I obviously ditched the
Randomly chiming in here, but now that I've used Hiccup (in Clojure) for a few years, nothing else seems evenly remotely pleasant to use. Especially when it's hooked up to a good IDE for super-easy key bindings (emacs + paredit for me).
Also chiming in. I like Jinja and handlebars and mustache and JSX makes me want to puke. I love Ractive but hate React. Recently back on django and have done a bit of django-ractive messing about so yes it is crazy. It'll never work. You get them mixed up in your head and it makes your brain hurt. But maybe this is a better. I give it a go.
One of the big failing of Jinja in my opinion is that it's Python with only instance methods, but Python has a weird, arbitrary-seeming historic division between basic functionality being implemented as global functions versus instance methods.
So if you want to replace a character in a string, that's fine, because `replace` is an instance method:
Changed plus to dot: {{ string.replace('+', '.') }}.
but if you want to take the length of that string, you need a Jinga-specific filter to have been implemented, because getting the length is via a global function `len()` in Python. This fails:
My string is {{ len(string) }} long.
If you're just using Jinga to build some HTML or whatever and you were always in your own Python code right before the template it's not really a problem, 'cause you can just do it in said Python code. I happily used Jinga for several web apps for years.
I really started to hate it in Ansible though, where I'm often just trying to get a one-off little operation done that I would rather have obvious right there in the template source rather than having to bounce over to a one-off filter function (or invoke some other outside code), and I can do it in Jinja, but it just looks and feels like hell... which kinda defeats the purpose.
I feel like Jinja was an especially bad fit for Ansible, but as a templating language I feel like it's main strength is it's better than D'jango templates... but that doesn't matter much outside the D'Jango world.
As a logic-ful template language I think it's deficient because it omits the functional parts of Python, which - as discussed above regarding `len()` - are very core to Python, and Jinja adds them back in a different way that requires extra mental overhead to keep track of. I really like the pipes (filters) but it would have been nice to just keep the Python globals as well for consistency.
And if you really want to go logic-less with your templates, I think Mustache(-variants) would be the way to go since they're much more truly "logic-less" and they're supported across a plethora of different runtimes besides Python, giving your much more flexibility. I've never really had the patience / discipline / right use case for logic-less though, so I'm far from an expert in this area.
Jinja is just a really weird mix... it's not logic-less, but it's not Python... it's a funky half-logic mishmash. It obviously makes sense and feels right to the people that make it, and if it makes sense and feels right for you that's awesome, but I hope you can understand how could feel awkward to others.
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.
The brute-forceable admin happened around the time web2py and Django devs started having a few arguments online, like this one [1], which didn't exactly paint web2py in a good light.
