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

51–60 of 126 posts

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

#51

Post by erikpukinskis »

cyberpanther wrote: post #49

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…

> Server side rendering only makes the first view faster.

The first view is the most important view, and making it faster is often the most beneficial thing you could do for engagement.

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

#52

Post by alexanderdmitri »

mhh__ wrote: post #25
snissn wrote: post #16

Earlier quoted context omitted.

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…

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.

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

#53

Post by Cyph0n »

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

Jinja is great. I'm also a fan of Play's Twirl.

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

#54

Post by sametmax »

dchuk wrote: post #13
sametmax wrote: post #11

Earlier quoted context omitted.

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.

So use push rather than polling? My point is that many sites don't really need to be as js heavy as they end up, and people end up solving the wrong problem (how to render all this js server side rather than how to reduce all this js in the first place)

Push requires js as well.

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

#55

Post by louiskottmann »

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.

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

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

#56

Post by dchuk »

sametmax wrote: post #54
dchuk wrote: post #13

Earlier quoted context omitted.

So use push rather than polling? My point is that many sites don't really need to be as js heavy as they end up, and people end up solving the wrong problem (how to render all this js server side rather than how to reduce all this js in the first place)

Push requires js as well.

I'm not saying don't use JavaScript, I'm saying don't abuse it and then try to dig yourself out of that hole with server rendering. Use the tools you have to the fullest extent that do the job perfectly well before reaching for other ones.

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

#57

Post by InstanceOf »

ben_jones wrote: post #26

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

Vuejs can be configured to use pug.

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

#58

Post by cyberpanther »

erikpukinskis wrote: post #51
cyberpanther wrote: post #49

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…

> Server side rendering only makes the first view faster. The first view is the most important view, and making it faster is often the most beneficial thing you could do for engagement.

Valid point. In addition to technical optimizations besides SSR, you can make perceived improvements too. If you get a first initial paint in one second lets says, you're not going to hurt engagement. There are plenty of tricks you can pull out first before you need SSR.

Sure if you're using Node.js pull out SSR first since its easier. But for Python right now, it's not the easiest thing.

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

#59

Post by nthcolumn »

meowface wrote: post #35
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 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.

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

#60

Post by mythrwy »

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 like Jinja. It's straightforward, easy to reason about. I'm a bit taken aback that you _aren't_ a big fan.
Post reply on HN