This is interesting, the code makes me want to euthanize myself, but it's cool to see.
replies(1):
I'm just amazed that saving 100kb or whatever could outweigh the other factors.
I re-evaluate most of them once in a while and there's a lot of looking alive but basically dead and bug-ridden ones. And some bugs are so trivial that it shows that no one uses them seriously.
Mithril is absolutely stable and mature compared to these other hyperscript-ish libs.
Who
Me. I want full control over my data and not outsource it to a lib that will dictate the shape of it. Mithril only does rendering cycles while being completely data-agnostic. It's basically react without its "functional" abracadabra.
I ran a relatively small web consultancy at the time and we were in the middle of trying to specialise in the new, more complex things people were starting to build on the web.
We had the potential to land a contract with what would be by far the biggest client we'd ever had. But they wanted us to test the water with us first by having us build a series of obnoxiously complex manufacturing cost calculators for one of their sales-focused web sites.
It was all complex rules and interdependent inputs/display values. And because it could all be hard coded it was the perfect candidate for a client-side only site (I don't think we even called them SPAs yet)
I remember thinking jQuery UI didn't feel like the right tool and React was super clunky back then so I reached for Mithril and had a great experience.
The declarative approach, automatic updates to the DOM etc that we take for granted now felt like magic back then. Being able to describe the data model/logic in a relatively abstract way and then watch as the UI changed in response was pretty cool.
I’d bet the customer’s CTO/tech lead took one look at the codebase and was instantly discouraged because some novel and unknown frontend framework was used.