Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

whatisjasongoldstein.com

Post reply on HN
Print view View original

41–50 of 126 posts

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

#41

Post by no_wizard »

sametmax wrote: post #5

I was wondering if we should not code a Python renderer for one JS framework and be done with it. We already have one JS engine in Python ( https://github.com/kovidgoyal/dukpy ). We even have pluggable renderers ( https://pypi.python.org/pypi/PyExecJS ). Later we will have webassembly renderers in Python, so you will be able to take frontend frameworks, compile them and execute them in Python. Finally, we have some f…

Why not just something like this? https://transcrypt.org/

It's Python to JS in a way that makes sense to me at least. JavaScript and Python have a lot of similarities in the languages imo especially around classes and functions

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

#42

Post by nrser »

jjawssd wrote: post #28
skywhopper wrote: post #14

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.

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.

Check this fiasco out for starters:

https://github.com/pallets/jinja/issues/659

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

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

#43

Post by eropple »

nilved wrote: post #23
vosper wrote: post #20

Earlier quoted context omitted.

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.

From that description it sounds nightmarish.

That "arbitrary code execution" is functional viewmodel stuff. It makes complete sense once you've spent more than an hour with it.

(This is also why "templating languages" in PHP were a special kind of foolish; PHP is a templating language.)

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

#44

Post by eropple »

deckar01 wrote: post #31
vosper wrote: post #20

Earlier quoted context omitted.

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.

This is why the React Inspector exists, and it's very very good at what it does.

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

#45

Post by captainmuon »

deckar01 wrote: post #31
vosper wrote: post #20

Earlier quoted context omitted.

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

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

#46

Post by dochtman »

I actually wrote a JavaScript code generator for Jinja, which allows you to use the Jinja parser and AST and generate pretty readable and fairly sane JavaScript code (for a pretty large subset of full Jinja). I actually used this in my startup (now long dead) where we were able to reuse quite a lot of template code both on the server and the client.

https://github.com/djc/jasinja

This is in some (conceptual/experiential) ways a precursor to my recent attempt to create a Rusty Jinja-like, which tries hard to take the best ideas from Jinja and mash it up with the best ideas from Rust:

https://github.com/djc/askama

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

#47

Post by Pxtl »

snissn wrote: post #16
skywhopper wrote: post #14

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

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

#48

Post by trumpownsyou »

deckar01 wrote: post #31
vosper wrote: post #20

Earlier quoted context omitted.

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.

sounds like you suck at JSX. it's truly a joy to work with once you get the hang of it.

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

#49

Post by cyberpanther »

I usually ignore server side rendering or isomorphic rendering. I'm not saying all projects should ignore it but you're really talking about a high level of optimization if you need it. And if you're reaching that level of optimization you probably shouldn't use Python.

Server side rendering only makes the first view faster. After that, everything is rendered on the client and faster that way. And if you use caching with progressive web apps or just file caching in general, the first view will be fast after. So you're only optimizing for the first of the first. You can then provide the initial data in the page request so that saves a round trip on the first request while still rendering on the frontend.

I say all this to just point out that there are many ways to speed up your frontend without doing SSR and they are much easier to implement with Python. So I'd rather exhaust all these techniques before implementing SSR. If I get to that point though, I suspect Python might be the slowest part of your stack. And lastly if you are doing SSR for SEO purposes then just use a prebuilt prerender service.

With all that said if there was an easier way to SSR with Python/Django, I'd definitely use it. But Jinja on the frontend doesn't sound like that answer.

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

#50

Post by acjohnson55 »

snissn wrote: post #16
skywhopper wrote: post #14

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'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.
Post reply on HN