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

71–80 of 179 posts

Re: React, but in Python

#71

Post by crubier »

Controversial, but I think that rather than trying to make Web stuff (e.g. React) work in Python, a more fruitful direction would be to make ML stuff (e.g. PyTorch, OpenCV) work in Typescript.

Javascript/Typescript is way faster than Python, is ubiquitous and can run pretty much everywhere, has many engine implementations, has an incredibly wide ecosystem, has a type system (Typescript) that blows any Python type system out of the water, runs in browsers, has non-stupid package management systems (PIP is a joke), is easy to get started, etc.

Re: React, but in Python

#72

Post by jraph »

The slowest framework now available for the slowest language.

(this is a joke, it was my immediate thought when seeing this. More seriously, probably not for me but looks interesting technically, I'll need to check out how it works)

Re: React, but in Python

#73

Post by quickthrower2 »

paulddraper wrote: post #10

I'm lost. React builds interactive UIs (web, mobile). After each interaction, the virtual DOM is programmatically recreated and reconciled to the actual DOM. But reactpy is running on a backend sever??? Is each interaction resulting in a server call? Can someone explain what is going on? EDIT: Ah, okay, thanks. Every re-render is a network call. If people complained about web UI performance before..... :)

Yeah this seems to combine the worst of both worlds: react headscratching (e.g. why useEffect do this weird shit) and slowness of the phoenix style send it all back to the server. The solution? For python people: learn some JS and use django.

Re: React, but in Python

#74

Post by miketery »

crubier wrote: post #71

Controversial, but I think that rather than trying to make Web stuff (e.g. React) work in Python, a more fruitful direction would be to make ML stuff (e.g. PyTorch, OpenCV) work in Typescript. Javascript/Typescript is way faster than Python, is ubiquitous and can run pretty much everywhere, has many engine implementations, has an incredibly wide ecosystem, has a type system (Typescript) that blows any Python type sys…

Isn’t mojo the future on that front?

Re: React, but in Python

#75

Post by bsimpson »

narush wrote: post #50

If you're interested in using React-style frontend programming in Python but want an experience / API closer to that of React, I recommend checkout out Reacton [1]. Similarly to this library, it gives you a `@component` decorator that allows you to create components out of functions. But it also: 1. Includes all existing React hooks (use_state, use_memo, etc) -- so you don't have to learn new patterns. I believe this…

I never expected to care about a UI library in Python, but my user research collaborators prefer Colab notebooks (as opposed to Observable, where my JS expertise would be relevant).

Now you (and the OP) have me pondering about building UIs in notebooks…

Not sure doing something in React is better than just learning the standard tools, but it's a good option to know exists.

Re: React, but in Python

#76

Post by jokoon »

Please try brython, it runs in the browser.

I find it so ironic that js, a language that runs in the browser, is now used on a server, to rebuild code that is sent back to browser.

Re: React, but in Python

#77

Post by jraph »

kokanee wrote: post #67
motogpjimbo wrote: post #58

Earlier quoted context omitted.

> One of the reasons behind the popularity around webapps was that they would no longer need to make 'a server call' on each interaction. Ironically, many modern SPAs are significantly slower than the traditional apps they replaced. Try using Twitter's webapp on a non-premium phone, for example. Sometimes it's regrettable that the webdev truck has no rear-view mirror.

The entire internet is slower because it's being squeezed to oblivion for monetization and tracking purposes. No matter what technology you choose to render HTML with, your company is going to have a slew of systems for injecting 3rd party scripts, running A/B tests, collecting analytics that include recording user sessions, etc etc. Back "before SPAs" we just weren't doing as much crap in the browser.

Tracking doesn't help but modern frontend development practices lead to slowness.

Rerendering and recomputing too much (ever encountered these chains of map() and filter() in render()?), many API calls, huge icon sets, huge custom fonts, CSS frameworks and JS frameworks, huge dependency trees with many instance of the same lib running sometime in several versions, big bundles... This heaviness in the name of convenience and branding is not free, it forces people to ditch perfectly fine hardware, which has a high environmental cost... not directly paid by people funding the code).

One of my pet peeves is managed text inputs, where render() is called each time you type a character, for a whole component tree if you are not careful and you happen to pass the content to some parent for some reason. Typing a message in Mattermost on the PinePhone is painful for this reason, there's just no reason typing should be slow even on slow hardware but managed component is considered good practice.

Making people buy newer / powerful and making people wait and using too much energy should be considered bad practice.

Re: React, but in Python

#78

Post by skratlo »

crubier wrote: post #71

Controversial, but I think that rather than trying to make Web stuff (e.g. React) work in Python, a more fruitful direction would be to make ML stuff (e.g. PyTorch, OpenCV) work in Typescript. Javascript/Typescript is way faster than Python, is ubiquitous and can run pretty much everywhere, has many engine implementations, has an incredibly wide ecosystem, has a type system (Typescript) that blows any Python type sys…

[flagged]

Re: React, but in Python

#80

Post by crubier »

miketery wrote: post #74
crubier wrote: post #71

Controversial, but I think that rather than trying to make Web stuff (e.g. React) work in Python, a more fruitful direction would be to make ML stuff (e.g. PyTorch, OpenCV) work in Typescript. Javascript/Typescript is way faster than Python, is ubiquitous and can run pretty much everywhere, has many engine implementations, has an incredibly wide ecosystem, has a type system (Typescript) that blows any Python type sys…

Isn’t mojo the future on that front?

Mojo looks cool. But I'll wait for it to be open sourced AND as easy to use as Typescript + React for real complex web apps before considering it. I expect this to take 2-5 years if it ever happens. It's a possible future, not the present.
Post reply on HN