> I would want to know: what are the Mizu ways of modularizing code to increase cohesion and decrease coupling?
Write a class or function closure similar to Vue composables.
It's not really the framework or libraries job of making you code more modular; that's your job by writing good code.
I guess what's not immediately clear to me is what's in scope for eg eval. I'll have to dig into the docs more than I have.
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
Parsing the playground demo was a fun scavenger hunt! Too fun... it took me several minutes to find `(coins += income)` at the line break. For me, it's difficult to scan for "code" that's in-lined as strings. That <progress/> eval, especially, is a doozy!
> Use this [eval] directive sparingly, prefer alternative directives for better maintainability and security. This directive is intended for edge cases.
Oh, and yet *eval is the heart and soul of the demo? In fact, it looks like the principal action--creating buildings--is performed by... the progress bar? That's low-cohesion and high-coupling if I've ever seen it.
I would want to know: what are the Mizu ways of modularizing code to increase cohesion and decrease coupling?
Anyways, thanks for sharing and congrats on launching.