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 · 7h 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 · 6h 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.
erikgaas · 30m 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.
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 · 41s 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.
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.
aatd86 · 17m 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.
jph00 · 5h 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 · 5h 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.
robertlagrant · 5h 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 · 3h ago
So exactly the same level as HTML already does? That seems like interpreting their words so charitably it no longer makes sense.
pacifika · 8h 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.
ddanieltan · 8h 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 · 6h 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 · 2h 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 · 5h 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.
mushufasa · 12h 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 · 7h 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 · 10h ago
What roadblocks did you run into with Dash that kept you from using it in prod?
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.
kissgyorgy · 3h 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 · 11h 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.
nodesocket · 1h 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 · 4h ago
For some reason simplicity is out of fashion these days.
dcreater · 12h ago
What's the development model behind this? Is it open source? How is answer.ai funded?
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 · 6h 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.
> 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.
atparinas · 11h ago
Yeah I've seen this approach with Elm. And I will tell you that this going to be a shitty approach fast
TheTaytay · 11h ago
Can you please elaborate? (I’m serious - I don’t know Elm)
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.
https://github.com/AnswerDotAI/MonsterUI/blob/main/monsterui...
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.
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.
I guess, having python objects makes things easier than handling html strings.
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.
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.
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.
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.
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.
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.
It's Apache 2.0.
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.
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.