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

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/

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).

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.

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.

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).