[HN Gopher] React, but in Python
___________________________________________________________________
React, but in Python
Author : filippofinke
Score : 165 points
Date : 2023-06-05 07:02 UTC (1 days ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| jcadam wrote:
| Perhaps a Tkinter replacement, eh?
| jake_overflow wrote:
| But... why?
| quechimba wrote:
| 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
| revskill wrote:
| Nowdays, with automatic api generation for your API, there's no
| difference in backend/frontend communication in type-safe way.
| taeric wrote:
| Curious what automatic generation you have in mind?
| revskill wrote:
| Say you have a function in the backend, for example in
| typescript:
|
| function handler(a: A, b: B) {}
|
| With a suitable tooling, you can generate the type for
| frontend to call handler(a, b) in a type-safe way, which
| could be validated on the backend and frontend.
|
| So you're just a "generation" step away from bluring BE/FE
| communication.
| taeric wrote:
| Apologies, I know what generation is. But the ABI that is
| the wire between the front and the back is notorious for
| not being stable. Such that I was asking if you have
| experience with a generation stack that is favorable.
| Most folks I know do not have favorable experience in
| this realm. Best I know of, are those that drop down to
| something like protobuff to describe the messages.
| [deleted]
| jerpint wrote:
| 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
| ksherlock wrote:
| Long 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.
|
| https://en.wikipedia.org/wiki/XHP
| 4ndrewl wrote:
| And long before transpiling became cool, FB had
| https://en.m.wikipedia.org/wiki/HipHop_for_PHP
| tedkalaw wrote:
| xhp was honestly pretty nice - it was something watching the
| rapid codemods transform the language.
|
| There was also ComponentKit, which was used heavily in fbobjc:
| https://github.com/facebook/componentkit
| TeaVMFan wrote:
| If you're interested in this sort of thing, but want to code in
| Java, try Flavour: https://flavour.sourceforge.io/
|
| Flavour is a fast, batteries-included, type-safe framework for
| making modern SPA web apps in Java (and other JVM languages).
|
| * Great Lighthouse scores? Check!
|
| * Real SPAs without sluggish network round trips? Check!
|
| * Modern path-based routing? Check!
|
| * Components (built-in and user-defined)? Check!
|
| * Effortless service calls? Check!
|
| * Refactor frontend and backend simultaneously using your current
| IDE? Check!
|
| If this sounds interesting, check out these other resources:
|
| * Article in Java Magazine:
| https://blogs.oracle.com/javamagazine/post/java-in-the-brows...
|
| * 100% Flavour 5-letter word game: https://frequal.com/wordii
|
| * Flavour podcast (created with Castini, a Flavour app):
| https://castini.frequal.com/cast/show/Flavourcast/f7e171e8-2...
| nightpool wrote:
| None of these links seem to work?
|
| This site can't be reachedCheck if there is a typo in
| frequal.com. DNS_PROBE_FINISHED_NXDOMAIN
| hu3 wrote:
| Not sure if your parent commenter fixed, but FYI all links
| worked for me.
| TeaVMFan wrote:
| Thanks hu3! No changes since posting, all links tested then
| and now, 100% working from here.
| narush wrote:
| 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
| results in a bit less magic (and so easier debugging) than just
| using raw variables. 2. Works with ipywidgets, so many existing
| data apps can be ported over very easily -- Jupyter users
| celebrate.
|
| I'm not associated with the project, but I know the maintainers
| (creators of Volia [2]) and they are honestly excellent. I
| haven't use the project in production, but the getting starting
| guide is pretty compelling.
|
| [1] https://github.com/widgetti/reacton [2]
| https://github.com/voila-dashboards/voila
| maartenbreddels wrote:
| Thanks for the shout out.
|
| The follow up of that is Solara: "NextJS, but in Python" :)
|
| https://github.com/widgetti/solara/
| bsimpson wrote:
| 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.
| jokoon wrote:
| 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.
| ariym wrote:
| Don't let Dan Abramov see this
| say_it_as_it_is wrote:
| Hello world examples don't inspire confidence that this is
| anything more than a toy
| mixeden wrote:
| No one knows what it means, but it's provocative
| paulddraper wrote:
| 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..... :)
| ledauphin wrote:
| 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.
| roqi wrote:
| > Making a 'server call' on each interaction is also what web
| apps used to do before SPAs were a thing.
|
| One of the reasons behind the popularity around webapps was
| that they would no longer need to make 'a server call' on
| each interaction.
|
| > And in many cases it's what SPAs do as well.
|
| I feel you're grossly misrepresenting what SPAs do. SPAs do
| calls to send and receive data, not to fetch server-side
| rendered content.
| motogpjimbo wrote:
| > 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.
| heavyset_go wrote:
| Hell, try using the Twitter web app on something with 8GB
| of memory or that's older than 5 years old.
| kokanee wrote:
| 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.
| quechimba wrote:
| 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.
| Solvency wrote:
| 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 entrench the modern state of meh-
| ness in performant UI?
| paulddraper wrote:
| > A far cry from the snappiness of desktop apps from 25+
| years ago
|
| So apps without network latency are faster? Huh.
| moritzwarhier wrote:
| 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?
| zdragnar wrote:
| As someone who has had the misfortune of working on
| poorly tuned WordPress and Drupal websites in a former
| life I can confirm this is an issue of culture, not and
| axiom of whether SPAs are intrinsically faster or slower.
| dustingetz wrote:
| manual network state sync between frontend and backend is
| the root cause of that
| onion2k wrote:
| 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.
| roqi wrote:
| > And nowadays you can deploy apps really close to users so
| latency is really low.
|
| That sounds like blindly throwing money at the software
| architecture problem you created for yourself. Supposedly
| SPAs became popular because your line of reasoning was
| embarrassingly absurd, in the sense that you do not
| mitigate the penalty of a network call by microoptimizing
| the cost of a network call.
| zelphirkalt wrote:
| People notice the difference of < 10ms in input delay on a
| command line. I am pretty sure humans notice stuff >= 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.
| tomas789 wrote:
| A no-op API call to FastAPI takes more than that. Even when
| running on localhost. And FastAPI is one of the better
| contestants.
| LtWorf wrote:
| If fast api didn't use pydantic (the slowest library in
| that space), I'm sure it might be more deserving of the
| name :D
|
| Microbenchmark to compare with typedload (which I wrote)
| and apischema
| https://ltworf.github.io/typedload/performance.html
|
| Note that pydantic and apischema use .so files, while
| typedload is just pure python code.
| paulddraper wrote:
| A no-op localhost call takes more than 100ms??
| rch wrote:
| Sounds like Elixir LiveView.
| shrimpx wrote:
| 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.
| paulddraper wrote:
| For a certain class of things, this could work.
|
| You'd have to conscious of this.
|
| It's defiantly not a "write a usual React app, but in
| Python"...every dropdown, menu, modal, etc interaction
| interaction is a backend call.
| thih9 wrote:
| What about conditional form elements, modal dialogs with
| static text, or collapsible menus?
|
| I understand the benefits, then again if interacting with
| these elements requires calling the backend then the cost is
| quite high.
| quickthrower2 wrote:
| 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.
| uhtred wrote:
| I thought generating html from function calls went out with the
| dinosaurs. We back doing it again?
| recursive wrote:
| I mean, react does it. It never left. JSX compiles to function
| calls.
| uhtred wrote:
| 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.
| neurostimulant wrote:
| 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...
| acemarke wrote:
| 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...
| )
| cantSpellSober wrote:
| Why?
| uhtred wrote:
| because ASP .NET webforms suck to work with
| nawgz wrote:
| 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
| Izkata wrote:
| No, he meant function calls as opposed to JSX, clarified in
| another comment.
| resoluteteeth wrote:
| > He means API calls, obviously overloaded the term
| "function calls" a bit
|
| No they literally meant generating html like h1() rather
| than <h1></h1> 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)
| shrimpx wrote:
| To be clear, what this comment is talking about is using `p()`
| and `div()` calls instead of `<p>` and `<div>` 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.
| loloquwowndueo wrote:
| https://htmx.org/ Says otherwise, so does
| https://blog.appsignal.com/2022/07/06/get-started-with-hotwi...
| uhtred wrote:
| 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.
| loloquwowndueo wrote:
| Htmx is not only about adding attributes to HTML :) check
| how responses to requests are expected to contain full or
| partial HTML instead of, say, json.
| uhtred wrote:
| yeah I get that, but the html that is returned from the
| server doesn't have to be generated with things like
| html.div(html.p('hello this is a p tag inside a div'))
|
| you could still have your html in a template file and
| parse and return the contents of that.
| agumonkey wrote:
| Could be fun to see this replacing jinja in old frameworks like
| django. Although inheritance had a better feel with templates..
| robertlagrant wrote:
| Django doesn't use Jinja, does it? I thought it did its own
| thing.
| gkhartman wrote:
| They have their own template engine, but it can be swapped
| for Jinja2 optionally.
| rmorshea wrote:
| ReactPy dev here. We're actually contributing to a WIP PEP that
| would add JS-like tagged template literals to Python. We think
| this will open up a whole new world of templating and DSL
| possibilities: https://github.com/jimbaker/tagstr
| crubier wrote:
| 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.
|
| <The world if data scientists/ML/CV people used Typescript.JPEG>
| miketery wrote:
| Isn't mojo the future on that front?
| garymiklos wrote:
| Does 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.
| b33j0r wrote:
| I love OP's project. I probably won't use it, and I say that
| sadly. I chased that dragon for years, but ECMA was a sleeping
| giant.
|
| I do not have the answer to your question, parent, but I feel
| the need to evangelize vanilla JS/ECMA.
|
| You can do everything you could do with jquery and react with
| very simple constructs now. Web components are slightly
| awkward, but damn! Possible, and easier than it ever was before
| js components.
|
| Introducing any additional technologies or node is no longer
| necessary. The frontend has evolved.
|
| Now. You still have to learn ECMA, but that's what browsers
| definitively run as of my writing.
|
| I can pray to mdn for wasm to be a go-to every day tech, but
| that day is not today.
| nosnah wrote:
| Not a list, but I've been trying out django-unicorn, which lets
| you build components in python and use things like
| unicorn:model and unicorn:click in your templates.
| fermigier wrote:
| https://github.com/sfermigier/awesome-python-web-frameworks#...
|
| (Not complete. Pull requests welcome.)
| shrimpx wrote:
| There are many, but here's a start:
|
| pyjs, streamlit, brython, pyodide, pywebio, gleam, dash, bokeh,
| gradio, pglet, idom, anvil, pynecone, onu
|
| The last two are YC-funded.
|
| Edit: add https://flet.dev which has superseded pglet
| funkaster wrote:
| from all the react clones I've seen there, this is the one that
| I'm mostly impressed by: https://yew.rs/ (React clone written in
| Rust, targeting webasm)
| ivoflipse wrote:
| Shameless plug for a similar project called Collagraph
| (https://github.com/fork-tongue/collagraph).
|
| From the README: Write your Python interfaces in a declarative
| manner with plain render functions, component classes or even
| single-file components using Vue-like syntax, but with Python!
| - Reactivity (made possible by leveraging observ) -
| Function components - Class components with local state and
| life-cycle methods/hooks - Single-file components with Vue-
| like syntax (.cgx files) - Custom renderers
|
| Currently there are two renderers:
|
| PysideRenderer: for rendering PySide6 applications PygfxRenderer:
| for rendering 3D graphic scenes with Pygfx
|
| It is possible to create a custom Renderer using the Renderer
| interface, to render to other UI frameworks, for instance
| wxPython, or even the browser DOM.
| jraph wrote:
| 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)
___________________________________________________________________
(page generated 2023-06-06 23:00 UTC)