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

11–20 of 126 posts

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

#11

Post by sametmax »

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.

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

#12

Post by sametmax »

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.

I had the opposite experience. Every time I see a JS project trying to do a bit of custom registration and some serious DB design, it's such a pain. The JS stack is great for pretty stuff, but the basics require so much boiler plate.

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

#13

Post by dchuk »

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.

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)

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

#14

Post by skywhopper »

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.

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

#15

Post by chickenfries »

erlehmann_ wrote: post #6

Templates cause bugs. The solitary appropriate solution is an unparser – a component that walks an AST and serializes it. Making sure the result conforms to the grammar of the output language without any unparser would always involve a parser. > As soon as I'm looking at more than one programming or markup language in the same file, I'm looking at spaghetti code. Iain Dooley, December 2011 http://www.workingsoftware.…

> you simply include everything in the markup that might need to be there, and the programmer removes whatever is not necessary

I realize you may not be cosigning on everything in the article you're quoting, but this is the author's first suggestion to an alternative to template languages.

I work on an SPA that was built like this. The index.html is over 10k lines long. It contains almost every single piece of the UI. Templating libraries and languages aren't perfect but they offer a better separation of concerns than just "dump it all in one file and write some imperative dom fiddling code to add different states"

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

#16

Post by snissn »

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

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

#19

Post by vosper »

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…

I've just got back into the Javascript world after several years of Python programming. My gut feeling is that we will end up with APIs in some language, and universal [0] Javascript apps that can render both client and server side. I don't think there's a place for non-Javascript server-side templating in the long run. JS (as a language, forgetting about the frameworks) has really come a long way in the last few years, to the point where I don't think you'll be able to justify having two different HTML rendering systems for much longer.

[0] aka isomorphic, but universal seems to be the new (IMO better, less overloaded) term for that

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

#20

Post by vosper »

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

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