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

101–110 of 126 posts

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

#101

Post by wbillingsley »

rhaps0dy wrote: post #87
cyberpanther wrote: post #67

Earlier quoted context omitted.

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

I have a bad feeling about this...

  ObiWan:   deals_in_absolutes ==> Sith  
  rhapsOdy: mathematician ==> deals_in_absolutes
  ----------------------------------------------
  therefore ...
We may have to wrap this in spoiler tags for Episode 9.

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

#102

Post by stevebmark »

Scarbutt wrote: post #79
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.

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.

I agree that server side rendering of gmail would greatly speed up the load and remove the need for a progress bar. The word on the street is Gmail has too much legacy code in it to much modernizing with. It's also one of the few very special apps that users tend to keep open forever in a tab, and never do page navigation. Definitely don't use GMail as your benchmark unless you're making something as specialized and popular as what they have now.

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

#103

Post by StavrosK »

wbillingsley wrote: post #101
rhaps0dy wrote: post #87

Earlier quoted context omitted.

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

I have a bad feeling about this... ObiWan: deals_in_absolutes ==> Sith rhapsOdy: mathematician ==> deals_in_absolutes ---------------------------------------------- therefore ... We may have to wrap this in spoiler tags for Episode 9.

The logic is inescapable.

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

#104

Post by captainmuon »

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.

You have things like IronPython or MicroPython, which are different from cPython but good enough.

When I say transpiler, I don't mean just mapping one syntax to another. I mean either really compiling to JS, or having a python bytecode interpreter in JS. It is possible to compile very different languages to JS, for example Nim.

I think it should be possible to support 100% of the core language - even metaclasses, why should that feature be more difficult? Of course you would not map Python classes to JS classes! You would map Python classes to something else, like opaque JS objects.

It is not realistic to support 100% of the library, but that is not neccessary - on the frontend, you wouldn't need to use most libraries, and you don't need C FFI. Most of the time, you'll be only pushing JSON or python objects into templates.

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

#105

Post by captainmuon »

eropple wrote: post #74
captainmuon wrote: post #45

Earlier quoted context omitted.

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?

I haven't tried redux with tyepscript yet. One thing that doesn't seem to be typed correctly is immutability-helpers (it catches some errors, but some stuff seems to be `any`).

It is impressive though how often you have types when I wouldn't expect it.

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

#106

Post by dgoldstein0 »

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.

in my experience, a lot of SPA-like pages are slow because their authors didn't think to async-load code that they don't immediately need. When we async load the larger not-immediately-needed components, the page gets faster. Optimizing the data fetching is also important but the simple ways to support server rendering are to eliminate ajax calls for initial data fetching, which is often an improvement anyway.

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

#107

Post by inimino »

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

- operator overriding - look up interception API - metaclasses - embdedded design patterns: iterator, singleton, context manager, etc. - multiple inheritance - standardised imports, with hooks - controlled gc

One of the best things about JS is that is has none of these features. Smaller languages are better, and blindly adding features is not the way to improve a language.

Unfortunately, nothing in JS can ever really go away, so it's starting to leave the "small language" sweet spot.

JS is better than Ruby by being smaller and infinitely better specified. Go is a nicer language due to being designed from scratch recently by people with excellent taste.

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

#108

Post by draegtun »

penpapersw wrote: post #40
meowface wrote: post #35

Earlier quoted context omitted.

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

Just to note they are equivalents in other languages including Hiccup's grandfather CL-WHO - https://stackoverflow.com/questions/671572/cl-who-like-html-...

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

#109

Post by amyjess »

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 agree. So far, my favorite templating language is stpl, which comes with Bottle.
Post reply on HN