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
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.
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.
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.
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.
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.
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.
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.
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.
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: 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
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 ?
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.
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.
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.
