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.
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 ;)
> 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.
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.
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.
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.
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.
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.
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
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).
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/
No, that's not what I mean. I mean "lower level" might be something like an "input" element - not nested; just a single element. Whereas a table might be considered higher-level: it is made of sub-elements.
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).
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.
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.
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.
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.
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
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.
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.
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.
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.
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!
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.
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.
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.
Suppose you need a template that renders some component inside a <div> tag. Now suppose you need to allow the template user to pass in any attributes they want into the <div> tag, but you need to make sure that when it is finally rendered, one of its CSS classes must be `dropdown`.
Eg, suppose the user passes in the following attributes to the div:
<div id=foo style=color:red class=my-component>
You need to make sure that the final rendered version is:
I'm most familiar with Django templates and Jinja2, and both of those provide template functions, filters, and/or various forms of control through which you can build up these sorts of abstractions.
I'd probably define a partial template for this dropdown as something like..
If you wanted more control over, say, the colours, you could just use an enum in your language of choice and provide a rendering function that turns it into the string `color:{{colour}};`, so that you retain some safety. You could do similar things with classes perhaps, keeping that as a list of strings and enforcing no whitespace or other separators in the text classes, then rendering to a whitespace separated string.
I feel like I should emphasize some of the text in my original question: 'Now suppose you need to allow the template user to pass in ANY attributes they want into the <div> tag, BUT you need to make sure that when it is finally rendered, one of its CSS classes MUST be `dropdown`.'
Fortunately, a Jinja guru in another channel showed me how to do it using a macro:
This pulls out the `class` attribute's value using the keyword argument and lets me render ALL the other passed-in attributes using the `kwargs` special variable. So, problem solved, with some abstraction, you're right.
BUT, for this `<combo-box>` custom element I also need to pass in multiple 'slots' ie children elements to inject inside various parts of the final rendered component. With HTML generation functions and values, this is relatively easy. With a template, it's possible but very unintuitive and ugly-looking, unfortunately!
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
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.
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.
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.
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 ;)
That book is amazing! An absolute gem showing a wonderful way to think about web programming.
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.
> 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.
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.
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...
It kinda looks like SwiftUI
> 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.
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.
> 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.
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
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
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).
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".
So exactly the same level as HTML already does? That seems like interpreting their words so charitably it no longer makes sense.
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/
No, that's not what I mean. I mean "lower level" might be something like an "input" element - not nested; just a single element. Whereas a table might be considered higher-level: it is made of sub-elements.
That was how I interpreted it.
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).
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.
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.
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.
What roadblocks did you run into with Dash that kept you from using it in prod?
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.
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.
Appreciate the lengthy reply!
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
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.
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.
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.
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.
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.
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!
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.
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.
Nice. This looks to be in the direction of where I was going. Will give it a try.
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)
good news => https://harcstack.org does this
bad news => your gonna have to learn raku :-)
> 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.
to expand on this (and yes the "claim" is intentionally tongue in cheek)
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.
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.
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.
Suppose you need a template that renders some component inside a <div> tag. Now suppose you need to allow the template user to pass in any attributes they want into the <div> tag, but you need to make sure that when it is finally rendered, one of its CSS classes must be `dropdown`.
Eg, suppose the user passes in the following attributes to the div:
You need to make sure that the final rendered version is: How do you do that?With abstraction, like in anything else.
I'm most familiar with Django templates and Jinja2, and both of those provide template functions, filters, and/or various forms of control through which you can build up these sorts of abstractions.
I'd probably define a partial template for this dropdown as something like..
If you wanted more control over, say, the colours, you could just use an enum in your language of choice and provide a rendering function that turns it into the string `color:{{colour}};`, so that you retain some safety. You could do similar things with classes perhaps, keeping that as a list of strings and enforcing no whitespace or other separators in the text classes, then rendering to a whitespace separated string.I feel like I should emphasize some of the text in my original question: 'Now suppose you need to allow the template user to pass in ANY attributes they want into the <div> tag, BUT you need to make sure that when it is finally rendered, one of its CSS classes MUST be `dropdown`.'
Fortunately, a Jinja guru in another channel showed me how to do it using a macro:
This pulls out the `class` attribute's value using the keyword argument and lets me render ALL the other passed-in attributes using the `kwargs` special variable. So, problem solved, with some abstraction, you're right.BUT, for this `<combo-box>` custom element I also need to pass in multiple 'slots' ie children elements to inject inside various parts of the final rendered component. With HTML generation functions and values, this is relatively easy. With a template, it's possible but very unintuitive and ugly-looking, unfortunately!
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
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.
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.
For some reason simplicity is out of fashion these days.
What's the development model behind this? Is it open source? How is answer.ai funded?
https://github.com/AnswerDotAI/MonsterUI/blob/main/LICENSE
It's Apache 2.0.
Yeah I've seen this approach with Elm. And I will tell you that this going to be a shitty approach fast
Elm is widely considered to be a really well-designed language for web development.
Can you please elaborate? (I’m serious - I don’t know Elm)
[dead]