I like the focus on simplicity, but I really wish frontend frameworks and libraries would stop abusing HTML.
Markup should only contain content and presentation. If it needs to be templated, then that's best done using a separate syntax.
If we need functionality, then that's the domain of JavaScript and programming languages.
We learned the importance of semantic HTML decades ago when we stopped using style elements and left this exclusively to CSS.
Separation of concerns is important. Yet modern frameworks insist on blurring these lines for some reason, and we end up with bastardized syntax, writing JS inline in attribute values, and cramming dozens of utility classes to style a single element (Tailwind is an abomination).
I don't mind frameworks that embrace components while keeping this separation clear. I think Svelte does a pretty good job at that, or at least it does a good job at hiding the magic it does to achieve this illusion from the developer. But from my limited exposure to Vue, React and Angular, these are not frameworks we should take inspiration from, and mizu looks even more jarring than those.
What did React do wrong? None of the custom props are rendered into the DOM. They had one quirk in the early days where they used HTML comments to keep track of things, but even that they removed.
Like I said, my experience with frontend frameworks/libraries is limited, so I could be wrong. I last used React nearly a decade ago, Svelte a couple of years ago, and Vue quite recently. Vue does seem like the worst offender in what I'm talking about, with the `v-if`/`v-else` shenanigans. And Mizu being mostly inspired by Vue takes this a step further.
My issue is not whether the custom props are rendered into the DOM, but about the developer experience. Svelte, for example, has separate templating syntax and generally tries to keep things isolated, even if it's ultimately all compiled to JS.
We decided to move away because PHP, JSP, etc was a mess with SQL codes and all other kind of form validation,etc code embedded into the pages together with CSS,etc. Yes it was a mess.
However, IMHO people have gone overboard with layering in so many places creating spaghetti projects that makes troubleshooting feel like goto riddled Basic of old.
In my view Vue's v-if / v-for / v-else is solidly for binding the viewmodel semantics, trying to separate it would require adding id's or some other way of connecting data to view production for no extra reason other than to specify that a list should be duplicated elements?
Wrote a small Vue page/app recently and this pragmatism really helped keep is small yet quite clean, HTML(with some small pieces of Vue markup), CSS and JS in each place. Would the project need to grow it'd be fairly easy to separate parts out into components but there wasn't even a need due to the small size.
React doesn't have any of that v-if/v-else crap, and it's one of the reasons I gravitated towards it. I don't like the fake attributes because it feels like an abuse of HTML, a risk if there's ever a collision because something was added to the living standard, and also, and this is mind-boggling bad to me, at least in the early days of Angular you could actually see the unparsed templating garbage on the page before the library kicked in and re-rendered.
The DX on React is quite nice. You had to do a bit of extra stuff to squeeze out a bit more performance by memoing stuff, but that's finally supposed to be fixed in React 19. And it's not like that perf was free if you did everything by hand anyway, that just required you to handroll clever batch DOM updates.
Can you talk about why separation of concerns is useful? I like it too, but I have a hard time trying to articulate why I prefer it over keeping everything in the same file. I've started working in a project that uses react and tailwind, and I've gotten pretty comfortable, but (ideological purity aside) it just isn't very enjoyable to use.
It's the contextual clarity for me. If I want to change the content, I can keep a specific syntax in mind and focus only on that. Same for JavaScript and CSS. I don't have to think about all of these things at once, but only at the boundaries where they interact with each other. Every component has a separate responsibility and they're composed in a specific way, but keeping them separate allows you to reason about them easier. This is similar to the Single Responsibility Principle.
Specialization is another aspect. Take this example from the mizu docs:
<div %http="https://example.com">
That is supposed to make a `fetch()` call. OK, great, so how do I make a POST request? Oh, with a `.post` "modifier". OK, great, so how do I specify the body? Oh, with a `%body` directive. OK, great, but what if I want to use a different encoding than the ones provided by the library? How about binary data? How about sending a specific header based on a condition, or interpreting the response in a specific way?
There are thousands of these questions and possible limitations and pitfalls that just wouldn't exist if the library didn't try to reinvent JavaScript in HTML. Just use the right tool for the job that is already specialized for what you're trying to do, and your task will be much easier.
BTW, I don't mind having components that contain JS, CSS and HTML in the same file. Svelte does this and I enjoyed using it. My problem is when these are mixed, or when CSS is entirely abandoned in favor of thousands of micro utility classes like Tailwind does.
Markup should only contain content and presentation. If it needs to be templated, then that's best done using a separate syntax.
If we need functionality, then that's the domain of JavaScript and programming languages.
We learned the importance of semantic HTML decades ago when we stopped using style elements and left this exclusively to CSS.
Separation of concerns is important. Yet modern frameworks insist on blurring these lines for some reason, and we end up with bastardized syntax, writing JS inline in attribute values, and cramming dozens of utility classes to style a single element (Tailwind is an abomination).
I don't mind frameworks that embrace components while keeping this separation clear. I think Svelte does a pretty good job at that, or at least it does a good job at hiding the magic it does to achieve this illusion from the developer. But from my limited exposure to Vue, React and Angular, these are not frameworks we should take inspiration from, and mizu looks even more jarring than those.