7 ms·

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 c

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 2y ago
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/ 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 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/ 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 2y ago
  fyi, HN doesn't support markdown
  - Terretta 2y ago
    > 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.
    - PurpleRamen 2y ago
      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.
      - Terretta 2y ago
        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.
        rmbyrro 2y ago
        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 ^?
        Terretta 2y ago
        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-supported-in-markdown-fields/ https://github.blog/changelog/2021-09-30-footnotes-now-suppo...
    - rmbyrro 2y ago
      Following that logic, wouldn't HN be a runtime for anything written, from assembly to Python? Which sounds... not quite right?

willchen 2y ago

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/ 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 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/ 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 2y ago
fyi, HN doesn't support markdown
- Terretta 2y ago
  > 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.
  - PurpleRamen 2y ago
    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.
    - Terretta 2y ago
      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.
      - rmbyrro 2y ago
        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 ^?
        Terretta 2y ago
        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-supported-in-markdown-fields/ https://github.blog/changelog/2021-09-30-footnotes-now-suppo...
  - rmbyrro 2y ago
    Following that logic, wouldn't HN be a runtime for anything written, from assembly to Python? Which sounds... not quite right?