[gavmor]

Slick looking website, novel and relatively intuitive DSL, solid documentation!

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.

[CharlieDigital]

    > I would want to know: what are the Mizu ways of modularizing code to increase cohesion and decrease coupling?

Ostensibly exactly what you would do with JavaScript.

Write a class or function closure similar to Vue composables.

It's not really the framework or library's job of making your code more modular; that's your job by writing good code.

[gavmor]

Yes, I know that it's my job to write good code. What I'm wondering is how must I design modules to accommodate this framework?

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.

[szundi]

there are libraries/frameworks that make that practically hard though

[lowlighter]

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