Oh,I agree so much here. It was 2 years back when I had looked at SolidJS. It was a simple project and had Bootstrap for a couple of pages and instead of JQuery or Mithril, I put in SolidJS. Was stuck on few reactive issues. Ryan was so quick to help me and also explain few things which really helped me.
IMO the best thing about Mithril is that it doesn't have reactivity, much like Imba. This allows you to define state with pure vanilla objects and classes. Also that it includes an HTTP client and router in just 10kB.
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.
Interested as well, Mithril seems plenty fast for my use case. One area I believe I read about where VDOM/Mithril is faster is dealing with dynamic list data. E.g. you have a list of items you're rendering (probably keyed in Mithril), and you append a new one, it'll render faster with VDOM then solid because the diff process will be faster than whatever solid is doing.
Solid's diff algorithm generally is faster(or atleast very comparable) than Mithril's. We test very well in list benchmarks like: https://krausest.github.io/js-framework-benchmark/current.ht.... We are also fast at node creation using pre-compilation to prepare the nodes in a way that can be created more efficiently.
Interesting, thank you for the links and clarification. May need to revisit solid then! What about rendering things that aren't rendered by solid, like markdown rendering via commonmark? Also, Mithril streams is a huge part of my app, will I miss it with Solid?
Hey Solid's reactive system uses Signals which are different than streams but work in similar use cases. Streams are slightly more oriented to transformation than synchronization. Most stream libraries could be used with Solid with a bit of an adapter on the end to connect to the templates as they are a good tool for managing global state.
All that being said. If you are happy with Mithril stick with it. It sounds like it's done everything you needed. I have a lot of respect for it's minimalist approach and its author is one of the most insightful and helpful people I've come across since getting into JavaScript frameworks.
If you are interested in trying something different. Check out our tutorials on the site and see how you feel about it. It is a little bit different type of framework.
Comments
Oh,I agree so much here. It was 2 years back when I had looked at SolidJS. It was a simple project and had Bootstrap for a couple of pages and instead of JQuery or Mithril, I put in SolidJS. Was stuck on few reactive issues. Ryan was so quick to help me and also explain few things which really helped me.
Interesting how does this compare to Mithril? I have yet find anything that is more performant than Mithril. Never heard of solid. How is it?
Mithril is reasonably fast, but there are plenty of faster options like Solid, Inferno, Preact, or Svelte.
https://krausest.github.io/js-framework-benchmark/current.ht...
IMO the best thing about Mithril is that it doesn't have reactivity, much like Imba. This allows you to define state with pure vanilla objects and classes. Also that it includes an HTTP client and router in just 10kB.
It's really verbose though compared to Svelte.
[Mithril.js author here]
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>
Thank you for stating that. Seems like Mithril isn't just fast for processor, rather it is a fast for mental processing.
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.
Hey Leo
I agree with all your points, of course. I don't think I ever stated that Mithril was slow or verbose in an absolute sense.
Interested as well, Mithril seems plenty fast for my use case. One area I believe I read about where VDOM/Mithril is faster is dealing with dynamic list data. E.g. you have a list of items you're rendering (probably keyed in Mithril), and you append a new one, it'll render faster with VDOM then solid because the diff process will be faster than whatever solid is doing.
Solid's diff algorithm generally is faster(or atleast very comparable) than Mithril's. We test very well in list benchmarks like: https://krausest.github.io/js-framework-benchmark/current.ht.... We are also fast at node creation using pre-compilation to prepare the nodes in a way that can be created more efficiently.
Interesting, thank you for the links and clarification. May need to revisit solid then! What about rendering things that aren't rendered by solid, like markdown rendering via commonmark? Also, Mithril streams is a huge part of my app, will I miss it with Solid?
Hey Solid's reactive system uses Signals which are different than streams but work in similar use cases. Streams are slightly more oriented to transformation than synchronization. Most stream libraries could be used with Solid with a bit of an adapter on the end to connect to the templates as they are a good tool for managing global state.
All that being said. If you are happy with Mithril stick with it. It sounds like it's done everything you needed. I have a lot of respect for it's minimalist approach and its author is one of the most insightful and helpful people I've come across since getting into JavaScript frameworks.
If you are interested in trying something different. Check out our tutorials on the site and see how you feel about it. It is a little bit different type of framework.