Universal Jinja: a crazy idea for a Python-ready front end • Hacker News Board

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

#71

Post by erlehmann_ » Sat, Jul 15, 2017, 8:16 PM UTC

sametmax wrote: post #10

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

This article has some good points but the reasons we add more logic to templates are: - just pre-generating everything outside of the template can be very efficients. Especially if you language can't make everything lazy or if you have several representations for the same dataset. - designers want a bit more freedom that just printing x. Having to go back to the dev team everytime you need a little tweak is terrible…

Yes, all of those are reasons. None of those reasons apply if users wwant something understandable, maintainable and secure.

Separation of concerns is a thing that can help designers, no?

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

#72

Post by vultour » Sat, Jul 15, 2017, 8:18 PM UTC

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…

Oh god, no. I don't know if I'm missing something but pug has been single handedly the worst templating engine I've ever seen. Why would you want to write some cryptic template that somehow gets turned into HTML?

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

#73

Post by mixmastamyk » Sat, Jul 15, 2017, 8:26 PM UTC

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

So I'm thinking what the heck is pug?, and looked it up.

Looks to be "haml with templating" in a single language. Great idea.

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

#74

Post by eropple » Sat, Jul 15, 2017, 8:41 PM UTC

captainmuon wrote: post #45

deckar01 wrote: post #31

Earlier quoted context omitted.

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.

That is true, but it is somewhat alleviated by the fact that react restricts what you can (or should) do in a component. A good component has one-way data flow and behaves like a pure function (modulo some AJAX, or interfacing with non-React code, but you can isolate that pretty nicely). Yes, it is not enforces, and JSX can be a footgun. Also, the separation of concerns is along a different line (not markup / behavio…

TSX has kinda driven me nuts because react-redux connect doesn't seem to type cleanly. Has that improved?

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

#75

Post by sametmax » Sat, Jul 15, 2017, 8:47 PM UTC

captainmuon wrote: post #68

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…

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.

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

#76

Post by sametmax » Sat, Jul 15, 2017, 8:48 PM UTC

Mizza wrote: post #36

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

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

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

#77

Post by sametmax » Sat, Jul 15, 2017, 8:56 PM UTC

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…

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 components that your job is to make work together.

There is no django of the JS word. None.

And because of that, most JS projects I worked on were disposable projects, prototype in production.

Now there is no meteor in the Python word neither. But professionally, I need something solid, not an ongoing experiment.

You can make fantastic stuff with JS, but only because the platform is fantastic. The web is genius. The JS ecosystem is terrible.

But wish, I really wish the JS community would pick on the seriousness of other communities and the python one would take more risks and innovations like the JS one.

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

#78

Post by sametmax » Sat, Jul 15, 2017, 8:59 PM UTC

no_wizard wrote: post #41

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…

Why not just something like this? https://transcrypt.org/ It's Python to JS in a way that makes sense to me at least. JavaScript and Python have a lot of similarities in the languages imo especially around classes and functions

Because it's a joke. It's just not Python. Not half of the Python libs work on those things. You don't have serious introspection, most of the stdlib is missing, the stack trace doesn't work as expected, you can forget about async / await and yield from, etc.

To run Python in the browser correctly, you need the entire 3Mo Python VM. Transpiling is not enough because Python semantics are complicated as it is very, very rich.

Comparatively, js is incredibly basic.

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

#79

Post by Scarbutt » Sat, Jul 15, 2017, 9:07 PM UTC

stevebmark wrote: post #65

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…

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.

I may be wrong, but GMail doesn't seem to do SSR, you have that progress bar when it loads up, so is not really an essential prerequisite as you make it out to be.

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

#80

Post by mixmastamyk » Sat, Jul 15, 2017, 9:13 PM UTC

andrewingram wrote: post #64

jasonthevillain wrote: post #29

Earlier quoted context omitted.

That's fair. What got me thinking about these ideas were cases where having a distributed frontend felt overengineered. If you have problems where GraphQL makes sense, this would be a step in the wrong direction.

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?