[HN Gopher] Designing a Pure Python Web Framework
___________________________________________________________________
Designing a Pure Python Web Framework
Author : picklelo
Score : 88 points
Date : 2024-03-22 18:42 UTC (4 hours ago)
(HTM) web link (reflex.dev)
(TXT) w3m dump (reflex.dev)
| etskinner wrote:
| Can you call it pure python if it compiles to React? Seems like
| the abstraction just makes it harder to debug
| picklelo wrote:
| 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 wrote:
| 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 wrote:
| 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.
| jph00 wrote:
| 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.)
| Terretta wrote:
| 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 wrote:
| " ,`Real programmers code it in binary"
|
| Edit: damn. Message received.
| Retr0id wrote:
| machine code is very much still an abstraction
| jph00 wrote:
| I really like this idea of using Python to create both the
| frontend and backend. Another lib doing this is
| 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/ ?
| picklelo wrote:
| 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
| troymc wrote:
| 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
|
| [2] https://anvil.works/blog/page/15.html
| jph00 wrote:
| 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 wrote:
| "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
| spxneo wrote:
| 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
| frodowtf wrote:
| > writing a lot of boilerplate code to connect the frontend and
| backend.
|
| OpenAPI. django-ninja supports it out of the box.
| DandyDev wrote:
| 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 wrote:
| Yeah - I've said this elsewhere, but I slightly prefer Litestar
| over FastAPI for this reason.
| DandyDev wrote:
| I was thinking about Litestar as well. Would be a good fit
| for this project. I hope the maintainers consider it.
| picklelo wrote:
| 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 wrote:
| Stay with FastAPI at least for now. Devs love it.
| devjab wrote:
| 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 wrote:
| 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 wrote:
| 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-magic-link-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 wrote:
| 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
| masenf wrote:
| That's a really good point. Definitely something we need to
| work out before integrating this into the core framework.
| jimmyechan wrote:
| Cofounder @ Dropbase (dropbase.io) here. If you just need to
| build internal tools with Python or want to build internal
| tools on top of your existing Python codebase, give us a try.
| We have granular permission built-in so you can share internal
| tools with others easily, down to who can use or edit each
| internal tool you build.
|
| For context, we're a more niche cousin to Reflex that's
| specifically designed to build internal tools. Reflex seems to
| be a more general framework to build anything you want; quite
| powerful, and possibly an easier to use Django replacement.
|
| It's awesome to see frameworks like Reflex. I think the Python
| ecosystem needs this.
| RobD94 wrote:
| I was wondering if WebAssembly has been considered as a
| compilation target instead of React? Are there major down sides
| to WebAssembly?
| masenf wrote:
| 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 wrote:
| 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 wrote:
| i love dash, but multipage and auth start to feel like a stretch.
| keeping an eye on reflex
| Julesman wrote:
| Fuck it. Let's code the web in binary.
| amai wrote:
| Another one? How many web frameworks does Python need?
| SCUSKU wrote:
| Yes.
| haolez wrote:
| 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 wrote:
| 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
| jph00 wrote:
| 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!
| FranklinMaillot wrote:
| For those who were familiar with pynecone, this is actually the
| same framework, just rebranded.
| picklelo wrote:
| Yes good call out. We started as Pynecone but a company with a
| similar name forced us to change our name.
| spxneo wrote:
| 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 wrote:
| 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?
___________________________________________________________________
(page generated 2024-03-22 23:00 UTC)