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.
The templates used in web2py felt good. Dont know what happened to web2py?
Universal Jinja: a crazy idea for a Python-ready front end
111–120 of 126 posts
Re: Universal Jinja: a crazy idea for a Python-ready front end
#112Ugh, 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.
I like Jinja. What's a Python templating language you prefer to it?
From what I've seen of other template languages, it resembles Mako the most, though some of the syntax superficially resembles Jinja2.
Re: Universal Jinja: a crazy idea for a Python-ready front end
#113Earlier quoted context omitted.
Apples and oranges. (Or fruits and oranges?) JSX can only do XML; Jinja is for arbitrary text.
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…
Re: Universal Jinja: a crazy idea for a Python-ready front end
#114Earlier quoted context omitted.
More yes, they have catched up on syntax. But they are far, far away in term of features. Even if we completly discard the huge and fantastic python stdlib (but really, no hashing or uuid in web language ?), Python has still: - operator overriding - look up interception API - metaclasses - embdedded design patterns: iterator, singleton, context manager, etc. - multiple inheritance - standardised imports, with hooks -…
- operator overriding - look up interception API - metaclasses - embdedded design patterns: iterator, singleton, context manager, etc. - multiple inheritance - standardised imports, with hooks - controlled gc One of the best things about JS is that is has none of these features. Smaller languages are better, and blindly adding features is not the way to improve a language. Unfortunately, nothing in JS can ever really…
In your opinion. There are entire platforms, with literally millions of programmers, which say otherwise - like .NET or C++ for example.
My opinion? There's no point in calling a language better without qualifying a context or use-case. There are so many languages, with so many different (takes on) features, that it's frequently impossible to even meaningfully compare them. Much less to say which is better.
In other words, I can agree with your statement, that "smaller languages are better", for example in fitting your tastes or in ease of implementation. I won't agree that smaller languages are "better" universally, however, because it's trivial to show the contrary. It's enough to point to all the "transpilers", template- or macro-systems that are being written all the time, nearly always for small languages. If smaller is universally better, then how come so many people want more features and are willing to invest their time to write a transpiler?
Personally, I like small, elegant languages - but I also like the big, pragmatic languages, the weird and experimental languages, the special-purpose and exotic languages and so on. Each has its uses and may be a good tool in the hands of a professional.
Re: Universal Jinja: a crazy idea for a Python-ready front end
#115Re: Universal Jinja: a crazy idea for a Python-ready front end
#116Earlier quoted context omitted.
I like Jinja. What's a Python templating language you prefer to it?
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).
Re: Universal Jinja: a crazy idea for a Python-ready front end
#117Earlier quoted context omitted.
More yes, they have catched up on syntax. But they are far, far away in term of features. Even if we completly discard the huge and fantastic python stdlib (but really, no hashing or uuid in web language ?), Python has still: - operator overriding - look up interception API - metaclasses - embdedded design patterns: iterator, singleton, context manager, etc. - multiple inheritance - standardised imports, with hooks -…
- operator overriding - look up interception API - metaclasses - embdedded design patterns: iterator, singleton, context manager, etc. - multiple inheritance - standardised imports, with hooks - controlled gc One of the best things about JS is that is has none of these features. Smaller languages are better, and blindly adding features is not the way to improve a language. Unfortunately, nothing in JS can ever really…
Re: Universal Jinja: a crazy idea for a Python-ready front end
#118Earlier quoted context omitted.
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 sens…
>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 muc…
Re: Universal Jinja: a crazy idea for a Python-ready front end
#119Earlier quoted context omitted.
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…
If you're saying that JSX can do more than XML because you can transform from XML into other things, then yes, that's trivially true.
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.
Re: Universal Jinja: a crazy idea for a Python-ready front end
#120Ugh, 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.
I like Jinja. It's straightforward, easy to reason about. I'm a bit taken aback that you _aren't_ a big fan.
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.