Show HN: Mesop – Open-source Python UI framework(google.github.io)
google.github.io
Show HN: Mesop – Open-source Python UI framework
https://google.github.io/mesop/
55 comments
This is appealing to me as a Python backend dev-- but if I end up building something cool for my own personal use, and I want to deploy it so others can use it-- is that a thing for this? I don't see any kind of documentation for deploying it, but that could just be on me. I realize this is touted as a demo-friendly / internal tool so that just might not be aligned for this type of thing.
Yeah, you can definitely deploy it to share with others. Check out our deployment guide (https://google.github.io/mesop/guides/deployment/) which shows you how to deploy Mesop apps to Google Cloud Run, but you should be able to deploy it on pretty much any service that takes a container.
For example, the demo gallery (https://google.github.io/mesop/demo/) itself is a Mesop app which is hosted on Cloud Run
For example, the demo gallery (https://google.github.io/mesop/demo/) itself is a Mesop app which is hosted on Cloud Run
Thanks! I somehow completely missed the deployment section.
Thank you! This looks very interesting and promising. I had issues running it locally on my Mac with pandas problems. But I switched to collab and it run well there. I guess you would use "requests" to get and post data to the backend ?
Could you share the error you're getting locally?
Re: calling backend, yeah you can use requests or anything else (e.g API client libs, talk to DB directly). The beauty is that you're just writing regular python code
Re: calling backend, yeah you can use requests or anything else (e.g API client libs, talk to DB directly). The beauty is that you're just writing regular python code
The error is: partially initialized module 'pandas' has no attribute '_pandas_datetime_CAPI' (most likely due to a circular import)
This happens only on the second interaction.
This happens only on the second interaction.
OK thanks. I've filed an issue here: https://github.com/google/mesop/issues/345 if you could share with us a repro (the Mesop code you're running) on the issue, that would be helpful in debugging this.
If you take a look at the "table" example on the demo gallery: https://google.github.io/mesop/demo/ it shows how to use Pandas w/ Mesop, so I'm not sure what's going on.
If you take a look at the "table" example on the demo gallery: https://google.github.io/mesop/demo/ it shows how to use Pandas w/ Mesop, so I'm not sure what's going on.
ok, will look at the issue and add an example if possible. The code I was executing was one of the example code present on the site. So nothing special.
So If I make a request from the python code, is the request executed in the browser ? or on the server ? Is the UI layer executing in the browser and use proxy rpc from the server ?
All the python code, including requests are executed on the server
Take a look at https://google.github.io/mesop/internal/architecture/ for an explainer on how the client-server interaction works and let me know if you have any questions!
Take a look at https://google.github.io/mesop/internal/architecture/ for an explainer on how the client-server interaction works and let me know if you have any questions!
Yay, thank you :-) going to take a look!
If only we had something like this for native desktop applications.
Might want to check out: https://flet.dev/docs/cookbook/packaging-desktop-app/
I haven't used it personally (this is separate from mesop), but it looks like a way to program desktop guis (among other platforms ( in Python
I haven't used it personally (this is separate from mesop), but it looks like a way to program desktop guis (among other platforms ( in Python
wxPython, Qt for Python, Tkinter?
Try dearpygui or pyimgui
Will you guys ever just do Python -> WASM? I think the next "Big break" for front-end web dev is literally this. I've been using Microsoft's Blazor (C#) which is this, with a mix of back-end and front-end capabilities, and I just don't see any reason to ever use JS or React again.
This is definitely something we've discussed and I think Python -> WASM is an exciting innovation. Right now, there's some challenges with how large of a WASM binary a typical Python app will compile to (e.g. bundling the std lib) and the initialization time [1].
I think supporting Python -> WASM could be one of the options we support, but there's probably always a need to support Python on the server, simply due to the ecosystem (e.g. dependencies) that's around it.
[1] https://pyodide.org/en/stable/project/roadmap.html#reducing-...
I think supporting Python -> WASM could be one of the options we support, but there's probably always a need to support Python on the server, simply due to the ecosystem (e.g. dependencies) that's around it.
[1] https://pyodide.org/en/stable/project/roadmap.html#reducing-...
I've thought about trying to support something along the lines of Django Templates -> WASM, but the one interesting thing that Blazor does is it also renders the templates on the back-end for those who don't necessarily want to render it on the browser. I think you'd have to consider some sort of templating language, that intermixes nicely with Python. If I remember correctly, Mako was a templating library I used for a project ages back, they focused on letting you for the most part just use standard python for the scripting side of the template engine.
So if I had the time and energy, I'd spend my time looking at something like Mako, maybe even forking it, and making it minimal enough to build into WASM. I assume you mainly want to shove a templating library into WASM and not too much more. The rest you could offload to a smaller JS library your WASM can interface through.
I could be talking off my other end, but this is all spit balling from various things I've read, I'm by no means a total expert.
So if I had the time and energy, I'd spend my time looking at something like Mako, maybe even forking it, and making it minimal enough to build into WASM. I assume you mainly want to shove a templating library into WASM and not too much more. The rest you could offload to a smaller JS library your WASM can interface through.
I could be talking off my other end, but this is all spit balling from various things I've read, I'm by no means a total expert.
As we mentioned Flet here - it's been able to build web apps running completely in the web browser (Flutter + Pyodide). Here are a few examples: https://flet.dev/gallery - most of those apps there are client-side except "Controls gallery" and "Chat" which are server-side.
How does it compare to https://nicegui.io/ ?
How does it compare with https://flet.dev/ ?
Does it compete in the niche of making simple things easy and hard things possible?
How does it compare with https://flet.dev/ ?
Does it compete in the niche of making simple things easy and hard things possible?
There is also https://reflex.dev/
Yeah, I think the "simple things easy and hard things possible" is a good way of framing this. I've written a blog post about the design philosophy of Mesop and how it differentiates with existing frameworks:
https://google.github.io/mesop/blog/2024/05/13/why-mesop/
Re: flet - flet intentionally takes a more imperative approach whereas Mesop embraces a declarative UI approach (as popularized by React, et al). I think the declarative UI approach scales better as apps get more complex, but I think the best way to see the difference is to look at some of the examples and see which approach you like more.
Re: nicegui - at the high level, there's definitely some similarities with the component-centric UI model. The data binding/state management works quite a bit differently and Mesop's approach provides stronger type-safety and, IMO, is more Pythonic, but that said, there's a lot of good options in this space and I think it's neat to look at all the innovation that's happening here, and ultimately, some of this is based on aesthetics and how you like to code your UIs.
Re: flet - flet intentionally takes a more imperative approach whereas Mesop embraces a declarative UI approach (as popularized by React, et al). I think the declarative UI approach scales better as apps get more complex, but I think the best way to see the difference is to look at some of the examples and see which approach you like more.
Re: nicegui - at the high level, there's definitely some similarities with the component-centric UI model. The data binding/state management works quite a bit differently and Mesop's approach provides stronger type-safety and, IMO, is more Pythonic, but that said, there's a lot of good options in this space and I think it's neat to look at all the innovation that's happening here, and ultimately, some of this is based on aesthetics and how you like to code your UIs.
I've seen a bunch of people recommending alternatives that are also Python based, makes me wonder if there's similar things for other languages like Go, Rust, etc
There's similar things in other languages like https://www.gpui.rs/ and https://github.com/linebender/xilem.
Mesop also drew inspiration from frameworks like LiveView (for Elixir/Phoenix) https://hexdocs.pm/phoenix_live_view/welcome.html which have demonstrated the viability of building server-driven web UIs for a number of years now.
Mesop also drew inspiration from frameworks like LiveView (for Elixir/Phoenix) https://hexdocs.pm/phoenix_live_view/welcome.html which have demonstrated the viability of building server-driven web UIs for a number of years now.
My standing question is "How do you handle accessibility"? Are the resulting apps accessible by default for people with screen readers? About peoplewith other disabilities?
Accessibility is important and the good thing is Mesop is built on Angular Material components (https://material.angular.io/components/) which has invested in supporting a11y. Mesop components are likely missing aria-* attributes, but it's pretty easy for us to add them (essentially plumbing them from Python into the Angular components), so please file an issue on our GitHub repo to let us know what we're missing, thanks!
At a first glance at the demo gallery, nothing there is labeled as a button except for some in the embedded frame. The buttons there does not have an accessible label though. Nothing is list or grid, on the page and when any of the demo buttons are pressed, the focus is not moved to the new content. So, aria-role and aria-label as a start, I think.
Thanks, I've filed an issue: https://github.com/google/mesop/issues/359
I've had a quick look through the docs/demos.
At the moment I use Flask/htmx/tailwind for my apps, but I like how succinct this framework is, but how themable is it?
At the moment I use Flask/htmx/tailwind for my apps, but I like how succinct this framework is, but how themable is it?
You can customize the UI quite extensively using our Style API https://google.github.io/mesop/components/style/
If you like tailwind, I think you will like this as it's essentially like writing inline styles, but with a Pythonic, strongly-typed API.
If you like tailwind, I think you will like this as it's essentially like writing inline styles, but with a Pythonic, strongly-typed API.
I'll try a small demo of my existing app and see if I can transition it. I've started to use dominate to replace jinja templates anyway as the multiple languages on the web layer was just causing me friction and slowing down the rolling out new things.
Glad to see Google employee still has 20% of their time to do side projects!
Python UI is especially interesting for ML/LLM folks who can build demos without changing tech stack.
I appreciate OP's ideas about how this project is compared to Streamlit?
I appreciate OP's ideas about how this project is compared to Streamlit?
Thanks for the question! Streamlit is definitely more mature and I think it's a great tool for many use cases.
Where I think Mesop shines is that you get a lot of flexibility, just by writing your UI in Python. For example, Mesop has an out-of-the-box [chat component](https://google.github.io/mesop/demo/), but if you need to customize it, you can actually just copy the [chat.py file](https://github.com/google/mesop/blob/main/mesop/labs/chat.py) and customize it however you want.
In comparison, Streamlit is great to get started with, but once you're trying to do some complex customizations, you'll often need to write your own React/TypeScript component.
I think the other thing is that Mesop has a [different philosophy for building UIs](https://google.github.io/mesop/blog/2024/05/13/why-mesop/) (e.g. based on functions) which results in a distinctly different developer experience. This is, of course, subjective, but I think the Mesop approach scales well as your app grows (e.g. thousands of lines), which even internal tools and demos oftentimes do.
Where I think Mesop shines is that you get a lot of flexibility, just by writing your UI in Python. For example, Mesop has an out-of-the-box [chat component](https://google.github.io/mesop/demo/), but if you need to customize it, you can actually just copy the [chat.py file](https://github.com/google/mesop/blob/main/mesop/labs/chat.py) and customize it however you want.
In comparison, Streamlit is great to get started with, but once you're trying to do some complex customizations, you'll often need to write your own React/TypeScript component.
I think the other thing is that Mesop has a [different philosophy for building UIs](https://google.github.io/mesop/blog/2024/05/13/why-mesop/) (e.g. based on functions) which results in a distinctly different developer experience. This is, of course, subjective, but I think the Mesop approach scales well as your app grows (e.g. thousands of lines), which even internal tools and demos oftentimes do.
fyi, HN doesn't support markdown
> HN doesn't support markown
Oh, but it does, it's just plaintext with classic “[squared](circle)” convention: clickable inline (references) following [annotated clauses]. We can read the term, and click the ref.
Markdown's point is if plaintext is supported, so is Markdown.
Oh, but it does, it's just plaintext with classic “[squared](circle)” convention: clickable inline (references) following [annotated clauses]. We can read the term, and click the ref.
Markdown's point is if plaintext is supported, so is Markdown.
If it's not rendered, then it's not supported. This is very obvious in this case, where the square-brackets have no additional value, but make it just harder to read the text. The links are getting rendered independent of the brackets, so markdown-syntax has no function here.
I think most markdown symbols add semantic comprehension or emphasis value in _plain_ text. That is functional[^1] even here.
Including the squared circle for inline links.
[^1]: As in functional requirements, is serving to convey the markup intent in a non rich text rendering.
Including the squared circle for inline links.
[^1]: As in functional requirements, is serving to convey the markup intent in a non rich text rendering.
Something tells me you felt clever posting this. If you're open to a different perspective:
The underscore makes your text worse to read, IMO. Same with the MD anchor syntax.
HN supports italicizing by wrapping an expression with asterisks *. Why insist on a foreign standard?
HN commenters use the [{i}] notation all the time for footnote referencing. Which can be used for links, declutttering the main text.
Why add a ^?
The underscore makes your text worse to read, IMO. Same with the MD anchor syntax.
HN supports italicizing by wrapping an expression with asterisks *. Why insist on a foreign standard?
HN commenters use the [{i}] notation all the time for footnote referencing. Which can be used for links, declutttering the main text.
Why add a ^?
Certainly, italics in asterisks, but underscores are valid too in plain text, double either to get bold. I wanted the _underscore_ since I was talking about plaintext and didn't want it disappeared, though I *suppose* this works too.
^ means superscript, as footnote numbers are in publishing, but more importantly, https://github.blog/changelog/2021-09-30-footnotes-now-suppo...
^ means superscript, as footnote numbers are in publishing, but more importantly, https://github.blog/changelog/2021-09-30-footnotes-now-suppo...
Following that logic, wouldn't HN be a runtime for anything written, from assembly to Python? Which sounds... not quite right?
This is really cool - I love Python UIs. This seems very similar to streamlit.
But the demos aren't very pretty :(
I feel like being able to build something beautiful should be a requirement for any tool to build UIs. People like me who care about the looks aren't afraid to dig into CSS as long as you make it feasible (cough streamlit cough).
But the demos aren't very pretty :(
I feel like being able to build something beautiful should be a requirement for any tool to build UIs. People like me who care about the looks aren't afraid to dig into CSS as long as you make it feasible (cough streamlit cough).
Thanks! Agree, we wanted to provide a high-degree of customizability with a CSS-like API https://google.github.io/mesop/components/style/ so you can create delightful demos.
Ah that's excellent! I didn't notice that, it might be a good idea to highlight it a bit more. On the front page, "Build custom UIs without writing Javascript/CSS/HTML" made me think CSS wasn't an option
Good point, we'll try to rephrase this to be clearer. Thanks for the feedback!
Exciting!
I'm surprised to see nobody has mentioned gradio yet. It seems to sit in the same niche as streamlit and mesop.
https://gradio.app/
I'm surprised to see nobody has mentioned gradio yet. It seems to sit in the same niche as streamlit and mesop.
https://gradio.app/
I've added mesop to https://pyviz.org/tools.html#dashboarding, where it is the 35th OSS Python dashboarding tool to appear. (There were 5 in 2019). It's a crowded space!
Thanks! Yeah, a lot of innovation happening in this space.
It would be really awesome if the native component model were built around standard web components instead of Angular. This would let people bring their own components regardless of what framework they were built in. And for the built-in native components, it means you wouldn't have to worry about integrating with the Angular compiler.
[deleted]
Useful to know about this Python web UI framework. There are also other Python web UI framework suggestions in the thread replies too.
This is very interesting. To build LLM chat-oriented WebApps in python, these days I use Chainlit[1], which I find is much better than Streamlit for this. I've integrated Chainlit into the Langroid[2] Multi-Agent LLM framework via a callback injection class[3], i.e. hooks to display responses by various entities. Example demos are here[4].
One of the key requirements in a multi-agent chat app is to be able to display steps of sub-tasks nested under parent tasks (to any level of nesting), with the option to fold/collapse sub-steps to only view the parent steps. I was able to get this to work with chainlit, though it was not easy, since their sub-step rendering mental model seemed more aligned to a certain other LLM framework with a partial name overlap with theirs.
That said, I am very curious if Mesop could be a viable alternative, for this type of nested chat implementation, especially if the overall layout can be much more flexible (which it seems like), and more production-ready.
[1] Chainlit https://github.com/Chainlit/chainlit
[2] Langroid: https://github.com/langroid/langroid
[3] Langroid ChainlitAgentCallback class: https://github.com/langroid/langroid/blob/main/langroid/agen...
[4] Langroid chainlit demos https://github.com/langroid/langroid/tree/main/examples/chai...
One of the key requirements in a multi-agent chat app is to be able to display steps of sub-tasks nested under parent tasks (to any level of nesting), with the option to fold/collapse sub-steps to only view the parent steps. I was able to get this to work with chainlit, though it was not easy, since their sub-step rendering mental model seemed more aligned to a certain other LLM framework with a partial name overlap with theirs.
That said, I am very curious if Mesop could be a viable alternative, for this type of nested chat implementation, especially if the overall layout can be much more flexible (which it seems like), and more production-ready.
[1] Chainlit https://github.com/Chainlit/chainlit
[2] Langroid: https://github.com/langroid/langroid
[3] Langroid ChainlitAgentCallback class: https://github.com/langroid/langroid/blob/main/langroid/agen...
[4] Langroid chainlit demos https://github.com/langroid/langroid/tree/main/examples/chai...
This is a Great project I am really looking forward to using for internal apps. IMO a central requirement for internal apps is auth, especially OIDC/SAML-type auth. How do you recommend implementing this in mesop?
Looking through the docs I am guessing a nice place for auth to hook into is the on_load parameter of the pages API? https://google.github.io/mesop/api/page/#mesop.features.page...
Looking through the docs I am guessing a nice place for auth to hook into is the on_load parameter of the pages API? https://google.github.io/mesop/api/page/#mesop.features.page...
This seems like a direct copy of reflex.dev https://reflex.dev/docs/events/page-load-events/
I have taken a thorough look at the source and I very much enjoyed it.
The project highlights the utility of Bazel more than I have seen before. How long did it take you (and others) to become as fluent as you are in Bazel and working with it?
Additionally, you (Will) seem to have a very intuitive grasp of build processes in general, notably many of the scripts are fun to dive into and have a very clean design. How did you familiarize yourself so well with those sorts of concepts? Do you have any recommended readings or side-projects you’d recommend tackling to get experience with?
The project highlights the utility of Bazel more than I have seen before. How long did it take you (and others) to become as fluent as you are in Bazel and working with it?
Additionally, you (Will) seem to have a very intuitive grasp of build processes in general, notably many of the scripts are fun to dive into and have a very clean design. How did you familiarize yourself so well with those sorts of concepts? Do you have any recommended readings or side-projects you’d recommend tackling to get experience with?
Thanks! I've used Google's internal version of Bazel but it wasn't until this project where I had to spend a lot of effort getting Bazel working in a new project, which is honestly a lot of work and not very straightforward :(
What helped me the most was looking at other projects using Bazel with similar tech stacks and then assembling it together, e.g. :
- https://github.com/angular/components - https://github.com/tensorflow/tensorboard
Alex Eagle of https://www.aspect.build/ has a lot of great resources on using Bazel - both on YouTube and the aspect website.
What helped me the most was looking at other projects using Bazel with similar tech stacks and then assembling it together, e.g. :
- https://github.com/angular/components - https://github.com/tensorflow/tensorboard
Alex Eagle of https://www.aspect.build/ has a lot of great resources on using Bazel - both on YouTube and the aspect website.
A small team of us at Google have been developing Mesop as an unofficial 20% project for the past few months. A wide range of research and product teams at Google have been using it to rapidly build internal apps and we’ve gotten a lot of positive feedback internally so now we’re looking to get feedback from the open-source community.
We think that Mesop provides a unique approach to building web UIs in Python - making it both easy to get started and also flexible enough to build customized UIs for a wide range of use cases. You can learn more about why we built Mesop here: https://google.github.io/mesop/blog/2024/05/13/why-mesop/
To look at some example Mesop apps, check out our demo gallery: https://google.github.io/mesop/demo/. Also, the demo gallery itself is built with Mesop: https://github.com/google/mesop/blob/main/demo/main.py which demonstrates the type of flexibility you have in building apps with Mesop.
A couple of us will be on here answering questions. Let us know what you think!