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.
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
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))))
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...
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.
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.
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!
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.
- 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
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.
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'm a huge nicegui fan + contributor + I build tools and libraries for it)
I've also written a vscode extension to support some of the nicegui workflows, just search "nicegui" in the extension marketplace.
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 ;)
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
I guess, having python objects makes things easier than handling html strings.
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).
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.
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.
dcreater•1d ago
ammo1662•1d ago
It's Apache 2.0.