I've tried it in my company. It's great, but the builds were annoying because of pip failing to solve the dependencies when using Reflex together with other big libraries. I'll give it another try in the future.
[deleted]
Designing a Pure Python Web Framework
41–50 of 59 posts
Re: Designing a Pure Python Web Framework
#42Earlier quoted context omitted.
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 wit…
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.
Re: Designing a Pure Python Web Framework
#43Having no logic in the front-end sounds nice, but how well does it deal with an imperfect network connection? If I have 500ms ping, does that mean I have to wait 500ms for each UI interaction?
Re: Designing a Pure Python Web Framework
#44Can you call it pure python if it compiles to React? Seems like the abstraction just makes it harder to debug
All programming is abstractions, unless you're using machine code. Abstractions don't necessarily make debugging harder -- done the right way, they can make it easier. (Yes, you can call it "pure python" if it compiles to something else, because every programming language compiles to something else.)
machine code is very much still an abstraction
Re: Designing a Pure Python Web Framework
#45Having no logic in the front-end sounds nice, but how well does it deal with an imperfect network connection? If I have 500ms ping, does that mean I have to wait 500ms for each UI interaction?
It has WebSockets so it at least avoids TCP/TLS connection overhead.
But yeah, that's the downside of any thin client.
Re: Designing a Pure Python Web Framework
#46> writing a lot of boilerplate code to connect the frontend and backend. OpenAPI. django-ninja supports it out of the box.
What do you use for the frontend?
Re: Designing a Pure Python Web Framework
#47Can you call it pure python if it compiles to React? Seems like the abstraction just makes it harder to debug
All programming is abstractions, unless you're using machine code. Abstractions don't necessarily make debugging harder -- done the right way, they can make it easier. (Yes, you can call it "pure python" if it compiles to something else, because every programming language compiles to something else.)
> Yes, you can call it "pure python" if it compiles to something else
There is an idea that "pure python" means python + python runtime.
For example, pg8000 is a "pure python PostgreSQL driver", but psycopg is not.
Even though both of them only require Python code from their users.
Re: Designing a Pure Python Web Framework
#48[dead]
Re: Designing a Pure Python Web Framework
#49[deleted]
Re: Designing a Pure Python Web Framework
#50Having no logic in the front-end sounds nice, but how well does it deal with an imperfect network connection? If I have 500ms ping, does that mean I have to wait 500ms for each UI interaction?
It has WebSockets so it at least avoids TCP/TLS connection overhead. But yeah, that's the downside of any thin client.
What do you mean? WebSockets require a TCP+TLS connection in most cases, unless you're using HTTP3