Live data from Hacker News

Universal Jinja: a crazy idea for a Python-ready front end

whatisjasongoldstein.com

91–100 of 126 posts

Re: Universal Jinja: a crazy idea for a Python-ready front end

#91

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?

Re: Universal Jinja: a crazy idea for a Python-ready front end

#92

"Isomorphic" templates are not enough. You also need isomorphic data fetching for client code. If you have to manually reinvent the same data fetching on the client and server, you don't get the full benefits of isomorphic code. You only have brittle templates with two different ways to glue data to view. So far isomorphic Node + React has been the best (but not perfect) way I've seen to do this. You abstract out the…

> Until browsers support a different language natively other than Javascript (which will never happen), Node + React is currently the most straightforward path to get there.

I think WebAssembly is promising for this. You could write your app in any language you want, as long as it compiles to WebAssembly.

Re: Universal Jinja: a crazy idea for a Python-ready front end

#93
post #90
post #85

Earlier quoted context omitted.

>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…

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 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.

Re: Universal Jinja: a crazy idea for a Python-ready front end

#94
post #72
post #25

Earlier quoted context omitted.

Pug templates( https://pugjs.org/api/getting-started.html ) are fairly nice. 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…

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?

For me, forcing me to be good about whitespace is very nice, no closing tags is even better, but the real kicker is

    .sep
vs

    
So short and concise! And the "somehow" isn't that magical... The code you right else where ultimately gets transformed into something else, too!

Re: Universal Jinja: a crazy idea for a Python-ready front end

#95
post #94
post #72

Earlier quoted context omitted.

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?

For me, forcing me to be good about whitespace is very nice, no closing tags is even better, but the real kicker is .sep vs So short and concise! And the "somehow" isn't that magical... The code you right else where ultimately gets transformed into something else, too!

Typed that mobile and wish I could edit it... Sorry!

Re: Universal Jinja: a crazy idea for a Python-ready front end

#96

Would not recommend using Nunjucks, unless you would like to contribute to maintaining it. https://github.com/mozilla/nunjucks/blob/master/CONTRIBUTING...

Actually, we've started maintaining Nunjucks at The Atlantic (it's in the references of jasonthevillain article).

Re: Universal Jinja: a crazy idea for a Python-ready front end

#97
post #20
post #16

Earlier quoted context omitted.

What is a "good template language"?

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.

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.

Re: Universal Jinja: a crazy idea for a Python-ready front end

#98
post #16

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.

What is a "good template language"?

I like EJS, because it looks as much like normal JS as possible.

http://ejs.co/

Re: Universal Jinja: a crazy idea for a Python-ready front end

#99
post #28

Earlier quoted context omitted.

I'd like to hear more about: - the broken mix of pythonisms - the arbitrary-feeling restrictions - the oddly missing pieces Because I can't find any.

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 ditche…

Fastest solution: fork the code and merge the PRs into your own branch yourself.

Re: Universal Jinja: a crazy idea for a Python-ready front end

#100

Earlier quoted context omitted.

I like Jinja. What's a Python templating language you prefer to it?

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.

Your "x and x and and x" sentence is about hard to parse! I was wondering whether you hated handlebars and mustache also.
Post reply on HN