We shipped a very major product (300 person company) on Mithril.js a few years back when React was young and Angular was the go-to in this space.
We had a fairly positive experience, but ran into enough problems here and there with vdom rendering bugs that we eventually decided to rewrite the entire product 4 years later in React.
Certainly, it did was it was supposed to very well, until we really pushed it to its limits with vdoms that were complex and mutating in real time. Then we broke it non deterministically and couldn't reliably reproduce the issues that we were having each time for a solid bug report. Couldn't really even reproduce them consistently in production, they would just happen in random places.
Mithril author here. Curious what version you were using. There have been some notable internal changes to the engine over the years.
The 1.0 release was a complete rewrite of the previous codebase, and included a very aggressive optimization inspired by inferno.js (called node recycling) that turned out to cause issues in some edge cases and didn't materialize significant enough performance benefits given the added internal complexity. I suspect that this is what was causing you grief.
Yeah we reported a few bugs over the years and many of them got fixed. We were using Mithril 0.x. We did get the product to a point where it was very stable, but there were patterns that we had to avoid (for example, at the time IIRC we had spooky bugs with children cycling between an element, a list of elements, or an empty array []).
In the end, the reason that we moved away from Mithril.js was that as a 300-person company, we just didn't have the resources to give it the attention that we felt we needed to give it (i.e. contribute) vs. the timeline that we needed for isolation and resolution.
Before we built our app in Mithril, I built a MVP prototype in Angular and the performance was so bad that the product was marked as "not plausible". Discovering Mithril.js was the only reason we decided to go through with the project. In some respects, the company owes its market-leading position to Mithril.js whilst its competitors are still crawling out of the dark ages of TTY and desktop thin clients
I have been using Mithril.js for a while and never ran into problems, but admittedly I only used it for small, personal project.
What I liked about Mithril was its simplicity: a clean API with a handful of methods but batteries-included at the same time, and very easy to learn, too!
Eventually I decided to write my own micro framework which borrows heavily from Mithril in terms of api design and approach (https://h3.js.org) -- basically, like Mithril, it comes with its own Virtual DOM implementation, hyperscript syntax (imho the best way to write a view, once you get used to it), a minimal router but also more obvious ways to manage local and global state.
Yeah, I am not even thinking about competing with React or other frameworks, as long as it works for me. I have learnt more building a micro framework from scratch about how single page application work than from using React or Angular and constantly checking stack overflow and other docs to make sure I was doing stuff "in the right way".
I would however be curious at what are the limits of such frameworks. Real-time dom updates... depends how complex I guess, and how fast. It would be nice to have a way to benchmark this properly...
Any chance you remember what those bugs resulted in? I’m dealing with the same scenario for work where I’m using Mithril and have been wondering if what I’m seeing is due to my usage or the library itself. I do love the library and its community but I’ve run into some crazy ui issues, especially when using keyed nodes, that I’ve never seen with the more mainstream vdom options I’ve worked with.
I've been out of the loop for a while, I'm getting back to it, and if you've discovered a keyed diff bug I'd love to hear about it.
Feel free to hop into the gitter chat (https://gitter.im/mithriljs/mithril.js) to explore the problem, or to file an issue if you're sure the bug is ours.
The point isn't that you can do web UI in Qt (you can, but it's on a canvas and very rough around the edges), but that web UI frameworks often struggle to achieve a lot of what is just a wave of the hand in desktop frameworks.
We had a fairly positive experience, but ran into enough problems here and there with vdom rendering bugs that we eventually decided to rewrite the entire product 4 years later in React.
Certainly, it did was it was supposed to very well, until we really pushed it to its limits with vdoms that were complex and mutating in real time. Then we broke it non deterministically and couldn't reliably reproduce the issues that we were having each time for a solid bug report. Couldn't really even reproduce them consistently in production, they would just happen in random places.