Yeah maybe I'll look into a simpler licensing as it may indeed be confusing and just drop the requirement, it's not like I really planned to make money with it anyways.
While I doubt this project will ever reach the popularity of projects such as docker, terraform, mondogb, wordpress, corejs, and many others, I'd like to avoid having issues that they encountered later due to their licensing.
Basically having companies that could afford to contribute and help maintainers but that choose to not do it just for pure greed, while keeping it free for everyone else that continue to make open project or just non-profit/personal use case.
As I'm no legal expert, the intention may not have been very clear in the wording though
Using qualified names is actually it good idea (similar to svg there could be a custom namespace for mizu)
It'll kind of solve the previous commenter concerns about with writing invalid html. While namespaces are more a xml thing, there are probably many benefits to this approach like querying all attributes from the namespace at once too.
Yeah the playground is intended to show many directives to display the capabilities, but I wouldn't recommend making complex apps entirely with the iife version. It's mostly intended for templating (like conditional, iterations, htmx-like op).
The ESM version is better suited for small dynamic apps as you can handle context in a better way, and define helper functions rather than declaring them in a html attribute. It makes the code more readable too and this how you'd be able to achieve a more cohesive app.
As for the eval, it's true the doc advertise against, but maybe I was a bit too harsh about it. The reasoning behind avoiding it is the same as "eval()" in js. It's kind of a "god mode" (like you could do *eval="this.remove()") and it may mess up your final rendering as some internal reference may not be properly cleared if you do niche stuff. If you know what you're doing there's no particular issue with it
I think rather the issue being new library popping up is more about choosing the right tool for the right project.
If you know that your project is going to be small-scaled (a MVP or POC, a blog, a UI for your home lab, a static website, etc.) then mizu and tools alike may be a good choice.
If you know that you eventually want to have thousands of customers, with hundreds of collaborators, then it might indeed be not the best fit. Going with a more "common" framework like the big name React and Vue is probably better.
Web dev nowadays offer a wide range of application, so everyone needs is different so a one-size-fits-all framework/library is almost impossible to achieve in my opinion
It's because it's mostly based on the vue syntax short hands (@ for event, # for slots and : for attribute bindings, :: was also proposed at a time for model in vue too but it was still being discussed last time i checked)
Rather than using a v- prefix like vue has, mizu uses *, but it's essentially the same.
All in all, I feel like it's still pretty close to what vue offers, at least when you plug it directly to your html page without passing by the component/composition way of writing vue.
I took a lot from vue (maybe more petite-vue at this point) and alpine to make mizu actually
But that's also related to another project of mine, matcha (which is a kind of tea) which is a semantic css stylesheet.
Both were designed as a mini-ecosystem, kind like how you would put tea in your water