Hey thanks for the feedback. We're working on relaxing our dependencies [1] to make reflex more compatible. Do you remember what libraries you had the conflict with?
This PR is super-helpful -- it's nearly impossible for me to work with projects that pin to specific versions, since it leads to so many conflicts. Having minimum versions like in this PR makes life much easier!
Thanks! we found script-like frameworks like Streamlit are nice for small apps, but hard to reason about for larger apps. We went with a declarative approach more similar to React.
FastAPI has been working well for us, but we're not strongly coupled to it - in the future it would be easy to swap it out if needed.
Right now Reflex is meant for full-stack apps, but portability is something people have asked us for.
We're working on making Reflex work in different environments like Jupyter notebooks, and we're also exploring using Reflex for widgets [1] that can be embedded in pre-existing apps, so you can add interactive Python elements easily without rewriting your whole app.
We need to compile down to React/HTML in the end as it's the only way to render a webpage. By "pure Python" we meant from the developer's perspective they won't have to touch React or Javascript.
We only use React for the UI layer and to send events. Since all the state/logic is kept in Python you won't see Javascript errors during runtime, and debugging can mostly be done in Python land.
Wow, you literally got everything wrong in this comment.
- There are a thousand ways to render HTML, you don't need React at all. Even for interactive pages (see recent alternatives like HTMX, or decade old solutions...)
- If it is converted to JS/React it's obviously not "pure" Python. Sorry, but that's just silly to say that.
- You will definitely see JavaScript errors during runtime, it's inevitable. Maybe not with simple toy projects, but with serious projects, it will happen and will make life miserable.
Sounds RIGHT to me. You need a modern front-end framework like React.js if you want to avoid state / component hierarchy nightmares that you find by doing the same with vanilla JS. Also, the statement of working with pure Python resonates well from the dev perspective. Makes sense to me!
I think they meant that rendering can only be done with JS/HTML, and if you want to use React stuff, React also has to be involved. No need to be rude and assume the worst.
Third point seems true though, I would definitely expect to see JS errors should any React libs have issues on their own.
Yeah we’re only hosting on a single region at the moment so there can be latency depending on your location. We’re working on using edge computing to speed this up.
Keeping the state on the server allows us to run arbitrary Python code and libraries in our event handlers that update the state. Currently only the ui is compiled to React but the logic stays in Python.
We’re working to offload more logic to the client in the for purely UI operations like you mention, and in the future want to leverage wasm once it’s more mature.
Cofounder of Pynecone here - thanks for the feedback. We’re prioritizing improving our docs and example apps in the upcoming weeks and will have a ChatGPT clone example. Definitely want to improve the onboarding experience and showcase these more complex use cases.
That’s awesome - it looks like a really interesting project. Would you be able to address the specific criticism raised by parent, on rich text boxes? Is this a case of a documentation shortfall, or something more fundamental?
We want to support any UI feature that you can build with React/NextJS. We will expand our core to include components like rich text inputs but we also have a way to wrap any React library so you're not locked into the components we provide: https://pynecone.io/docs/advanced-guide/wrapping-react
Hey! Don't take my comment as too negative, I do like the idea & enjoyed using Pynecone right to the point I got stuck. Best of luck improving it, I'll definitely circle back in the future
We use Websockets for state interactions, so the latency may depend on your internet connection + distance to server. We will improve this in the future by leveraging more edge computing and WebAssembly to execute closer to / on the client.
Why don't you just transpile the frontend Python code to JS at build time and just have normal HMTL/JS/CSS in the final deployed web app with a Python backend?
You've mentioned no-code tools. For a client, I had to work with the no-code tool Bubble a lot. They do something similar, where the front-end is not built statically but dynamically and uses WebSockets to communicate with the back-end. I don't think this is a good idea (and that's why Bubble is also trying to switch to static pages now, but you can imagine what it takes to do that once you reach a certain size).
In fact the Pynecone frontend is built statically. But UI event handlers are run on the backend. The latency scenario is identical to if you used HTMX or Hotwire or a traditional web server. You click, it gets posted to the backend, an output comes back and is rendered.
The click counter thing is contrived and maybe Pynecone should have avoided centering on that, since the users they're targeting for sure don't care about frontend-only click counters.
Is it possible to take the optimistic approach and update the UI before getting response from the back end? Obviously for simple things, like counters, that need an immediate update to the UI.
You could designate some handlers to be “frontend-only” and then compile them to wasm or js and run them in the browser. There might be usability/ergonomics issues with having “special” functions that don’t really work like normal ones.
Edge computing isn't a universal fix. At the moment I'm on a corp network that routes traffic through a proxy a couple states away (security reasons), I rarely see <200ms latency and occasionally see >500ms latency. The counter and slider example don't feel right at that latency.
Also, I turned off WiFi and then clicked the counter a couple times. Obviously the clicks didn't render. When I turned it on, then the counter updated one at a time at what felt like 300ms intervals. I often use the web from the train as I commute and data service can be spotty. I expect I'd see input latency in the minutes if I tried.
I think this is only viable if you're certain all your users have ping <100ms, and are on stable connections.
If you have to use this model, try batching user events (10 clicks => increment by 10) and cancelling old events (slider events at 5, 10, 20; only send slider=20 event).
Source code here: https://github.com/picklelo/webcritic