I appreciate the no-build-step approach. It’s refreshing to see a return to simplicity, even if it feels cyclical—similar libraries have come and gone, but that’s how the web evolves. As browsers continue to improve and embrace web standards, it makes sense to lean into tools that trend toward minimalism and simplicity. Great job!

I love that this lets you create custom elements! I think that's a big missing feature from HTMX (even though HTMX can already use custom elements).

I'm working on a somewhat similar system called Heximal. It focuses on adding full-fledged templating to the <template> element, and full declarative component definitions to HTML, plus some built-in custom elements like <h-var>, <h-out>, <h-scope>, <h-include>, and <h-fetch> that make HTML more of a declarative programming language.

A big difference from HTMX is that it doesn't rely on magic attributes, but instead adds full data-binding with rich expressions for any attribute or text content, and control flow, to <template>. And component definitions include defining properties, attributes, styles, etc.

These things are being proposed for HTML, so Heximal is somewhat of a polyfill for HTML from the future. Or it's a bit like Tangle or Curvenote.

https://github.com/elematic/heximal/

I love the information architecture of this site. You jump right in to demonstration code and a reference and only later the marketing text. So refreshing. I can see at a glance what the project is and what makes it different. Kudos!

Here is an alternative without the funky license

https://data-star.dev

Interesting license:

This project is dual-licensed.

You may use this project under the terms of the MIT License for non-commercial projects OR as long as you are sponsoring this project through GitHub sponsors with a monthly minimum donation of 1 (one) dollar using the link below:

    GitHub sponsors, Simon Lecoq: <https://github.com/sponsors/lowlighter>

You may use this project free of charge under the terms of the GNU Affero v3.

Via https://github.com/lowlighter/mizu?tab=readme-ov-file#-licen...

The documentation was a pretty interesting read until "AGPLv3".

This is AWESOME We need more of this kind of innovation and less React and Node bloat. Love the simplicity here, thank you.

EDIT: never mind the license killed it for me. Cool innovation but unusable with its AGPLv3 license.

Really cool work, congrats!

I built my own frontend framework for similar reasons: https://github.com/fresho-dev/mancha. It was meant to adress the lack of lightweight solutions that worked both on the frontend and the backend. The main goal was to start with client side rendering and, only if you reach the point where you need it, switch to server side rendering. It also includes a drop in replacement for TailwindCSS except it won't yell at you for doing everything client side.

What I really wanted was a better maintained version of PetiteVue. But that highlights another problem: I simply can't trust anyone in the frontend JavaScript ecosystem, I've been burned too many times. It took a while to get to the point of it being usable, but now I know no one can pull the rug from under me. I use only the most basic APIs possible, only 1-2 third party dependencies, and as little hacks as possible.

It still has a few warts here and there but I hope to be able to call it a 1.0 stable version soon enough.

Get it? Because mizu means water in Japanese?

Reminds me of hibiki html (now dead)

https://www.hibikihtml.com

And kind of like Imba:

https://imba.io

A related thread about half a year ago https://news.ycombinator.com/item?id=40455944

I actually really love this, and have been wanting something like this for a while. Excited to give it a try.

It reminds me of vue templates. I’d love to see some benchmarks comparing it with react jsx and vue/nuxt, both for server-side and client-side. Thanks!

Caught 1 typo and 1 broken link on the site in case you'd like to fix: https://triplechecker.com/s/477573/mizu.sh

The site is well organized and the information flows smoothly, nice job.

but what is the cons here???? anything you mention about the pros, there must be cost to make right??

after fast skimming it, I found its gonna be hard to separate concern when build interactive UI

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.

https://mavo.io is another similar idea

The licence seems messed up. You can opt to use an MIT licence, but only if you're noncommercial or you pay. The MIT licence explicitly states that the software is provided free of charge, and can be sublicensed, so anyone with an MIT copy, can give it away for free.

I wish it didn't require authors to practice doing the wrong thing (writing invalid HTML) for to use the tool.

Authors are free to either create any data-* attributes they wish for any purpose, so long as the custom attributes are prefixed with "data-".

Authors are also free to create any (valid) HTML custom element, and to invent custom attributes for those elements.

But this appears to require authors to write invalid HTML.

We've been down this road before many times.

On adoption things are simple and clean.

Then your product becomes more complicated and your requirements for data handling outgrow what a tool like mizu can offer.

Then you are facing a choice: Redo everything in a more scalable and expensive (as in dev training, qe needs) framework/library or stick with that you have?

Choose carefully.

> In summary, mizu.js is free for open-source and non-commercial projects, while a small contribution is required for commercial closed-source projects to support its development.

That's... weird.

I've evaluated front-end frameworks in the past and considered both free (open source and no cost) against commercial. I can't explain why, but the mandatory donation for commercial use just rubs me the wrong way.

(And don't get me wrong, I've published my own basic HTML templating library here: https://www.npmjs.com/package/pogon.html)

Perhaps I can explain it this way: If I'm doing a hobby/learning project, there's no obstacle to using Mizu. But, if I'm a rank-and-file employee, experimenting, setting up the $1 / month donation is actually a huge obstacle. It's not the cost, it's the actual act of handling money. Furthermore, Mizu will need a lot of paying customers for the monthly donations to actually pay for anything substantial.

Personally, I would think more carefully about how to derive income from Mizu.

Feels like knockoutjs, i recall using it 10 years ago. It was all so simple back then.

I've been using React templating lately, then you get a lot of cool features like Tailwind and can even use React for your email templates:

https://react.email/docs/introduction

It helps me ship faster when I use the same stack everywhere. I even ported my background task library to TypeScript so to keep the stack the same:

https://github.com/wakatime/wakaq-ts

I have a 60 LOC [bash script][1] to do something similar to my personal blog

[1]: https://github.com/alexandremcosta/alexandremcosta.github.io...

[dead]

[flagged]

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.