News for hackers. Stuff that matters.

maartenbreddels

Re:Build your Jupyter dashboard using Solara on Tuesday December 17, 2024 @10:15AM (#42441997)
I guess someone needs to build a Solara app running in the Jupyter Notebook to interface with Jupiter (running on Solana).
Also check out https://py.cafe/ (I work on this project)

It supports streamlit, dash, virzo and solara. Frameworks like shiny, gradio and panel are planned (maybe even fasthtml).

It's also really nice to integrate this into your documentation: https://mkdocs.py.cafe/

We plan to support fastHTML at https://py.cafe/

This also uses pyodide, but supports more frameworks out of the box.

On https://solara.dev/docs/tutorial/streamlit we highlight the main differences:

* Solara will not continuously re-execute your script as Streamlit does.

* Solara will re-execute components instead, only what needs to. * State in Solara is separate from the UI components, unlike streamlit, where they are strongly linked.

* State can be on the application level (global) for simplicity or on the component level (local) for creating reusable components.

* Solara should not block the render loop. Long-running functions should be executed in a thread using use_thread.

Re:We wrote the OpenAI Wanderlust app in pure Python using Solara on Wednesday November 08, 2023 @05:14PM (#38197909)
Yes, the API is a bit more complex than before but it does give more options!
Re:We wrote the OpenAI Wanderlust app in pure Python using Solara on Wednesday November 08, 2023 @05:13PM (#38197886)
Thank you
Re:We wrote the OpenAI Wanderlust app in pure Python using Solara on Wednesday November 08, 2023 @05:13PM (#38197878)
It’s demoed in https://www.youtube.com/live/U9mJuUkhUzk?si=Ko3FZ0Axx7jcZaQ7 @ 35:11 Hope that helps :)
Re:We wrote the OpenAI Wanderlust app in pure Python using Solara on Wednesday November 08, 2023 @03:30PM (#38196495)
It can be used for general purposes, but we focus on the data science landscape. However, our main website is built using solara, and we know a few startups using solara for their main product (public-facing, not internal).
Re:We wrote the OpenAI Wanderlust app in pure Python using Solara on Wednesday November 08, 2023 @02:56PM (#38196009)
We (the authors of the Solara web app framework) were inspired by the OpenAI keynote Wanderlust app they demoed and rebuilt it in Python using Solara. It would be good to showcase our framework's power and inspire others to build UI's with AI/LLM elements in it.

GitHub: https://github.com/widgetti/wanderlust App: https://huggingface.co/spaces/solara-dev/wanderlust X: https://twitter.com/maartenbreddels/status/17223244907077020... Solara: https://github.com/widgetti/solara/

Re:It's React, but in Python on Tuesday June 06, 2023 @04:25PM (#36218641)
Thanks for the shout out.

The follow up of that is Solara: "NextJS, but in Python" :)

https://github.com/widgetti/solara/

Not sure where you found that link, but https://solara.dev/api should work fine!

Let’s take that question to GitHub or discord not to go too much off topic here ok? Thanks!

In Solara you can dynamically put together the UI like in react, in pynecone you need to use their primitives to make lists and conditional rendering. Also, state management is not tied to solara, but could use dataclasses or pydantic, wrapped in a reactive variable.

I think what sets Solara apart from the rest is that we use a 10 year proven paradigm, React, but on the Python side, although with a more Pythonic API. For instance making reusable components in Python is a real benefit. Pynecone uses ReactJS in the front end, but on the Python side it’s their own API.

I do like pynecone, their API is pretty. I do wonder with many of these frameworks. Does the paradigm works for more complex apps, or does it end in complexity hell once you go past the hello world examples. At least React has proven itself.

Co-creator of Voila here. Voila is rather un-opinionated about what you can run in it. While it offers excellent support for ipywidgets, it's certainly not confined to that. One downside of Voila is that it can be resource-intensive, as it creates a new kernel/process for each page view or browser tab.

Mercury, in my view, seems really interesting for quick demos and reports. It's somewhat akin to Streamlit, making it ideal for notebook authors.

On the other end of the spectrum (and pardon my shameless plug here), there's Solara (https://github.com/widgetti/solara/). Solara is a fully-fledged web framework for Python, specifically designed to handle app sizes that surpass what Streamlit and Dash can manage. It's worth noting that Solara can render ipywidgets, using a pure Python React-like framework. This can be particularly useful after the exploration phase, when you're looking to transition a project from the notebook into production.

Correct. We were already doing that with pure/classic ipywidgets based apps.

We helped many clients get their prototypes into production and identifier some friction doing that.

We now have a way to make more complex apps using the same stack, and get better app startup performance.

We're excited to introduce Solara: A pure Python web framework built for large, complex apps.

While there are many Python web frameworks out there, most are designed for small data apps or use paradigms unproven for larger scale. Code organization, reusability, and state tend to suffer as apps grow in complexity, resulting in either spaghetti code or offloading to a React application.

Solara addresses this gap. Using a React-like API, we don't need to worry about scalability. React has already proven its ability to support the world's largest web apps.

Solara uses a pure Python implementation of React (Reacton), creating ipywidget-based applications. These apps work both inside the Jupyter Notebook and as standalone web apps with frameworks like FastAPI. This paradigm enables component-based code and incredibly simple state management.

By building on top of ipywidgets, we automatically leverage an existing ecosystem of widgets and run on many platforms, including JupyterLab, Jupyter Notebook, Voilà, Google Colab, DataBricks, JetBrains Datalore, and more.

We look forward to your thoughts and feedback!

Show HN: Write React in the Jupyter notebook without JavaScript build tools

https://github.com/widgetti/ipyreact

The friction of getting a small snippet of React code into the Jupyter notebook really high. Especially when you want to have communication between the browser and the Python process.Using sucrase to do transpiling of jsx/tsx in the browser, and using ES modules features (+shims) allows you to take for instance any Material UI example (like https://mui.com/material-ui/react-rating/) and have it...

( Read More... | no comments | 2 points | on HN )

Show HN: Reacton – A pure Python port of React for ipywidgets

https://github.com/widgetti/reacton

Hi, I'm an ipywidgets maintainer, which is a library for writing interactive widgets in the Jupyter notebook.For our living, we help organisations create larger applications, and sometimes turn them into user facing web applications using Voilà.Over time, we noticed that making larger application hit the same problems as web applications in the jQuery era (state transitions being the biggest...

( Read More... | no comments | 5 points | on HN )
My guess is that should be possible, feel free to hop onto https://github.com/vaexio/vaex/discussions !
Thanks, glad you find Vaex useful.

Indeed, for small data there is not much to gain, at least this is not the focus of this article. Although even with small amounts of the, the automatic pipelines are useful https://vaex.io/blog/ml-impossible-train-a-1-billion-sample-...

AFAIK Modin tries to be the API compatible with Pandas, but then faster/distributed. Vaex tries to be a DataFrame library that is as fast as possible on a single machine to keep things simple and fast (although distributed is on the horizon, we don't need it currently). We're not afraid to break compatibility with pandas, because we care about performance. Both libraries try to hide the laziness from the user.
Yes, Arrow 3.0 has much more string kernels https://arrow.apache.org/docs/cpp/compute.html
Re:A Visual Debugger for Jupyter on Saturday March 28, 2020 @04:27PM (#22714078)
For a visual output, voila can give you a dashboard look: https://github.com/voila-dashboards/voila/ see e.g. https://github.com/maartenbreddels/voila-demo for a mobile-ready responsive rendering of a notebook.

Older »