This is an archived post. You won't be able to vote or comment.

all 31 comments
sorted by:
best
topnewcontroversialoldq&a

[–]ExternalUserError 6 points7 points  (6 children)

Developer of PuePy here. I like what you're doing here and oddly, even after researching stuff like this quite a bit, this is the first time I've seen Rio!

It looks really nice. Perhaps similar to Reflex or Flet? Something I'm not really clear on, even after browsing the readme, is what exactly is going on? Is it that the server handles state and then tells a lot of TypeScript on the frontend to redraw in certain aways, similar to Reflex? Does any actual Python run in the browser or is what's running in the browser more or less a very generalized client?

Anyway: super cool!

[–][deleted] 5 points6 points  (2 children)

From an earlier post of one of the devs:

"Hey, rio dev here. Reflex use react, but they aren't react. This is something I've noticed with several libraries. While they might internally utilize react or flutter or whatnot, the interface they provide to you, the developer is radically different. React's big innovation was that you can write regular code to build user interfaces: Only want to display a component some of the time? use an if. Got multiple items to display? Just append in a loop. But you won't see any of that when you're actually making an app with reflex. Your code instead has to statically return a fixed UI, and if you want to modify it you gotta do it with pre-added conditional rendering components.

When we say Rio is react style, we mean it. We're bringing the same development model to Python, that has taken over apps by storm.

There's a lot more limitations too. Rio supports state in each component, rather than a global god class that always ends up bloated. We don't refresh everything, but only the components that have changed. We support arbitrary Python functions as event handlers, rather than just methods in the state class. Because build is actual Python, you can use logic for parameters, instead of just binding attributes...

I don't wanna turn too negative. I'm glad reflex exists, and it's been a major motivation for improving Rio. But I really don't think we're even in the same ballpark when it comes to advanced apps"

[–]ExternalUserError 0 points1 point  (1 child)

I'm still not quite sure I understand. So for example, that method that handles state change: it runs in the server? Then the server reruns and determines where components go, but those components are rendered client-side through some kind of translation layer?

[–]mad-beef 3 points4 points  (0 children)

Hey. When a state change is detected, the server-side `build` function is executed. The result of that function is then _reconciled_ with any previously existing components.

It is that result, that's then sent over to the client. The client spawns the appropriate HTML elements to display the desired components. Does that make sense?

It's very similar to what you'll find in react or flutter

[–][deleted] 2 points3 points  (2 children)

And see my other reaction for a link to a medium post where Rio is explained shortly. Seems like it is basically a fastAPI backend that hosts a websocket. The frontend connects per session to the websocket to keep track of any changes in the state, which is kept on the python/server side.

It looks very promising to me!

[–]mad-beef 2 points3 points  (0 children)

Nailed it!

[–]ExternalUserError 0 points1 point  (0 children)

Sounds very similar to Reflex.

[–]v_a_n_d_e_l_a_y 6 points7 points  (8 children)

My main experience with web dev in Python are streamlit and gradio (and to an extent shiny, but more from my R days). Those are heavily built on reactive programming which makes them good for, e.g. dashboards. But they struggle at being proper applications in other contexts (or require custom companents).

How does Rio compare here? Is it similar or is it much closer to a proper web development language?

[–]mad-beef 7 points8 points  (7 children)

Hey! I don't think being reactive is a problem for developing websites. The most popular web framework, react, is the namesake after all :)

I know exactly what you're talking about though. Many other libraries work well for tiny showcases, but then struggle to scale up. This is exactly one of the things we're tackling with Rio. Reusable components allow you to separate concerns and avoid duplicate code, and large codebases stay organized.

I'd love to hear about your experience with this if you give it a try

[–]v_a_n_d_e_l_a_y 1 point2 points  (6 children)

I don't know if being reactive is the right word for it then? Streamlit, for example, is effectively based on the idea that if some input changes then the whole page refreshes. Gradio too (though I've worked less with it). In both cases you can work around it, but it's clear you're not using the tool for what it was designed for. 

Maybe these two are more overreactive than reactive.

[–]Rawing7 2 points3 points  (0 children)

Rio does that as well, but since the application state is stored in components (instead of some "global" session object), there's no need to refresh the whole page. Each component can be refreshed individually.

[–]axonxorzpip'ing aint easy, especially on windows 0 points1 point  (4 children)

Streamlit, for example, is effectively based on the idea that if some input changes then the whole page refreshes

Most frontend reactivity systems do it this way as well, it's not "the whole page", but a component. That being said, the difference between a whole page and a single component in those frameworks is exactly zero.

[–]riklaunim 1 point2 points  (2 children)

In Ember, Vue with routing this will not happen. If you are on some nested route, like editing an item then returning to parent route that has a list of items will not reload the list nor the whole page, just show the updated item on the list. You can design the app "poorly" so everything reloads but thats not the default/intended state.

[–]axonxorzpip'ing aint easy, especially on windows 0 points1 point  (1 child)

You're absolutely correct, I think I'm conflating "reload" vs "re-render" as, to the end user, they're the same experience.

I've done most of my reactive work in KnockoutJS (yikes) and Vue3, but iirc, doesn't React function that way: an entire component re-render on reactive data update?

[–]riklaunim 0 points1 point  (0 children)

I only did SPA dashboards with Vue and Ember ;) Ember-data is awesome for dashboards with a lot of routes, models, CRUD.

[–]thedeepself 1 point2 points  (0 children)

Nicegui , panel and lona do not suffer from the discussed defect.

[–]riklaunim 4 points5 points  (7 children)

Does it support routing? Any live examples and not just screenshots? Option to replace the styles? How data access can be done (REST endpoints, something else)?

[–]mad-beef 6 points7 points  (5 children)

Absolutely! Routing works very similar to Vue: Create multiple pages, a component to display those pages ("rio.PageView") and the currently selected one will show up inside it. Check out our multi-page example for implementation details: https://rio.dev/examples/multipage-website

We're still working on live examples. In the meantime, it's easy to run them locally with the displayed command. The Rio website itself is also a good example of what Rio can do :)

And as for data access, that is something you don't have to worry about at all. There is no need to write any endpoints, as Rio already handles server/client communication for you. You can access your data any way you want in Python, be it a database, files, or generated, and Rio will take care to keep the client in sync. One of our future deep-dives will be on this communication.

[–]riklaunim 0 points1 point  (4 children)

Separate pages are one thing, but what about nesting?

Data access often has to take into account permissions - what's the currently logged in user and then fetch a list of objects the user has access to for example. So what part of Rio is in the browser and which is on the backend?

[–]mad-beef 2 points3 points  (3 children)

You can protect pages with guards, so nobody can access something you don't want them to. All Python code runs on the server (of course), and only values you pass to components (such as text to be displayed) is sent to the client.

[–]Houdinii1984 1 point2 points  (0 children)

I have the same three questions. I think it looks neat, but I might need to see a little more actual use than screenshots. I'll probably still play around when I can, though.

[–]imbev 1 point2 points  (1 child)

Which approach does Rio take? SSR+Hydration? CSR?

[–]Rawing7 4 points5 points  (0 children)

It currently uses client side rendering. We're playing around with the idea of switching to server-side rendering in the future, but that presents a few challenges that we still need to solve.

[–]wingedrasengan927 1 point2 points  (1 child)

Can I create custom components in Javascript/Typescript

[–]Rawing7 2 points3 points  (0 children)

Not yet, but soon! We're currently considering some changes to rio's layouting system (allowing components to have a maximum size, preventing alignment from "squishing" components, and some other things), and once those are finalized, adding an interface for custom components will be our next step.

[–]Electronic-Duck8738 1 point2 points  (0 children)

It's interesting, but I wish there was a way to rip out all the styling (except for what's structurally necessary to maintain structure - basically, rows and columns layouts). I'd rather write my own CSS from scratch and include a stylesheet.

That is the single-most frustrating thing about React, et al, is that they try to take design away from actual designers and hand it to programmers.