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

121–126 of 126 posts

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

#121

Post by Daishiman »

amirouche wrote: post #115

I don't understand people still using Django for their web based stuff. I was under the impression that ReactJS + aiohttp was state of the art. Please explain why I am wrong.

They have literally no point in comparison. Django deals with data, business models, form validation, messaging, and backend. You can render to templates or you can use it to host an API server, or whatever you desire.

React does literally none of those things. aiohttp is just a barebones http server with no built-in functionality.

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

#122

Post by vosper »

sametmax wrote: post #77
vosper wrote: post #19

Earlier quoted context omitted.

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…

I don't know, I put Vanilla, jQuery, Angular, React and Vue in production. I used gulp and webpack and manual setup. I used node and static js. In in end, nothing is well integrated. You would think the whole bloody "one language to rule them all" concept would make the JS stack the most integrated one of all. Well to my surprise, far from it. It's a mess of hundred of moving unstable badly documented always changing…

Oh, yeah, it's a mess right now. Debugging especially sucks. I'm hoping that given 5 more years of work on server-side JS we'll get to something that's not miserable, and that transpiling will be a thing of the past

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

#123

Post by meowface »

amyjess wrote: post #112
meowface wrote: post #35

Earlier quoted context omitted.

I like Jinja. What's a Python templating language you prefer to it?

stpl, a.k.a. SimpleTemplate. It comes with Bottle, which is the project Flask was inspired by. From what I've seen of other template languages, it resembles Mako the most, though some of the syntax superficially resembles Jinja2.

I like it too, but for larger projects I think Jinja lets you repeat yourself less.

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

#124

Post by glimmung »

shakna wrote: post #111
aepc wrote: post #91

Earlier quoted context omitted.

The templates used in web2py felt good. Dont know what happened to web2py?

web2py let arbitrary code be called by the client, and its failsafes were full of holes. So it fell out of favour.

That's just nonsense - source?

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

#125

Post by shakna »

glimmung wrote: post #124
shakna wrote: post #111

Earlier quoted context omitted.

web2py let arbitrary code be called by the client, and its failsafes were full of holes. So it fell out of favour.

That's just nonsense - source?

Handful of open CVEs in Debian. [0]

The brute-forceable admin happened around the time web2py and Django devs started having a few arguments online, like this one [1], which didn't exactly paint web2py in a good light.

[0] https://security-tracker.debian.org/tracker/source-package/w...

[1] https://www.quora.com/Is-web2py-a-good-Python-web-framework

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

#126

Post by mixmastamyk »

andrewingram wrote: post #83
mixmastamyk wrote: post #80

Earlier quoted context omitted.

Looks to be an alternative to the traditional "rest api". Would anyone care to comment on the productivity benefits of one or the other?

It's more like an enhancement of the traditional backend-for-frontend (BFFs) pattern, enabling ad-hoc endpoints (based on queries) rather than static ones. The main productivity benefit comes from the fact that the query language is a very good fit for the component model. Each component can declare its data dependencies in the form of query fragments, and these get composed into a single query for the entire UI. It…

:D

https://news.ycombinator.com/item?id=14839576

Post reply on HN