Does this offer any advantage over gradio? One big issue I have with gradio is that « simple » computations happen in the backend and make the UX very slow on deployment
React, but in Python
31–40 of 179 posts
Re: React, but in Python
#32Earlier quoted context omitted.
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.
Firefox's Devtools uses React and it doesn't use JSX. Example: https://github.com/mozilla/gecko-dev/blob/aec3a901e6f6b3041b...
Their reasoning: https://firefox-source-docs.mozilla.org/devtools/frontend/re...
Re: React, but in Python
#33Long ago, before jsx and react, before hack, Facebook had a fork of php called xhp, which allowed xml data within php. I'm not suggesting anybody should maintain a fork of python with xml support but a pre-processor could parse xython and generate standard python with trees of html.xx() calls.
Re: React, but in Python
#34Nice! 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.
Curious what automatic generation you have in mind?
Re: React, but in Python
#35Does anyone have a list of full-stack Python frameworks for building interactive web apps? I feel like a new one comes out each week, and it would be nice to see them together to compare.
Re: React, but in Python
#36Re: React, but in Python
#37I thought generating html from function calls went out with the dinosaurs. We back doing it again?
To be clear, what this comment is talking about is using `p()` and `div()` calls instead of `
` and `` tags like in JSX.
On first read, I thought by "generating html from function calls" the author was referring the react-style way of building a UI by writing a reactive function that returns HTML.
Re: React, but in Python
#38Earlier quoted context omitted.
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.
Firefox's Devtools uses React and it doesn't use JSX. Example: https://github.com/mozilla/gecko-dev/blob/aec3a901e6f6b3041b... Their reasoning: https://firefox-source-docs.mozilla.org/devtools/frontend/re...
That page is very out of date. They did later adopt a build step and switch to using JSX in much of the FF DevTools codebase.
As an example, here's the Editor main component (same "latest" commit you pointed to):
https://github.com/mozilla/gecko-dev/blob/aec3a901e6f6b3041b...
The codebase is a mish-mash of very old-style React+Redux code, with newer files and usages.
(I know this because I work at Replay.io, which started as a fork of the FF DevTools source, and we spent all of last year modernizing our fork :) Migrated the entire codebase to TS, ripped out all remaining uses of the ancient `React.DOM` helper functions and converted those to JSX, modernized the 2015-era Redux logic, etc: https://github.com/replayio/devtools/pulls?q=is%3Apr+sort%3A... )
Re: React, but in Python
#39I'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..... :)
In reality, an important and large class of apps will hit the backend on roughly every click anyway, and having full control over in-browser interactivity is kind of overkill for those apps. Business apps with tables, charts, and forms, for example. You click the nav to load a new page, you scroll down or click a button to load more data, you fill a form and click submit, all those things hit the server.
For those types of apps, this 'backend-driven reactive apps' paradigm could be more efficient, because programmers don't have the option to build stuff like an inefficient network protocol or bloated frontend stack.
Re: React, but in Python
#40Earlier 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.
People notice the difference of = 10ms, <= 100ms. It is perhaps the expectation, that is different. People do not expect websites to react immediately, like when they are typing a command in a terminal emulator.