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

21–30 of 126 posts

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

#21

Post by zepolen »

I've done this many years ago with https://github.com/wkral/jinja2js

It works - but there are gotchas:

1. You can't depend on useful pythonisms/javascriptisms such as

  {{thing or ""}} vs {{thing || ""}
2. Template filter code still has to be duplicated in both languages - i18n such as {{_('String')}} for example - which sort of makes sense - but then you have to do the same for some other, really trivial, filters.

3. Testing becomes annoying because a template can work in one, and not the other - you have to test both.

4. You don't get the newer html diff style virtual dom rendering which can cause issues with stuff like select boxes. You end up with special case code to handle that, which is more of a hassle.

The conclusions from it all were:

a) You do save time over doing it once in python, once in js

b) You don't save time over doing it all in js - especially if you use a newer functional style js template framework (react/vue/polymer)

c) You can still get the best of both worlds by hooking up your templates in js to be rendered by your backend - eg like https://github.com/reactjs/react-rails does.

In the end for my next project I decided to do an api for the backend in python and the website/frontend in react with SSR, and am really thrilled with the results - very maintainable, testable and simple overall.

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

#23

Post by nilved »

vosper wrote: post #20
snissn wrote: 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.

From that description it sounds nightmarish.

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

#24

Post by jasonthevillain »

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.

Oh, I know exactly what you're talking about. I've seen Jinja code that assumes "Jinja has this feature, so I should use it."

I'm not sure that's the template language's fault and more than Python is responsible for Python code that goes metaclass happy for no reason.

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

#25

Post by mhh__ »

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"?

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

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

#26

Post by ben_jones »

Can someone explain to me why we haven't normalized html templating with a Pug-like syntax (formally Jade)?

My perceived benefits of Pug/Jade:

* Significantly fewer LOC

* Improved Readability

* A lot of existing tooling thanks to its popularity in the NodeJS community

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

#27

Post by paulddraper »

vosper wrote: post #20
snissn wrote: 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.

Apples and oranges. (Or fruits and oranges?) JSX can only do XML; Jinja is for arbitrary text.

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

#28

Post by jjawssd »

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.

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

#29

Post by jasonthevillain »

omegaworks wrote: post #9

Ugh. After living in frontend land (native mobile and react) I'm really not looking forward to going back to Django. It feels so irrelevant in the world of backend-as-a-service and GraphQL. ...Please forgive my cynicism. I am looking for a reason to like this. Maybe I should just move on.

That's fair.

What got me thinking about these ideas were cases where having a distributed frontend felt overengineered. If you have problems where GraphQL makes sense, this would be a step in the wrong direction.

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

#30

Post by brianwawok »

sametmax wrote: post #11
dchuk wrote: post #8

I've been working on a site recently, in Rails, and just been using Turbolinks and SJR (Server Javascript Responses). Granted, it's a content heavy site with fairly light ajax interactions, but it's a pretty delightful process. So many people jump to heavy JS libs/frameworks to do stuff that can be solved in much more boring/simple ways most of the time. You don't need React/Angular/Vue to submit a form over ajax.

Nobody said that. We just said "if your side IS js heavy, then rendering on the server would be nice". Not all sites need a lot of JS. But your tweeter clone is going to be very boring if you have to hit F5 every 30 seconds and polling doesn't really scale.

Why don't you think polling scales? I would argue the exact opposite that polling scales great. To a public api can you cache to your hearts delight. To a private api you can shard away.
Post reply on HN