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

31–40 of 126 posts

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

#31

Post by deckar01 »

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.

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.

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

#32

Post by s_kilk »

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

Probably just the cost of making high-quality ports of Pug in every language.

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

#33

Post by benologist »

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

It seems to me like headless browsing (now in Node) will make it pretty easy to construct your page using the DOM directly on the server without scattered logic and DSLs.

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

#34

Post by RobertoG »

vosper wrote: post #19
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 yea…

You are, my friend, an optimist.

After learn and forget a few js frameworks, see develop the "compile to javascript" fashion, javascript jumping to the server, the different flavours of MVC, "isomorphic programming", subsets of javascript that compile to whatever and etc..; my gut feeling is that it will never end.

If that is a good or bad thing is left as an exercise for the reader.

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

#35

Post by meowface »

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?

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

#36

Post by Mizza »

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 actually took a stab at this for a now out-of-favor JS framework, Knockout.js.

You can see the project here: https://github.com/Miserlou/django-knockout-modeler

It allows you to take a single Django QuerySet and turn it into a SPA with in-page listing, sorting, filtering with a single Django template tag:

{{ my_query_set|knockout }}

I used in production in a few projects and was very happy. If I were to do this again, I'd re-do it for Vue.js and make the data-syncing bi-directional. But I hope we see more stuff like this.

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

#37

Post by jasonthevillain »

bastawhiz wrote: post #4

I see a few problems. The biggest problem is testability. Testing that a template renders correctly means parsing the markup into a DOM and asserting that certain conditions are met. This is exacerbated by the differences between Jinja and Nunjucks, which can be non-trivial and unexpected (e.g., Jinja will render synchronously, while Nunjucks can render asynchronously--weird async behavior may appear). Since your app…

Agreed, testability is a big problem, I'll add a note. Thanks.

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

#38

Post by dom96 »

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…

Similarly Nim templates (they are called filters in Nim) are very good. It's just Nim code with markup code interspersed, it works very well but I do admit that it could still be improved.

What I like most about it is that i can just use Nim code in my templates. I can't say the same for Django templates or (I guess) Jinja.

https://nim-lang.org/docs/filters.html

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

#39

Post by dchuk »

brianwawok wrote: post #30
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.

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.

Also a good point. Polling is also a very straightforward and reliable system, and can be very efficiently with both caching and returning empty responses when nothing has changed, etc

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

#40

Post by penpapersw »

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?

Randomly chiming in here, but now that I've used Hiccup (in Clojure) for a few years, nothing else seems evenly remotely pleasant to use. Especially when it's hooked up to a good IDE for super-easy key bindings (emacs + paredit for me).
Post reply on HN