[HN Gopher] MonsterUI: Python library for building front end UIs...
___________________________________________________________________
MonsterUI: Python library for building front end UIs quickly in
FastHTML apps
Author : indigodaddy
Score : 134 points
Date : 2025-06-02 20:41 UTC (1 days ago)
(HTM) web link (www.answer.ai)
(TXT) w3m dump (www.answer.ai)
| dcreater wrote:
| What's the development model behind this? Is it open source? How
| is answer.ai funded?
| ammo1662 wrote:
| https://github.com/AnswerDotAI/MonsterUI/blob/main/LICENSE
|
| It's Apache 2.0.
| mushufasa wrote:
| On the one hand I am the target audience for this: someone who
| wants to focus on data and have the frontend "solved" for me.
|
| On the other hand, I have been burned by every similar framework
| I've tried (e.g. Dash by plotly, many others) when I *need* to
| tweak one small thing in the frontend, and simply can't because
| of the way the framework functions. In which case, I have had to
| rewrite the feature from scratch. So I have found these tools
| okay for internal tools or proof-of-concept stage, but inadequate
| for real applications with real users where you need to quickly
| iterate on feedback in directions you cannot predict in advance.
| curiousgal wrote:
| What roadblocks did you run into with Dash that kept you from
| using it in prod?
| jph00 wrote:
| This isn't that kind of tool at all -- it's quite the opposite
| actually. It's a very thin layer on HTTP and HTML. MonsterUI
| uses tailwind, and you can directly use tailwind everywhere
| yourself.
| acbart wrote:
| This looks a lot like the approach we use in my pedagogical
| library Drafter: https://drafter-
| edu.github.io/drafter/quickstart/quickstart....
|
| Route functions consume a State object (arbitrarily whatever type
| you want) and return a Page object, which has the new State and a
| list of component objects, which are dataclasses that can be
| serialized to strings of HTML. We provide functions for Button,
| CheckBox, BulletedList, etc.
|
| So far, it's been pretty effective for our CS1 course to let
| students develop nicely decomposed web applications in just
| Python. We can deploy through Github Pages thanks to our custom
| Skulpt bindings, and it even makes unit testing quite easy.
| atparinas wrote:
| Yeah I've seen this approach with Elm. And I will tell you that
| this going to be a shitty approach fast
| TheTaytay wrote:
| Can you please elaborate? (I'm serious - I don't know Elm)
| danpalmer wrote:
| Why use this over a templating language? I've always found it
| much easier to write basically-just-html with a few placeholders,
| and then render in Python or whatever else.
| collyw wrote:
| For some reason simplicity is out of fashion these days.
| nodesocket wrote:
| Agree, I'm building a Flask based app and find using templates
| works well. Sure I have to know tailwind classes, but it's not
| that hard to grok and putting the view layer into python seems
| like an unnecessary combination.
| erikgaas wrote:
| Templating is great. I think I prefer fasthtml because I can
| apply all of the python tricks I know. Python arguments seem to
| work very well. Having a list of dom elements and splatting
| them into another component would feel very similar to
| templating.
| anentropic wrote:
| I find the thing that is awkward with templates in a large
| project is there is only an implicit link between the template
| and the code that populates it
|
| So there is no type safety or IDE help if you pass an invalid
| context from python to be rendered, i.e. that doesn't match var
| names in the template
|
| So... I find these "html in python" libs kind of ugly in the
| Python code side but I definitely see the advantage
|
| And then the idea that you can build 'components' as python
| functions
|
| They are basically doing JSX but without benefit of the custom
| syntax
| johnfn wrote:
| icons = ("mail", "linkedin", "github") return Card(
| DivLAligned( DiceBearAvatar(name, h=24, w=24),
| Div(H3(name), P(role))), footer=DivFullySpaced(
| DivHStacked(UkIcon("map-pin", height=16), P(location)),
| DivHStacked(*(UkIconLink(icon, height=16) for icon in icons))))
|
| > I specified the entire layout, font sizing, icons, and avatar
| using only Python. I controlled everything without needing
| special flexbox or CSS class knowledge.
|
| The provided Python looks even more difficult to understand than
| typical HTML/CSS. DivLAligned? DivFullySpaced? What if I only
| want it partially spaced? DivHStacked? Oh no... Flex and Tailwind
| already do this, it's trivial, and crucially online documentation
| is plentiful and AI understands it just fine. This seems to be
| reinventing Tailwind with different names.
| drdaeman wrote:
| > This seems to be reinventing Tailwind
|
| I would rather think of this as Python bindings to
| HTML+Tailwind with a bunch of utility shortcuts. E.g.
| `DivFullySpaced(...)` is simply a convenience shortcut
| `Div(cls=("flex","justify-between","items-
| center","space-y-4"))(...)`, which turn becomes `<div
| class="flex justify-between items-center space-y-4">...</div>`
| (there are a few more levels of indirection there, but the
| source is easy to navigate). They don't reinvent Tailwind, they
| build a Python library on top of it.
|
| Or it can be thought as a DSL translating into another DSL.
| That's also a pretty common thing out there, and a perfectly
| valid idea if there's some need for a different syntax, and/or
| some issue why the original language is not a good fit.
| pzo wrote:
| For some one who actually did mostly native mobile dev in
| last decade and haven't touched web since react this still
| looks kind of weird to me. It feel like glueing into the name
| SwiftUI and HTML and just feel very awkward to me. Can't
| explain but I feel a little repellent by such names - would
| prefer either trying to sick convention more to SwifUI or
| Flutter or Compose or stick to more HTML/Tailwind convention.
|
| On the one hand I'm definitely more comfortable with python
| and wish I could use it fullstack on frontend as well rather
| than JS/CSS but on the other hand not sure if I like such
| abstraction.
| erikgaas wrote:
| If you want a custom Div you can just define a function for it.
| The definition of DivLAligned is just for convenience. You can
| see its implementation is fairly trivial.
|
| https://github.com/AnswerDotAI/MonsterUI/blob/main/monsterui...
| cvwright wrote:
| It kinda looks like SwiftUI
| pacifika wrote:
| So this is an abstraction over FastHTML which is an abstraction
| over HTMX, Starlette, HTML, and HTTP. HTMX is an abstraction over
| JS. Starlette is a micro web framework for Python.
|
| So this is the stack you need to know in the real world when
| debugging an application made with it.
|
| You could say that generative AI is an abstraction over all that.
| Or in other words I'm saying that's a lot of edge cases to debug.
| Sorry to be sceptical.
| ddanieltan wrote:
| I'm starting to come around to this opinion. I was originally
| quite bullish on FastHTML but I am starting to feel a little
| bit lost with all the abstraction and indirection.
|
| I was initially attracted by the idea that I could replace the
| traditional HTML, CSS, Javascript , Python (backend) project
| entirely in Python, but it's starting to feel like the original
| mix of languages might have been the simplest option all along,
| particularly with GenAI tools
| rasmus1610 wrote:
| Actually the abstractions are much thinner than with
| something like NextJS imo. It all comes down to what you are
| comfortable with. If you learned web dev in the React era,
| this approach feels very odd, but if you come from something
| like Ruby on Rails, this actually quite intuitive and not a
| lot of abstraction (see Jeremy's comment in this thread).
|
| I personally like to stay with normal HTML and FrankenUI
| instead FastHTML instead of MonsterUI tho.
| mark_l_watson wrote:
| While I sort of agree with your and the parent post (I have
| always liked Flask with simple Janga templates) I just put a
| task on my personal schedule to try a project with FastHTML
| and MonsterUI. A long time ago I found studying JH's
| abstractions for deep learning very useful, even though I did
| all my real work in TensorFlow. It will probably be the same
| with FastHTML and MonsterUI: I am likely to just use it for
| one fun project, but I am sure to learn a few things. And, I
| might use it long term. A no-lose situation because I am
| retired and my time is my own.
| robertlagrant wrote:
| It does feel like just having a base library that renders HTML
| for you might be quite a good building block for all these
| libraries. Sorting that layer alone out would be quite useful.
| erikgaas wrote:
| Imo they are abstractions but not quite as bad as you / myself
| / everyone else is used to. Monsterui is moreso an extension of
| fasthtml. It doesn't hide any of the underlying API. Same with
| fasthtml with respect to htmx.
|
| Htmx also may leverage js but it is meant to patch http
| functionality based on how http "should" function. See the
| hypermedia book for that discussion. You don't need to really
| know that it used js. You don't interact with it via js, just
| the dom.
|
| As for starlette I'm not currently aware of any server stack
| that doesn't have some convenience library for that.
|
| My point is that the frameworks which makes us very pessimistic
| every time a new approach comes out frequently try to make
| something really easy but once you get far enough you realize
| that you have to break their abstractions. And create hacks
| just to access the lower level implementation. I think you'll
| find something like this very different. When you need control
| you'll find everything to be much easier to decompose such that
| you can operate at your needed level of abstraction.
| pacifika wrote:
| Appreciate the lengthy reply!
| vFunct wrote:
| I'm really hoping someone comes up with a pure Python declarative
| HTML component/CSS/JS framework, sorta like SwiftUI for the web.
| I tried to make something a few years ago but ran out of time.
|
| Anyone want to vibe code that? I could use it for Django, instead
| of the horrible Django template
| language/HTMX/Tailwind/DaisyUI/etc..
|
| I never want to write HTML/CSS/JS ever again. Give me Python UI
| components!
| librasteve wrote:
| good news => https://harcstack.org does this
|
| bad news => your gonna have to learn raku :-)
| lioeters wrote:
| > Combining HTMX with raku Air, Red and Cro so that you can
| just build websites the right way(tm).
|
| Web-related software development is hilarious in its
| creativity and absurdity. I'm sure it works, and well-tested
| too, but do we really need all those libraries and languages
| with cute magical names? I suppose it's smart people having
| fun while hopefully getting paid.
| librasteve wrote:
| to expand on this (and yes the "claim" is intentionally
| tongue in cheek) - HTMX is established as
| an antidote to React and similar overly complex tools
| - it has started a renaissance in server side web design
| options - raku (HARC), Go (GOTHH), Python (FastHTML),
| Rust (HARM) etc - HARC builds on the
| declarative/functional approach of ElmLang - Cro (web
| stack) and Red (Object Relational Mapper) are the raku
| "goto" modules
|
| HARC is a very serious attempt to refresh the web
| development experience for hard core coders that embraces
| LOB and eschews templates with constrained semantics.
|
| raku is well suited for this, but you do need to learn it.
|
| Do we need a better way? Perhaps we should stick with the
| lovely situation we already have.
| photios wrote:
| I'm not familiar with SwiftUI, but have you seen NiceGUI:
| https://nicegui.io/
|
| You define your UI in Python and the end result is a Vue/Quasar
| UI stylable with Tailwind (in case you want to poke at that)
| that is hosted as a FastAPI app.
| vFunct wrote:
| Nice. This looks to be in the direction of where I was going.
| Will give it a try.
| jph00 wrote:
| I'm the creator of FastHTML -- I see quite a few of the comments
| so far are about FastHTML, rather than MonsterUI, so I guess I
| should provide some background.
|
| FastHTML moves back closer to the foundations of the web. The
| functional components are a direct 1-1 mapping of m-expressions
| to HTML tags (i.e children are positional parameters, attributes
| are named parameters). There's nothing new to learn there if you
| know HTML already. I've been using functional components for web
| apps for >25 years, including building Fastmail with them -- they
| work very nicely for me at least, and are standard in most
| functional programming communities. I like being able to treat my
| components directly as plain objects directly in python
| (including using the python debugger, profiler, etc, and using
| IDE standard python navigation), rather than having to switch to
| a separate templating language with its own way of doing things.
|
| MonsterUI is mainly a FastHTML wrapper around FrankenUI -- a pure
| js/css/html version of shadcn. I like using native components
| like this, instead of needing special react/vue/svelte/etc
| framework libs. FastHTML's functional approach make server-
| rendered components feel a lot like jsx in react (jsx behind the
| scenes is a wrapper over a similar data structure to FastHTML's,
| but js doesn't natively provide the needed m-expression syntax,
| hence the need for jsx).
|
| For newer devs that never really learned native HTTP/HTML ways of
| developing for the web, and have lived in the react/nextjs/etc
| world, FastHTML will seem very odd. But for anyone that grew up
| with Perl, PHP, etc, writing plain server handlers that deliver
| HTML directly to the server, FastHTML will feel quite natural.
| They are two different approaches, each with their pros and cons.
| At Answer.AI we've written a lot of useful apps in FastHTML now,
| including SSE and websockets, rich client interactions, etc, and
| it's been working nicely for us.
| eidorb wrote:
| I'm about 1/3 through https://hypermedia.systems. It feels
| right intuitively. But I kinda left off about 10 years ago with
| Flask and maybe a JS chart lib. Great times!
|
| I can see hypermedia future -- it's lightweight iframes all the
| way down ;)
| jph00 wrote:
| That book is amazing! An absolute gem showing a wonderful way
| to think about web programming.
| boxed wrote:
| > Higher level components [like] tables
|
| But look at the code for a table:
| https://monsterui.answer.ai/api_ref/docs_tables
|
| It's just exactly the HTML but written weirdly in Python. This
| isn't higher level, this is the exact same abstraction level as
| HTML already gives you!
|
| I am so frustrated with this stuff. I developed an ACTUAL higher
| level abstraction for tables in iommi
| (https://docs.iommi.rocks/tables.html) and it boils my blood when
| people call this stuff "higher level". It's not. Not even close.
| jph00 wrote:
| But that's the point! It's just html!
|
| But since the direct 1:1 mapping to html returns a python
| object, you can build up rich component hierarchies using plain
| python, mapping to plain html. And thanks to MonsterUI it looks
| pretty good too.
|
| You seem to be arguing that more complexity, moving further
| from the foundations of the web, is a good thing. The fasthtml
| philosophy is the opposite -- sticking close to the
| fundamentals is good.
| boxed wrote:
| > But that's the point! It's just html!
|
| That's the point of FastHTML maybe, but the article linked
| says "higher level components" which is a lie. This is an
| enormous distinction, and not even close to subtle.
|
| > You seem to be arguing that more complexity, moving further
| from the foundations of the web, is a good thing.
|
| You use the word "complexity" in a weasel way.
|
| It's fine to not have higher levels of abstraction in your
| framework. It's not fine to lie and say you do when you do
| not.
| viralsink wrote:
| The link to documentation showing simple HTML does not take
| away from the statement that the library offers higher
| level components, or provides the base for creating higher
| level components.
|
| It seems to indeed be a HTML template engine based on
| Python.
|
| Also, please don't boil your blood
| robertlagrant wrote:
| I don't think they mean the same sort of "level" as you do when
| talking about higher level. I think they probably more mean
| "complex components".
| boxed wrote:
| So exactly the same level as HTML already does? That seems
| like interpreting their words so charitably it no longer
| makes sense.
| erikgaas wrote:
| There is no reason for the author to be misleading about
| Table as a "high level component". There are more than
| enough examples that fit your definition. Look at the code
| for dashboard and music and you will see plenty of
| abstractions on top of the html components.
| https://monsterui.answer.ai/music/
| threecheese wrote:
| You should always aim to interpret most charitably,
| especially wrt a demonstrated good actor. Or perhaps you
| have a personal bias I'm not aware of (no shade, it just
| occurred to me while typing).
| aatd86 wrote:
| it's not really weird. It's just some datastructures. And I've
| never coded in python.
|
| I guess, having python objects makes things easier than
| handling html strings.
| kissgyorgy wrote:
| I also made a component library which is more generic, can be
| used for ALL Python web frameworks:
| https://compone.kissgyorgy.me/
|
| Components can be mixed and matched, Bootstrap v5 components is
| already in the works.
|
| I already have a Storybook-like tool which can render and
| showcase such components.
___________________________________________________________________
(page generated 2025-06-03 23:01 UTC)