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

81–90 of 126 posts

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

#81

Post by mixmastamyk »

sametmax wrote: post #75
captainmuon wrote: post #68

Earlier quoted context omitted.

Or, the other way around: Write a react clone in Python (complete with "pyx" files), and then use one of the python to js transpilers to compile to js on the frontend. On the backend, you'd use "react" just as another simple template language, whereas on the frontend, you'd also have the reconcilation algorithm.

You will never get a perfect Python on JS, only a mockery of it. It would be more confusing than anything. Beside, transpilers add tons of complexity, and this complexity increase more when the language is very different from JS.

Aren't ES6+ more like Python (or Coffeescript) now than ever? But yes, complexity.

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

#82

Post by eropple »

krapp wrote: post #66
eropple wrote: post #43

Earlier quoted context omitted.

That "arbitrary code execution" is functional viewmodel stuff. It makes complete sense once you've spent more than an hour with it. (This is also why "templating languages" in PHP were a special kind of foolish; PHP is a templating language.)

>This is also why "templating languages" in PHP were a special kind of foolish; PHP is a templating language. Any PHP project of any reasonable complexity will either use an existing "templating language" (by which you probably mean a framework) or be forced to create some sloppy, ad-hoc version of one, because while yes, PHP is a templating language/framework, it's also a terrible one.

In my time with PHP, I never found a PHP templating language better or more effective than using PHP itself. At the time, the big ones were Smarty and Twig; both are stump-dumb tools designed to make easy things annoying and hard things impossible.

Emitting HTML is no different from any other functional programming task. State in, HTML out. (You had to be a little clever because you had to ob_start/ob_get_buffers/ob_end, but whatever. Still better than the alternatives.)

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

#83

Post by andrewingram »

mixmastamyk wrote: post #80
andrewingram wrote: post #64

Earlier quoted context omitted.

To be honest, I'd use GraphQL at any scale. I've recently used it in programming challenges for job interviews, and I've used it in production for about 18 months. It's such a good conceptual fit for front-end, that it now feels strange to work any other way.

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 means every time you use a component, you can be sure that you'll have the data you need.

I should add that none of this is a unique capability of GraphQL, I know people who've built similar component-data binding with JSON-API, but it's the full package that's compelling. The query language is lovely to work with. You can build GraphQL schemas around the needs of clients, allowing you to hide any weird data modelling or service boundaries you may have in your platform. As an API designer, as well as a front-end developer, I love it.

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

#84

Post by chickenfries »

erlehmann_ wrote: post #69
chickenfries wrote: post #15

Earlier quoted context omitted.

> 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…

Note that I made a different proposal above the quote. I think SPAs are either fundamentally dishonest engineering, in the same way that a microwave wrapped in artificial wood veneer is (and a stainless steel microwave is not) or should result in such a template. If you really think that this is too much, IMO you should not make an SPA in the first place.

> I think SPAs are either fundamentally dishonest engineering, in the same way that a microwave wrapped in artificial wood veneer is (and a stainless steel microwave is not) or should result in such a template.

Could you rephrase or expound on this metaphor? I have no idea what you mean by "fundamentally dishonest engineering" or what that has to do with SPAs and templates.

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

#85

Post by krapp »

eropple wrote: post #82
krapp wrote: post #66

Earlier quoted context omitted.

>This is also why "templating languages" in PHP were a special kind of foolish; PHP is a templating language. Any PHP project of any reasonable complexity will either use an existing "templating language" (by which you probably mean a framework) or be forced to create some sloppy, ad-hoc version of one, because while yes, PHP is a templating language/framework, it's also a terrible one.

In my time with PHP, I never found a PHP templating language better or more effective than using PHP itself. At the time, the big ones were Smarty and Twig; both are stump-dumb tools designed to make easy things annoying and hard things impossible. Emitting HTML is no different from any other functional programming task. State in, HTML out. (You had to be a little clever because you had to ob_start/ob_get_buffers/ob_…

>both are stump-dumb tools designed to make easy things annoying and hard things impossible.

What hard things, specifically? I've used Twig a lot and never found it to get in the way of anything else I was trying to do.

>You had to be a little clever because you had to ob_start/ob_get_buffers/ob_end, but whatever.

By the time you have some general abstraction to push "state" into and get "HTML" out of, and deal with output buffering, header management, etc, you've started building an ad-hoc framework.

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

#86

Post by sametmax »

mixmastamyk wrote: post #81
sametmax wrote: post #75

Earlier quoted context omitted.

You will never get a perfect Python on JS, only a mockery of it. It would be more confusing than anything. Beside, transpilers add tons of complexity, and this complexity increase more when the language is very different from JS.

Aren't ES6+ more like Python (or Coffeescript) now than ever? But yes, complexity.

More yes, they have catched up on syntax. But they are far, far away in term of features. Even if we completly discard the huge and fantastic python stdlib (but really, no hashing or uuid in web language ?), Python has still:

- operator overriding

- look up interception API

- metaclasses

- embdedded design patterns: iterator, singleton, context manager, etc.

- multiple inheritance

- standardised imports, with hooks

- controlled gc

- dict comprehension

- generator expressions

- type hints

- string formatting language and operations

- much more comfortable lists

- rich built ins (all, any, enumerate, zip...)

- no weird implicit type casting and comparison rules

- stack traces and very explicit error messages

- support of a lot of charsets out of the box

- multiple notations for text and numbers

- types for bytes

- support for imaginary numbers

And so much more.

Because Python is such an easy language to use, it's easy to think it's just a simple scripting language.

It's not.

It is very, very powerful.

But it has such a smooth learning curve and you can be productive in it so quickly a lot of people never need to see it.

You can compare Ruby to Python. Or Go.

But JS ? It's not even on the same planet. The only reason this abomination has this success is because it has an accidental monopoly on the most awesome and popular platform of the human race: the web.

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

#87

Post by rhaps0dy »

cyberpanther wrote: post #67
stevebmark wrote: post #65

Earlier quoted context omitted.

If you're writing a SPA, server side rendering is probably the most important optimization you can make to speed up your application. No other optimization will come close to the benefits of server rendering. SPAs are both slow and perceived as slow. True SPAs are only appropriate for a subset of the web where you have very specific user constraints.

> No other optimization will come close to the benefits of server rendering. "Only the Sith deal in absolutes", Obi-Wan Kenobi

Mathematicians also deal in absolutes! Not just the abs function, also proofs and counterexamples.

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

#88

Post by mixmastamyk »

sametmax wrote: post #86
mixmastamyk wrote: post #81

Earlier quoted context omitted.

Aren't ES6+ more like Python (or Coffeescript) now than ever? But yes, complexity.

More yes, they have catched up on syntax. But they are far, far away in term of features. Even if we completly discard the huge and fantastic python stdlib (but really, no hashing or uuid in web language ?), Python has still: - operator overriding - look up interception API - metaclasses - embdedded design patterns: iterator, singleton, context manager, etc. - multiple inheritance - standardised imports, with hooks -…

Nice work, thanks.

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

#89

Post by Mizza »

sametmax wrote: post #76
Mizza wrote: post #36

Earlier quoted context omitted.

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 aga…

Cool. Does that parse JS in Python or generate JS from python ?

Generates JavaScript from Django QuerySets in a single template tag.

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

#90

Post by eropple »

krapp wrote: post #85
eropple wrote: post #82

Earlier quoted context omitted.

In my time with PHP, I never found a PHP templating language better or more effective than using PHP itself. At the time, the big ones were Smarty and Twig; both are stump-dumb tools designed to make easy things annoying and hard things impossible. Emitting HTML is no different from any other functional programming task. State in, HTML out. (You had to be a little clever because you had to ob_start/ob_get_buffers/ob_…

>both are stump-dumb tools designed to make easy things annoying and hard things impossible. What hard things, specifically? I've used Twig a lot and never found it to get in the way of anything else I was trying to do. >You had to be a little clever because you had to ob_start/ob_get_buffers/ob_end, but whatever. By the time you have some general abstraction to push "state" into and get "HTML" out of, and deal with…

It's been a while, but I found Twig (and most mustachealikes) just super confining. I don't want to go write a function to transform my state and then expose it to Twig, I want to write a function. (They are pure functions, of course, because...well, competence, y'know?) Just stuff like that. It all gets built to PHP, but with limiters I don't need and (IME) teams that understand functional (in the pure-function sense, not the typeclasses-and-shitting-on-people-who-don't-write-Haskell sense) programming don't either.

> By the time you have some general abstraction

Sure. It's about a dozen lines long. And the language is the actual language I'm working with, not something that needs its own parser to give me less functionality in the spirit of mollyguarding on behalf of people who make mistakes of classes I categorically refuse to allow in my systems. (Please don't mistake this as me saying "I don't write bugs." I write many, many bugs. But I structure programs such that some bugs are very, very hard not to make obvious and to avoid.)

For similar reasons, this is why almost all of my web stuff these days uses a Node backend and a React/JSX or React Native frontend. Consistency across the whole thing, buttressed by tools that encourage good practice without chopping you off at the knees.

Post reply on HN