Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

React, but in Python

github.com

Post reply on HN
Print view View original

21–30 of 179 posts

Re: React, but in Python

#21

Post by onion2k »

quechimba wrote: post #16
ledauphin wrote: post #13

Earlier quoted context omitted.

yes, from reading the docs, there's a websocket. Making a 'server call' on each interaction is also what web apps used to do before SPAs were a thing. And in many cases it's what SPAs do as well. Of course, it depends what counts as an 'interaction', but that's been the case since JavaScript existed.

Yep. And nowadays you can deploy apps really close to users so latency is really low. If you have <100ms you don't really notice the latency.

Proximity is only part of the equation. If a user has a slow router or a busy corporate firewall to go through their timings can be far higher than 100ms even if the server is a few miles away.

Re: React, but in Python

#22

Post by uhtred »

recursive wrote: post #12
uhtred wrote: post #2

I thought generating html from function calls went out with the dinosaurs. We back doing it again?

I mean, react does it. It never left. JSX compiles to function calls.

yes but no one generates html from the function calls directly in react (even though you could if you wanted), they use jsx which is at least a bit like writing html.

Re: React, but in Python

#23

Post by uhtred »

loloquwowndueo wrote: post #4
uhtred wrote: post #2

I thought generating html from function calls went out with the dinosaurs. We back doing it again?

https://htmx.org/ Says otherwise, so does https://blog.appsignal.com/2022/07/06/get-started-with-hotwi...

I haven't used htmx but it looks nothing like pyreact. htmx is about adding attributes to html, so again, you are still writing html.

Re: React, but in Python

#25

Post by moritzwarhier »

Solvency wrote: post #19
quechimba wrote: post #16

Earlier quoted context omitted.

Yep. And nowadays you can deploy apps really close to users so latency is really low. If you have <100ms you don't really notice the latency.

But... 99% of insert-startup-product-built-on-React (or honestly, any framework) is typically super slow (for whatever reason that might be). Sluggish, not super responsive, laggy UI, however you want to describe it. A far cry from the snappiness of desktop apps from 25+ years ago. Something or some collection of people are doing something wrong, somewhere in the chain. So isn't this just yet another way to further e…

Your statement is very broad. Might be the startup culture and lacking technological expertise, no?

Was insert-startup-product-built-on-.NET fast 15 years ago, for example?

Not trying to be controversial, just wondering.

I agree that a product built by clueless developers stringing together random libraries or bad custom code in React would create slow products.

In your spirit, I might argue that thinking "reactively" and client-centric tends to lead to unneeded requests.

Developing without meaningful API contracts or basic CS skills also makes it easy to unintendedly blow up network payloads.

Caching is hard though.

Have you worked on bad PHP applications that reload on every interaction without caching?

Re: React, but in Python

#26

Post by Izkata »

nawgz wrote: post #8
cantSpellSober wrote: post #6

Earlier quoted context omitted.

Why?

He means API calls, obviously overloaded the term "function calls" a bit In this case, I think it's also clear that most things you'd call an "application" abhor this behavior, which is why heavy clients are so popular, and small shops without frontend engineering talent are making a big push away from heavy clients which raises all the hubbub about HTMX etc

No, he meant function calls as opposed to JSX, clarified in another comment.

Re: React, but in Python

#27

Post by dustingetz »

Solvency wrote: post #19
quechimba wrote: post #16

Earlier quoted context omitted.

Yep. And nowadays you can deploy apps really close to users so latency is really low. If you have <100ms you don't really notice the latency.

But... 99% of insert-startup-product-built-on-React (or honestly, any framework) is typically super slow (for whatever reason that might be). Sluggish, not super responsive, laggy UI, however you want to describe it. A far cry from the snappiness of desktop apps from 25+ years ago. Something or some collection of people are doing something wrong, somewhere in the chain. So isn't this just yet another way to further e…

manual network state sync between frontend and backend is the root cause of that

Re: React, but in Python

#28

Post by resoluteteeth »

nawgz wrote: post #8
cantSpellSober wrote: post #6

Earlier quoted context omitted.

Why?

He means API calls, obviously overloaded the term "function calls" a bit In this case, I think it's also clear that most things you'd call an "application" abhor this behavior, which is why heavy clients are so popular, and small shops without frontend engineering talent are making a big push away from heavy clients which raises all the hubbub about HTMX etc

> He means API calls, obviously overloaded the term "function calls" a bit

No they literally meant generating html like h1() rather than in something like jsx templates

(I initially wasn't sure if they were talking about the model of server side rendering with client side events passed back to the server through a websocket either though)

Re: React, but in Python

#29

Post by revskill »

quechimba wrote: post #5

Nice! I believe this is a really good approach for making web apps. Best part is probably that you save time by not having to implement some sort of JSON API for your frontend to communicate with your backend. I've been working on a similar thing in Ruby. https://github.com/mayu-live/framework

Nowdays, with automatic api generation for your API, there's no difference in backend/frontend communication in type-safe way.
Post reply on HN