9 ms·

Designing a Pure Python Web Framework

117 points by picklelo 2y ago

Julesman 2y ago
Fuck it. Let's code the web in binary.
etskinner 2y ago
Can you call it pure python if it compiles to React? Seems like the abstraction just makes it harder to debug
- picklelo 2y ago
  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.
  - kissgyorgy 2y ago
    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.
    - harkinian 2y ago
      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.
    - pbronez 2y ago
      Would you consider it “pure Python” if it targeted a WASM runtime for the browser side component?
    - eharvey71 2y ago
      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!
- jph00 2y ago
  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.)
  - Retr0id 2y ago
    machine code is very much still an abstraction
  - Terretta 2y ago
    10100010 00000000 10111101 00010011 00001000 10011101 00000000 00000100 11101000 11100000 00101100 11010000 11110101 01100000 01010010 01100101 01100001 01101100 00100000 01110000 01110010 01101111 01100111 01110010 01100001 01101101 01101101 01100101 01110010 01110011 00100000 01100011 01101111 01100100 01100101 00100000 01101001 01110100 00100000 01101001 01101110 00100000 01100010 01101001 01101110 01100001 01110010 01111001 00000000
    - dgfitz 2y ago
      “ ��,��`Real programmers code it in binary”
  - paulddraper 2y ago
    > 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.
jph00 2y ago
I really like this idea of using Python to create both the frontend and backend. Another lib doing this is https://solara.dev/ https://solara.dev/ . Something I particularly like about Solara is that you can interactively build your app in a Jupyter Notebook, since behind the scenes it's using ipywidgets. Has anyone compared Solara and Reflex and can comment on pros/cons? Are there other options in this space? Maybe https://shiny.posit.co/py/ https://shiny.posit.co/py/ ?
- picklelo 2y ago
  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. [1] https://x.com/nikhi1rao/status/1767756284751991035 https://x.com/nikhi1rao/status/1767756284751991035
troymc 2y ago
Anvil [1] is another "pure Python web framework", where you write both the client and the server code using Python. (The client code gets converted to JavaScript so that it can run in the browser.) Anvil has been around since 2016 [2]. [1] https://anvil.works/docs/app-architecture https://anvil.works/docs/app-architecture [2] https://anvil.works/blog/page/15.html https://anvil.works/blog/page/15.html
- jph00 2y ago
  Doesn't Anvil force you to run stuff on their proprietary service however -- which costs money? (I'm not saying that's not a good option for some people, but it's very different to an open source framework you can run anywhere.)
  - troymc 2y ago
    "The runtime engine that powers Anvil’s app hosting is open source. This means you can host your app anywhere..." Source: https://anvil.works/open-source https://anvil.works/open-source
- spxneo 2y ago
  oh wow oh wow! i didnt know about this, this goes even further with a UI editor (that is a killer app) I'm going to have to pause reflex (im still loving it so far) and take a look at anvil here because it seems to be more mature and baked product than reflex as it stands one thing i appreciate about Reflex is it feels programmatic and familiar with background in python backend...so maybe its suitable for more limited scope items? perhaps UI editor like anvil is what reflex needs to implement? Anvil just takes my breath away, i can't believe i never saw this before edit: okay so i got excited and to run one of the boilerplate apps I need to enter my credit card for a 7 day trial for my python environment to make the app work properly ?! this is such a bad experience for new developers. now i understand why nobody around me suggested it. sigh....going back to reflex.dev
  - troymc 2y ago
    As a general rule, an online server should never be left "open" so that anyone can run arbitrary code there. Such servers quickly get turned into bots for botnets (which do things like denial-of-service attacks for their commanders). I suspect Anvil has that credit card requirement to prevent botnet recruiters from abusing Anvil's free trial. (Anvil lets signed-up users run arbitrary Python code on their servers.) By asking for a credit card, Anvil has the information they need to go after anyone who violates their terms of service. Reflex doesn't have to ask for a credit card because you can try it out locally. With Anvil, there is no local dev, you do all the dev in your web browser, in the Anvil Editor app. It's not just a web framework; it's a Rapid Application Development suite.
frodowtf 2y ago
> writing a lot of boilerplate code to connect the frontend and backend. OpenAPI. django-ninja supports it out of the box.
- paulddraper 2y ago
  What do you use for the frontend?
  - frodowtf 2y ago
    Usually, I go with openapi-generator and pick the typescript-fetch template. You can use that with whatever js-based frontend framework you want.
DandyDev 2y ago
This looks like a really neat project! The examples certainly feel less “script-like” than streamlit. One thing I find disappointing though, is that this framework is built on top of FastAPI. I feel it’s a bad idea to build on top of what’s basically a one-man project. No matter how popular that project is.
- robertlagrant 2y ago
  Yeah - I've said this elsewhere, but I slightly prefer Litestar over FastAPI for this reason.
  - DandyDev 2y ago
    I was thinking about Litestar as well. Would be a good fit for this project. I hope the maintainers consider it.
- picklelo 2y ago
  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.
  - slrainka 2y ago
    Stay with FastAPI at least for now. Devs love it.
    - gjiuu 2y ago
      [flagged]
- devjab 2y ago
  I wouldn’t worry about using FastAPI. Not that your point is wrong but the code base isn’t exactly large and it’s entirely open source. If the project goes off road or something you can always continue on your own fork. I’m not sure why you wouldn’t use FastAPI for this. It’s popular because it’s really good.
abdullahkhalids 2y ago
I have used this to build an internal tool, and that was quite a nice experience. My main complaint right now is that it's quite a bit of work to build authentication. I think there are some examples somewhere that show you how to do it. But given, how common it would be for people to use authentication, it should be built in as a first-class object.
- masenf 2y ago
  Thanks for the feedback. I work on Reflex and in a recent release, the team added a template and CLI for creating third-party components and publishing them to PyPI. Since then, I've built a few authentication libraries that might be of interest: https://github.com/masenf/reflex-local-auth https://github.com/masenf/reflex-local-auth https://github.com/masenf/reflex-magic-link-auth https://github.com/masenf/reflex-magic-link-auth https://github.com/martinxu9/reflex-google-auth https://github.com/martinxu9/reflex-google-auth (documentation WiP) The problem with having auth built in is that it's been hard to find a solution that actually works for a majority of use cases. That said, as these auth libraries get more popular and refined, they might be moved into the reflex-dev organization as officially maintained components, or even integrated with the core framework.
  - abdullahkhalids 2y ago
    Thanks. This helps a lot. However, I am concerned that the @reflex_local_auth.require_login decorator [1] merely redirects users to the login page. > Although this seems to protect the content, it is still publicly accessible when viewing the source code for the page! This should be considered a mechanism to redirect users to the login page, NOT a way to protect data. So, I have to put an if-else condition on the State data associated with each protected page, in addition to this decorator. The reasonable way to do it would be for the decorator to actually prevent any data load at all before redirecting. This will prevent a lot of mistakes, besides removing boiler plate. [1] https://github.com/masenf/reflex-local-auth https://github.com/masenf/reflex-local-auth
    - masenf 2y ago
RobD94 2y ago
I was wondering if WebAssembly has been considered as a compilation target instead of React? Are there major down sides to WebAssembly?
- masenf 2y ago
  At least one of the advantages in targeting React is being able to leverage the vast existing library of React components to quickly expose new and advanced functionality to the Reflex app.
devgoldm 2y ago
I gave this a go recently, nice work! In a few hours I was able to get a really nice looking UI starting from an example. I got a bit frustrated when it came to managing state though. I struggled to mutate and view the same state across all web users, instead of creating state per user that connects. However this is still a great framework I’ll definitely revisit in the future!
Kalanos 2y ago
i love dash, but multipage and auth start to feel like a stretch. keeping an eye on reflex
amai 2y ago
Another one? How many web frameworks does Python need?
- SCUSKU 2y ago
  Yes.
haolez 2y ago
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.
- picklelo 2y ago
  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? [1] https://github.com/reflex-dev/reflex/pull/2796 https://github.com/reflex-dev/reflex/pull/2796
  - jph00 2y ago
    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!
- deleted 2y ago
  [deleted]
FranklinMaillot 2y ago
For those who were familiar with pynecone, this is actually the same framework, just rebranded.
- picklelo 2y ago
  Yes good call out. We started as Pynecone but a company with a similar name forced us to change our name.
duckman1 2y ago
[dead]
spxneo 2y ago
im super excited to use this it has a lot potential just needs more tutorials and github projects using it i feel like this scratches a lot of itch and the HN comments here aren't doing it justice. I am not even an investor in reflex and im using it and i love it frontend for backend (python)
Retr0id 2y ago
Having 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?
- paulddraper 2y ago
  It has WebSockets so it at least avoids TCP/TLS connection overhead. But yeah, that's the downside of any thin client.
  - Retr0id 2y ago
    What do you mean? WebSockets require a TCP+TLS connection in most cases, unless you're using HTTP3
ConanRus 2y ago
[dead]
deleted 2y ago
[deleted]
waldrews 2y ago
What would make it easier for me to bet on this is if a few pages made with this could be embedded in an existing Django app, in particular using Django auth. I assume many other people are in that position, with existing Django assets. I get that it's not straightforward because it's based on FastAPI and has its own ORM based on SqlAlchemy, both of which have different async behavior than Django, but is it possible to maybe host a Django app and Reflex app in the same process, routing between the two at the WSGI/ASGI etc. level, and only interact with the Django auth middleware?

117 points by picklelo 2y ago

Julesman 2y ago

Fuck it. Let's code the web in binary.

etskinner 2y ago

Can you call it pure python if it compiles to React? Seems like the abstraction just makes it harder to debug

picklelo 2y ago
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.
- kissgyorgy 2y ago
  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.
  - harkinian 2y ago
    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.
  - pbronez 2y ago
    Would you consider it “pure Python” if it targeted a WASM runtime for the browser side component?
  - eharvey71 2y ago
    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!
jph00 2y ago
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.)
- Retr0id 2y ago
  machine code is very much still an abstraction
- Terretta 2y ago
  10100010 00000000 10111101 00010011 00001000 10011101 00000000 00000100 11101000 11100000 00101100 11010000 11110101 01100000 01010010 01100101 01100001 01101100 00100000 01110000 01110010 01101111 01100111 01110010 01100001 01101101 01101101 01100101 01110010 01110011 00100000 01100011 01101111 01100100 01100101 00100000 01101001 01110100 00100000 01101001 01101110 00100000 01100010 01101001 01101110 01100001 01110010 01111001 00000000
  - dgfitz 2y ago
    “ ��,��`Real programmers code it in binary”
- paulddraper 2y ago
  > 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.

jph00 2y ago

I really like this idea of using Python to create both the frontend and backend. Another lib doing this is https://solara.dev/ https://solara.dev/ . Something I particularly like about Solara is that you can interactively build your app in a Jupyter Notebook, since behind the scenes it's using ipywidgets. Has anyone compared Solara and Reflex and can comment on pros/cons? Are there other options in this space? Maybe https://shiny.posit.co/py/ https://shiny.posit.co/py/ ?

picklelo 2y ago
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. [1] https://x.com/nikhi1rao/status/1767756284751991035 https://x.com/nikhi1rao/status/1767756284751991035

troymc 2y ago

Anvil [1] is another "pure Python web framework", where you write both the client and the server code using Python. (The client code gets converted to JavaScript so that it can run in the browser.) Anvil has been around since 2016 [2]. [1] https://anvil.works/docs/app-architecture https://anvil.works/docs/app-architecture [2] https://anvil.works/blog/page/15.html https://anvil.works/blog/page/15.html

jph00 2y ago
Doesn't Anvil force you to run stuff on their proprietary service however -- which costs money? (I'm not saying that's not a good option for some people, but it's very different to an open source framework you can run anywhere.)
- troymc 2y ago
  "The runtime engine that powers Anvil’s app hosting is open source. This means you can host your app anywhere..." Source: https://anvil.works/open-source https://anvil.works/open-source
spxneo 2y ago
oh wow oh wow! i didnt know about this, this goes even further with a UI editor (that is a killer app) I'm going to have to pause reflex (im still loving it so far) and take a look at anvil here because it seems to be more mature and baked product than reflex as it stands one thing i appreciate about Reflex is it feels programmatic and familiar with background in python backend...so maybe its suitable for more limited scope items? perhaps UI editor like anvil is what reflex needs to implement? Anvil just takes my breath away, i can't believe i never saw this before edit: okay so i got excited and to run one of the boilerplate apps I need to enter my credit card for a 7 day trial for my python environment to make the app work properly ?! this is such a bad experience for new developers. now i understand why nobody around me suggested it. sigh....going back to reflex.dev
- troymc 2y ago
  As a general rule, an online server should never be left "open" so that anyone can run arbitrary code there. Such servers quickly get turned into bots for botnets (which do things like denial-of-service attacks for their commanders). I suspect Anvil has that credit card requirement to prevent botnet recruiters from abusing Anvil's free trial. (Anvil lets signed-up users run arbitrary Python code on their servers.) By asking for a credit card, Anvil has the information they need to go after anyone who violates their terms of service. Reflex doesn't have to ask for a credit card because you can try it out locally. With Anvil, there is no local dev, you do all the dev in your web browser, in the Anvil Editor app. It's not just a web framework; it's a Rapid Application Development suite.

frodowtf 2y ago

> writing a lot of boilerplate code to connect the frontend and backend. OpenAPI. django-ninja supports it out of the box.

paulddraper 2y ago
What do you use for the frontend?
- frodowtf 2y ago
  Usually, I go with openapi-generator and pick the typescript-fetch template. You can use that with whatever js-based frontend framework you want.

DandyDev 2y ago

This looks like a really neat project! The examples certainly feel less “script-like” than streamlit. One thing I find disappointing though, is that this framework is built on top of FastAPI. I feel it’s a bad idea to build on top of what’s basically a one-man project. No matter how popular that project is.

robertlagrant 2y ago
Yeah - I've said this elsewhere, but I slightly prefer Litestar over FastAPI for this reason.
- DandyDev 2y ago
  I was thinking about Litestar as well. Would be a good fit for this project. I hope the maintainers consider it.
picklelo 2y ago
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.
- slrainka 2y ago
  Stay with FastAPI at least for now. Devs love it.
  - gjiuu 2y ago
    [flagged]
devjab 2y ago
I wouldn’t worry about using FastAPI. Not that your point is wrong but the code base isn’t exactly large and it’s entirely open source. If the project goes off road or something you can always continue on your own fork. I’m not sure why you wouldn’t use FastAPI for this. It’s popular because it’s really good.

abdullahkhalids 2y ago

I have used this to build an internal tool, and that was quite a nice experience. My main complaint right now is that it's quite a bit of work to build authentication. I think there are some examples somewhere that show you how to do it. But given, how common it would be for people to use authentication, it should be built in as a first-class object.

masenf 2y ago
Thanks for the feedback. I work on Reflex and in a recent release, the team added a template and CLI for creating third-party components and publishing them to PyPI. Since then, I've built a few authentication libraries that might be of interest: https://github.com/masenf/reflex-local-auth https://github.com/masenf/reflex-local-auth https://github.com/masenf/reflex-magic-link-auth https://github.com/masenf/reflex-magic-link-auth https://github.com/martinxu9/reflex-google-auth https://github.com/martinxu9/reflex-google-auth (documentation WiP) The problem with having auth built in is that it's been hard to find a solution that actually works for a majority of use cases. That said, as these auth libraries get more popular and refined, they might be moved into the reflex-dev organization as officially maintained components, or even integrated with the core framework.
- abdullahkhalids 2y ago
  Thanks. This helps a lot. However, I am concerned that the @reflex_local_auth.require_login decorator [1] merely redirects users to the login page. > Although this seems to protect the content, it is still publicly accessible when viewing the source code for the page! This should be considered a mechanism to redirect users to the login page, NOT a way to protect data. So, I have to put an if-else condition on the State data associated with each protected page, in addition to this decorator. The reasonable way to do it would be for the decorator to actually prevent any data load at all before redirecting. This will prevent a lot of mistakes, besides removing boiler plate. [1] https://github.com/masenf/reflex-local-auth https://github.com/masenf/reflex-local-auth
  - masenf 2y ago

RobD94 2y ago

I was wondering if WebAssembly has been considered as a compilation target instead of React? Are there major down sides to WebAssembly?

masenf 2y ago
At least one of the advantages in targeting React is being able to leverage the vast existing library of React components to quickly expose new and advanced functionality to the Reflex app.

devgoldm 2y ago

I gave this a go recently, nice work! In a few hours I was able to get a really nice looking UI starting from an example. I got a bit frustrated when it came to managing state though. I struggled to mutate and view the same state across all web users, instead of creating state per user that connects. However this is still a great framework I’ll definitely revisit in the future!

Kalanos 2y ago

i love dash, but multipage and auth start to feel like a stretch. keeping an eye on reflex

amai 2y ago

Another one? How many web frameworks does Python need?

SCUSKU 2y ago
Yes.

haolez 2y ago

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.

picklelo 2y ago
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? [1] https://github.com/reflex-dev/reflex/pull/2796 https://github.com/reflex-dev/reflex/pull/2796
- jph00 2y ago
  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!
deleted 2y ago
[deleted]

FranklinMaillot 2y ago

For those who were familiar with pynecone, this is actually the same framework, just rebranded.

picklelo 2y ago
Yes good call out. We started as Pynecone but a company with a similar name forced us to change our name.

duckman1 2y ago

[dead]

spxneo 2y ago

im super excited to use this it has a lot potential just needs more tutorials and github projects using it i feel like this scratches a lot of itch and the HN comments here aren't doing it justice. I am not even an investor in reflex and im using it and i love it frontend for backend (python)

Retr0id 2y ago

Having 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?

paulddraper 2y ago
It has WebSockets so it at least avoids TCP/TLS connection overhead. But yeah, that's the downside of any thin client.
- Retr0id 2y ago
  What do you mean? WebSockets require a TCP+TLS connection in most cases, unless you're using HTTP3

ConanRus 2y ago

[dead]

deleted 2y ago

[deleted]

waldrews 2y ago

What would make it easier for me to bet on this is if a few pages made with this could be embedded in an existing Django app, in particular using Django auth. I assume many other people are in that position, with existing Django assets. I get that it's not straightforward because it's based on FastAPI and has its own ORM based on SqlAlchemy, both of which have different async behavior than Django, but is it possible to maybe host a Django app and Reflex app in the same process, routing between the two at the WSGI/ASGI etc. level, and only interact with the Django auth middleware?