FYI, the krausest benchmark is known among framework authors to be not very good (it weighs some aspects much more heavily than others and has been gamed by various toy-ish "frameworks" that aren't all that practical in real life).
With that said, people obviously use React and even Ember (which are on the slower side of the krausest rankings) out in the wild and they're generally fine frameworks: asciinema-style "render-a-huge-grid-at-60fps" is very much a niche use case that 99.9% of people don't have.
I think the most accurate way to describe Mithril.js is that it aims to be a "get-out-of-your-way" sort of tool, in the sense that if things go wonky, you can generally reason about the low level reason as to why that is the case. For example, in Mithril.js, `render` is not just a first-class concept but an explicit API. So if you ever run into an issue where the template doesn't update for whatever reason, you can intuitively infer exactly what to do to unblock yourself. No need to reason about stale closures when debugging useEffect, observable/signal composition, or similarly complicated mental models. Reactivity, specifically, is great for squeezing performance from needle-in-the-haystack sort of updates when you have humongous haystacks, but it does also have caveats: if Svelte ever doesn't update the template for some reason, the mental model required to understand reactivity membership graphs and reactive bindings and where the compiler has jurisdiction and all that jazz are quite a bit more complicated than "ok fine, just slap a render call in this library's event handler".
The thing you said about vanilla objects follows from those principles: as a JS person, you know how objects work so you're never going to run into cognitive dissonance about the semantics of your primitives.
The verbosity thing I think is more a testament to Svelte being terse than anything else. Mithril.js isn't really verbose compared to other frameworks, IMHO.
I always say Mithril is a sushi chef knife. It's wonderful if you know what you're doing, but you can cut yourself badly if you don't.
In more popular frameworks like React, Vue, and Angular, there are multiple tools that give you a structure. In Mithril you're free to do whatever you want.
Personally, I love that freedom. It's also one of the reasons I love Svelte, since it tends to get out of the way.
FYI, the krausest benchmark is known among framework authors to be not very good (it weighs some aspects much more heavily than others and has been gamed by various toy-ish "frameworks" that aren't all that practical in real life).
With that said, people obviously use React and even Ember (which are on the slower side of the krausest rankings) out in the wild and they're generally fine frameworks: asciinema-style "render-a-huge-grid-at-60fps" is very much a niche use case that 99.9% of people don't have.
I think the most accurate way to describe Mithril.js is that it aims to be a "get-out-of-your-way" sort of tool, in the sense that if things go wonky, you can generally reason about the low level reason as to why that is the case. For example, in Mithril.js, `render` is not just a first-class concept but an explicit API. So if you ever run into an issue where the template doesn't update for whatever reason, you can intuitively infer exactly what to do to unblock yourself. No need to reason about stale closures when debugging useEffect, observable/signal composition, or similarly complicated mental models. Reactivity, specifically, is great for squeezing performance from needle-in-the-haystack sort of updates when you have humongous haystacks, but it does also have caveats: if Svelte ever doesn't update the template for some reason, the mental model required to understand reactivity membership graphs and reactive bindings and where the compiler has jurisdiction and all that jazz are quite a bit more complicated than "ok fine, just slap a render call in this library's event handler".
The thing you said about vanilla objects follows from those principles: as a JS person, you know how objects work so you're never going to run into cognitive dissonance about the semantics of your primitives.
The verbosity thing I think is more a testament to Svelte being terse than anything else. Mithril.js isn't really verbose compared to other frameworks, IMHO.
</two-cents>