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 2 days ago [-]
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 2 days ago [-]
That book is amazing! An absolute gem showing a wonderful way to think about web programming.
> 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 2 days ago [-]
> 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 2 days ago [-]
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 2 days ago [-]
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.
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 2 days ago [-]
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 2 days ago [-]
> 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 2 days ago [-]
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
enzojean 1 days ago [-]
The goal on MonsterUI is just to make creating UI in fasthtml easier. Sometimes that means using HTML in a 1:1 mapping. If HTML does something great, it just uses that directly as you see with `Table` and implements helpers like `TableFromDicts`.
But sometimes it means syncing themes between frameworks. Sometimes it means server side markdown rendering. Sometimes that means integrations with 3rd part APIs like dice bear and picsum. And sometimes it means high higher level components such the `NavBar` component.
Totally fine if that's not to your taste, but there's nothing being misrepresented in the article AFAICT
enzojean 1 days ago [-]
Sure, there's stuff like that. But there's also stuff MonsterUI creates itself that is higher level, such as navbars which are not 1:1 mapping and is higher level.
It has a lot of direct translation, and a lot of other stuff too like functions that integrate with external APIs and server side markdown rendering and theme syncing between lots of different libraries (5 listed on the main page).
robertlagrant 2 days ago [-]
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 2 days ago [-]
So exactly the same level as HTML already does? That seems like interpreting their words so charitably it no longer makes sense.
erikgaas 2 days ago [-]
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 2 days ago [-]
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 2 days ago [-]
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.
mushufasa 2 days ago [-]
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.
jph00 2 days ago [-]
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.
curiousgal 2 days ago [-]
What roadblocks did you run into with Dash that kept you from using it in prod?
pacifika 2 days ago [-]
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.
erikgaas 2 days ago [-]
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 2 days ago [-]
Appreciate the lengthy reply!
ddanieltan 2 days ago [-]
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 2 days ago [-]
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 2 days ago [-]
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 2 days ago [-]
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.
AsthmaBoy 1 days ago [-]
Back in the day, around 1998/1999, Oracle had tools to develop Web-applications served directly from the database.
To produce HTML one would use a variety of PL/SQL functions, one function for each HTML tag that was available at the time.
The result was that each time I had to correct a spelling error, or change a portion of the page, I had find in the code where the change was to be applied, change the code, recompile the package, and then restart the service to have the changes come into effect.
Combine it with the fact that the code written was always much more verbose that writing straigth HTML, it got really old, really fast.
In the end, I created a micro-CMS where I put the HTML code as snippets in the database that I then combined in PL/SQL to form a page that could be served to a browser.
Changes appeared on the fly as I updated the HTML snippets, and the service had no downtime due to restarts.
Not long after, we moved to using Zope to develop more advaced solutions, but thats another story.
Now, this was a long time and 2 jobs ago :), but I am curious as to why in 2025, one would prefer to go to return these types of solutions.
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.
vFunct 2 days ago [-]
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!
photios 2 days ago [-]
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.
daelon 1 days ago [-]
Nicegui is fantastic, I've been using it professionally for 3-4 years now.
I've also written a vscode extension to support some of the nicegui workflows, just search "nicegui" in the extension marketplace.
vFunct 2 days ago [-]
Nice. This looks to be in the direction of where I was going. Will give it a try.
daelon 1 days ago [-]
If you need any help getting started feel free to hit me up on discord @ this username or the email in my bio.
(I'm a huge nicegui fan + contributor + I build tools and libraries for it)
> Combining HTMX with raku Air, Red and Cro so that you can just build websites the right way™.
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 2 days ago [-]
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.
kissgyorgy 2 days ago [-]
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.
danpalmer 2 days ago [-]
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.
anentropic 2 days ago [-]
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
erikgaas 2 days ago [-]
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.
nodesocket 2 days ago [-]
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.
collyw 2 days ago [-]
For some reason simplicity is out of fashion these days.
dcreater 2 days ago [-]
What's the development model behind this? Is it open source? How is answer.ai funded?
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.
I can see hypermedia future -- it's lightweight iframes all the way down ;)
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.
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.
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.
https://github.com/AnswerDotAI/MonsterUI/blob/main/monsterui...
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.
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.
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.
It seems to indeed be a HTML template engine based on Python.
Also, please don't boil your blood
But sometimes it means syncing themes between frameworks. Sometimes it means server side markdown rendering. Sometimes that means integrations with 3rd part APIs like dice bear and picsum. And sometimes it means high higher level components such the `NavBar` component.
Totally fine if that's not to your taste, but there's nothing being misrepresented in the article AFAICT
It has a lot of direct translation, and a lot of other stuff too like functions that integrate with external APIs and server side markdown rendering and theme syncing between lots of different libraries (5 listed on the main page).
I guess, having python objects makes things easier than handling html strings.
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.
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.
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.
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
I personally like to stay with normal HTML and FrankenUI instead FastHTML instead of MonsterUI tho.
To produce HTML one would use a variety of PL/SQL functions, one function for each HTML tag that was available at the time.
The result was that each time I had to correct a spelling error, or change a portion of the page, I had find in the code where the change was to be applied, change the code, recompile the package, and then restart the service to have the changes come into effect.
Combine it with the fact that the code written was always much more verbose that writing straigth HTML, it got really old, really fast.
In the end, I created a micro-CMS where I put the HTML code as snippets in the database that I then combined in PL/SQL to form a page that could be served to a browser.
Changes appeared on the fly as I updated the HTML snippets, and the service had no downtime due to restarts.
Not long after, we moved to using Zope to develop more advaced solutions, but thats another story.
Now, this was a long time and 2 jobs ago :), but I am curious as to why in 2025, one would prefer to go to return these types of solutions.
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.
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!
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.
I've also written a vscode extension to support some of the nicegui workflows, just search "nicegui" in the extension marketplace.
(I'm a huge nicegui fan + contributor + I build tools and libraries for it)
bad news => your gonna have to learn raku :-)
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.
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.
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.
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
It's Apache 2.0.