[HN Gopher] Show HN: Mesop - Open-source Python UI framework
       ___________________________________________________________________
        
       Show HN: Mesop - Open-source Python UI framework
        
       I'm excited to share about Mesop - a new, open-source Python UI
       framework that enables Python developers to quickly build
       delightful web apps in a scalable way.  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!
        
       Author : willchen
       Score  : 96 points
       Date   : 2024-06-03 20:44 UTC (2 days ago)
        
 (HTM) web link (google.github.io)
 (TXT) w3m dump (google.github.io)
        
       | EddieLomax wrote:
       | 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.
        
         | willchen wrote:
         | 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
        
           | EddieLomax wrote:
           | Thanks! I somehow completely missed the deployment section.
        
       | devtom wrote:
       | 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 ?
        
         | willchen wrote:
         | 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
        
           | devtom wrote:
           | 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.
        
             | willchen wrote:
             | 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.
        
               | devtom wrote:
               | 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.
        
           | devtom wrote:
           | 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 ?
        
             | willchen wrote:
             | 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!
        
               | devtom wrote:
               | Yay, thank you :-) going to take a look!
        
       | FloatArtifact wrote:
       | If only we had something like this for native desktop
       | applications.
        
         | willchen wrote:
         | 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
        
         | zerr wrote:
         | wxPython, Qt for Python, Tkinter?
        
       | giancarlostoro wrote:
       | 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.
        
         | willchen wrote:
         | 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-...
        
           | giancarlostoro wrote:
           | 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.
        
         | appveyor wrote:
         | 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.
        
       | sergius wrote:
       | 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?
        
         | abdullahkhalids wrote:
         | There is also https://reflex.dev/
        
         | willchen wrote:
         | 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.
        
       | zinclozenge wrote:
       | 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
        
         | willchen wrote:
         | 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.
        
       | gostsamo wrote:
       | 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?
        
         | willchen wrote:
         | 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!
        
           | gostsamo wrote:
           | 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.
        
             | willchen wrote:
             | Thanks, I've filed an issue:
             | https://github.com/google/mesop/issues/359
        
       | VagabundoP wrote:
       | 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?
        
         | willchen wrote:
         | 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.
        
       | herrington_d wrote:
       | 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?
        
         | willchen wrote:
         | 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 f
         | ile](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.
        
           | rmbyrro wrote:
           | fyi, HN doesn't support markdown
        
       | solidasparagus wrote:
       | 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_ ).
        
         | willchen wrote:
         | 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.
        
           | solidasparagus wrote:
           | 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
        
       | groodt wrote:
       | 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/
        
       | jbednar wrote:
       | 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!
        
       | spankalee wrote:
       | 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.
        
       ___________________________________________________________________
       (page generated 2024-06-05 23:02 UTC)