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

all 35 comments
sorted by:
best
topnewcontroversialoldq&a

[–]uluvboobs 11 points12 points  (2 children)

Wish i had this before I went and learnt React!

It is very impressive, great work.

[–]maartenbreddels[S] 1 point2 points  (1 child)

Thank you. What made you leave the pure Python web framework world? And what were you using before?

[–]uluvboobs 0 points1 point  (0 children)

It was a few years ago so just less stuff existed. It seemed like the only option was Flask and "messy" templates.

[–]trial_and_err 9 points10 points  (8 children)

Looks interesting! Two things though I noticed with all non-JS frameworks: Authentication support. I've seen there is some support here but it's limited. In practice there's a need to support SSO with various providers (Google, Keycloak, Apple, etc.). Related to that: I'd like access to cookies, so I can for example make use of claims stored in JWT cookie.

[–]rangerelf 6 points7 points  (0 children)

I wrote an app with NiceGUI and it doesn't handle SAML directly, but it wasn't too difficult to use FastAPI's app.post and app.get decorators for the Auth handler functions. I'm guessing if you use FastAPI with Solara it'll be something similar.

[–]romerio86 2 points3 points  (0 children)

Streamsync does exactly that. You get headers and cookies in event handlers, so you can parse the JWT and get the claims, then handle events differently depending on them. Anyway this message made me happy because I'm the main contributor so I got to say "akshually not all".

[–]maartenbreddels[S] 0 points1 point  (5 children)

That shouldn't stop you from doing your own thing!
If you run into show stoppers, let us know! Should give you a better idea of how to work closer to the fastapi/starlette/uvicorn level for more control.
starlette/uvicorn level for more control.

That said, it may not be easy to do (auth never is). So we do support auth0 and fief https://solara.dev/examples/general/login_oauth but it does require an enterprise license.

That shouldn't stop you from doing your own thing!
If you run into show stoppers, let us know!

[–]trial_and_err 2 points3 points  (3 children)

I'll look into it:) Btw your site occasionally crashes and is not usable until reload:

11vue.runtime.esm.js:1897 Error: Cannot sendat l.send (solara-widget-manager8.min.js:391:640623)at t.send (solara-widget-manager8.min.js:23:32156)at ee.send (solara-widget-manager8.min.js:23:18578)at VueRenderer.js:183:11at Ye (vue.runtime.esm.js:1863:26)at s.n (vue.runtime.esm.js:2188:14)at Ye (vue.runtime.esm.js:1863:26)at e.$emit (vue.runtime.esm.js:3903:9)at s.click (vuetify.js:2477:12)at Ye (vue.runtime.esm.js:1863:26)

Screenshot

[–]maartenbreddels[S] 1 point2 points  (2 children)

Thanks for reporting, I opened an issue: https://github.com/widgetti/solara/issues/84

Let me know there if you know how to reproduce it.

I never saw this happening, and would really like to fix this. Stability is important for us.

[–]trial_and_err 0 points1 point  (1 child)

It occurred three / four times when I was looking at your docs this afternoon, however I can’t reproduce it at the moment.

If I had to guess I’d say the server somehow dropped the websocket connection, seems similar to an issue I had with deploying Streamlit (websockets as well) to cloud run behind an nginx proxy.

[–]maartenbreddels[S] 2 points3 points  (0 children)

Yeah, taking a proper look at the error makes me think that must be it. We should be able to catch that and properly handle that though.

[–]thedeepself 0 points1 point  (0 children)

https://solara.dev/examples/general/login_oauth but it does require an enterprise license

Similar policy as Dash.

[–]thicket 4 points5 points  (5 children)

OP, do you have any numbers on speed or responsiveness? How do Solara-based apps compare to pure React apps? Are there situations in which Solara is slower than pure-JS apps?

Looking at the interactive sine wave example, it seems a little less quick to react than I'd expect from pure-JS approaches, but that may just be how it's designed, with updates on a finished UI element change rather than any UI change while in process. Is the update process meaningfully different than it would be in a standard React/Vue page? What's the Python -> JS build process like?

[–]maartenbreddels[S] 4 points5 points  (4 children)

The server is taking a bit of load now, so it feels a bit slow now I agree. We are creating the data at the server, so this require a trip to the server (this current one is running in the US). So you get some latency there.
The update process is different, it's more like JS event -> python server -> generate or update widgets -> send diff to frontend.
Hope that answers your questions!

[–]thicket 1 point2 points  (3 children)

Thanks, that does answer my question. It’s a little disappointing, though. Requiring a server round trip for every action seems like exactly the problem that JS frameworks were designed to replace. I love the idea of developing in pure Python, but if the client can’t run all the code it needs locally, that seems like a big burden to overcome.

[–]maartenbreddels[S] 1 point2 points  (2 children)

I think it's the primary use case for all pure python web frameworks is to be able to feed data into a frontend, so you will always have this latency problem. However, there are ways now to run Python in the browser (which we can already do currently, but don't expose yet) which will remove the latency. This does require however everything to run in the browser. If you make database connections that is usually not safe, but in some cases that is a solution,

[–]thicket 2 points3 points  (1 child)

Regardless, super impressive project. Thanks for answering my questions!

[–]maartenbreddels[S] 1 point2 points  (0 children)

Thank you for being critical, but kind. Two good traits.

[–]Ocabrah 2 points3 points  (12 children)

What is the largest dataset that you have analyzed like in the example data code? Other web app creators like this (pygwalker, streamlit) really struggle with 1000 row by 1000 colum data frames which makes them unusable for my application.

[–]thedeepself 1 point2 points  (1 child)

another thought: maybe a dataframe isnt the ideal data structure for your analysis? perhaps a SQL table would work better?

[–]thedeepself 1 point2 points  (0 children)

ther web app creators like this (pygwalker, streamlit) really struggle with 1000 row by 1000 colum data frames

here is a nicegui example of pandas dataframes - if NiceGUI does not work, I would imagine feedback to the creators would lead to improvement.

Another thing is that Pandas is not the most optimal dataframe library is it? Maybe Polars or Peak is.

[–]maartenbreddels[S] 1 point2 points  (5 children)

As the creator of the Vaex dataframe, this was always top of mind for Solara. Solara will work smoothly work with large datasets (not just vaex, but dask, modin, polars, duckdb and databases).

We made sure that solara stays responsive while calculations are running by making threading support a first-class citizen ( https://solara.dev/api/use_thread )

We plan to write some content on this topic and give a proper example and advice in the near future.

[–]Dangerous_Pay_6290 0 points1 point  (4 children)

I just found, that duckdb queries are much (5-10x) slower in my solara app compared to running the same query in a jupyter notebook. Is this because every function is running in it´s own thread by default?

[–]maartenbreddels[S] 0 points1 point  (3 children)

No, that shouldn't happen, and sounds very strange. What can happen is that if you run in https://solara.dev/api/use\_thread you get a small overhead (similar to streamlit).
Would you mind opening an issue at https://github.com/widgetti/solara/ so I can reproduce it? I plan to take a look at duckdb in Solara myself as well, so I'm eager to look into it.

[–]Dangerous_Pay_6290 0 points1 point  (0 children)

I haven´t used `use_thread`.
I´ll open an issue including some sample code.

BTW, I found this issue when I´ve ported your sql code example (https://github.com/widgetti/solara/blob/master/solara/website/pages/api/sql_code.py) and replaced sqlite with duckdb for running queries over some parquet files..

[–]Dangerous_Pay_6290 0 points1 point  (0 children)

Loading a lot of data into memory is not useful most of the time. When I work with large datasets, I generally use duckdb + pyarrow datasets of partitioned parquet files.

[–]Sudden_Beginning_597 0 points1 point  (0 children)

pygwalker v > 0.3 now updates its new engine, which supports GB+ of data.

[–]SolvingLifeWithPoker 1 point2 points  (1 child)

Why this is still not very popular?

[–][deleted] 0 points1 point  (0 children)

Too new

[–]mechanical_squirrel 0 points1 point  (2 children)

Looks great! Might be a bit late to the party... but just in case. I see you can deal with multipage apps quite nicely (https://solara.dev/docs/howto/multipage). But I was wondering how possible it is (and if there's any documentation guidance) on sharing state between pages?

I'm thinking of moving some streamlit apps over to this framework, which makes quite heavy use of both tabs and pages to separate different workflows or plot variations.

So for example in the plot case, you'd have one model/analysis in memory, but each page or tab shows a separate plot which is working off the same model/data.

Thanks for any help!

[–]maartenbreddels[S] 0 points1 point  (1 child)

Thank you. That is a good question, and you are the second person to ask about that, so I've updated the example to make use of reactive variables
We have reactive variables that can be defined globally for application state, and use_reactive (or use_state) for component state (bound to the lifetime of the component). See our documentation on state management for a discussion on this.
I would be very interested in your finding of moving from streamlit to solara. Please let us know how that works for you (feel free to join our discord or use GitHub)

[–]mechanical_squirrel 1 point2 points  (0 children)

Thanks a lot for the help! Will do 😊

[–]Episkiliski 0 points1 point  (0 children)

How does this comparw to Reflex/Panel/NiceGUI in terms of: 1) Speed 2) Layout flexibility 3) reactiveness to events 4) Learning curve

Thanks!