lowlighter

Maybe it'd feel weird for a native speaker to have something named "Water", but it does sound cool.

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

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.

I'll keep this in mind for future iterations!

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

Thanks! It's always hard to find a nice balance between explaining your project and showing how it actually work

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

Thanks for catching this, I'll look into it!

Ok this made me laugh xD

Yeah I don't think this is meant to be used for a production environment. I wrotten this mostly to style my hobby projects effortlessly

Anyway more "professional contexts" probably have their own branding too, so the added value is probably negligeable in this case

Yes it's exactly as you guessed it

The hundreds of files in the repo are just for maintainability and organization, but in the end it'll result in a single file to include, although you can also individually select which part you want to include if you'd like

I actually love sakura, but I wanted something more complete like having syntax-highlighting styles out-of-the-box and still have some utilities classes.

The demo page is supposed to be the website itself which is intended as a documentation too (you also have a basic website previewer at the begining).

It definitely needs some more polish, but I wasn't expecting this being posted on HN this early

Yes this is exactly the goal of this project

Some people aren't specialized in front-end (or they just find it boring) so they're more the target audience. I did this because I wanted to avoid having to redo an UI each time I started a new hobby project

While there are customization options, it's really intended as just being an include without the need of changing anything else in your documents

Thanks for the constructive feedback!

To be honest I was kind of taken aback seeing this on HN because it was posted before I could do a show hn myself

I'm not a frontend dev nor a designer so it can be indeed apparent that I lack knowledge on color theory, accessibility concerns and other aspects that may seem obvious for other people. Probably hence the "artisanal" feel too.

I'll research more about the things you mentioned in the future. As for collaboration with a professional designer I'm open to receive advices, but I don't plan especially on hiring one as it's a side project. I don't think currently that professionals are the target audience for it, but I guess it'll definitely appeal more to hobbyist