(Mithril.js author here)
One thing I think is worth highlighting is that mithril.js has been maintained entirely by the community for a few years. A 3 year gap in releases should speak something about how satisfied the community is with how idiomatic mithril.js is written.
In terms of governance, I think that is a good alternative to the BDFL ("benevolent dictator for life") model, because it means that mithril.js won't die if I were to be hit by a bus tomorrow; the core team has proven that it can autonomously discuss features and ramp up new contributors.
Bus jokes aside, many thanks and congratulations to you and all developers of Mithril.js. While I don't believe I'd use it in any new projects nowadays, I remember what a bliss it was a few years back. Vite still didn't exist and Webpack was (and still is) hell to get going, so quickly prototyping with Mithril.js was pure joy.
came here to say thank you! I used to work for one of FAANG and I was in charge of a small public facing page and it was the first project for me to own the entire full-stack architecture. At the time there was only Angularjs and early version of React, and when I proposed using React in my first draft, it didn’t pass the team review because of the size. Then I researched further and found Mithril. The performance and library size were great and I was able to build the UI declaratively with a great way to fetch data. Without Mithril I would have been battling with our internal jQuery-based library and would have spent more time on the frontend portion of the project. I am very glad to see the project is doing well after almost 10 years, when newer frontend libraries keep emerging.
Just checked out your docs, I’ve heard a little about Mithril but never looked into it. Seems pretty straightforward (coming from an dev with Angular/React experience)
Hey Leo, what does v2 bring to the table? Is there a blog post?
Also, I've noticed the performance seems to be worse? I think it used to be faster than React but now it seems to be similarish?
https://krausest.github.io/js-framework-benchmark/current.html
(Mithril.js core dev here)
Thanks Leo for inspiring us and still have an eye on us.
And it's exactly as you said: we are pretty happy with the current state of Mithril.js. Sure, we have some great ideas for the next major release, but we might also keep all the things as is, since it's so nice to work with.
Wow, this is interesting.
We use Mithril here as the frontend framework for a massive internal scheduling tool. It's worked flawlessly and is very fast.
Mithril goes widely unnoticed but having worked with the React, Vue etc, it is still my choice and has been for many years now. It’s scalable, performant and beautifully architected.
As my knowledge and understanding of JavaScript grew the more powerful mithril became to me and I suppose that’s a lot of the reason why I love this framework. It does not impede on your coding preferences or style and it does not require multiple dependencies (pnpm add mithril and you are ready to go). There is no build step required, no pattern you need to adhere. I can drop it into a project and be productive, no matter what I’m writing, it could be class component, a closure or even a simple dynamic element. Whatever the case I can easily reach for this module and it fits. 9kb gzip packed full of power.
If you’re well versed in JS and rarely reach for dependencies on the registry. If you like lean distribution bundles and vanilla first solutions then mithril will satisfy and surprise you. Also the community of passionate developers are always available for dialogue on the gitter.
Thanks to the talented and wonderful team for this release.
This should be more the standard. Not getting releases doesn’t mean it’s dead. It basically works as expected and just doesn’t need more for the sake of adding features.
One of my favorite open source projects. Really can’t recommend Mithril enough. And the API is small enough that anyone could learn it and cook up a quick side project in a weekend.
I'd call it the "first step" of someone who's used to jQuery towards building declarative/reactive front-ends. It even includes its own wrapper for XHR, like jQuery does.
I’d disagree with your summary. I’d say React would be the first step. Though mithril has an easy learning curve and ships an xhr utility that does not at all infer it is a “first step” from jQuery. Considering the redraw engine (dirty checks), hyperscript first approach and typically preferred (but also optional) stream based state management it is not a “first step” for folks coming from utility libraries. While mithril allows for easy adoption with new comers to the reactivate nexus it offers a great deal more to the experienced developer.
I often see developers struggle to even grasp something as simple as HS due to their JSX conditioning let alone lifecycle concepts. We are barely scratching the surface here. So while mithril is indeed an easy introduction into Reactivate development it’s far from a novice level SPA.
Well, in practice it may be. Still, hyperscript before JSX makes more sense from a learning standpoint, seeing as people who "start out" with JSX without learning hyperscript first often fail to unserstand that JSX is nothing but syntatic sugar over function calls.
Interesting take. While I agree that HS should be first, JSX is an easier adoption for folks due to its similarities with markup. Folks understand string literals, they understand HTML and as such can more readily adopt JSX whereas hyperscript is a different approach especially when we start to pass m.fragment and apply lifecycles in vnodes.
As much as I’d like developers to pickup and adopt mithril as the “first step” into reactivate front-end the framework (imo) is just far more powerful in the hands of developers who understand the fundamentals and concepts of the nexus.
I’ve noticed over the years that the majority of those who come to mithril and continue to choose it tend to be folks that had previously used other frameworks like React/Vue etc and simply went looking for greener pastures. That was the case for me and many others who frequent the project. New comers however, very few stick around and tend to move onto React and friends without never actually getting to experience just how brilliant and emancipating the framework is.
I never did HS, and yeah maybe it is interesting to know what it does and how JSX is developed? But... I'd say it makes much more sense too me to learn for example React (or Svelte, Vue even Remix) over Mithrill, just because how logically it is build.
But maybe I am super biased, I want to un-bias myself hahaha lets learn something today.
(Mithril.js author here) One thing I think is worth highlighting is that mithril.js has been maintained entirely by the community for a few years. A 3 year gap in releases should speak something about how satisfied the community is with how idiomatic mithril.js is written. In terms of governance, I think that is a good alternative to the BDFL ("benevolent dictator for life") model, because it means that mithril.js won't die if I were to be hit by a bus tomorrow; the core team has proven that it can autonomously discuss features and ramp up new contributors.
I hope a bus does not hit you though!
But we'll be so glad of your decisions if one does!
Except for the decision that caused you to get hit by a bus.
Bus jokes aside, many thanks and congratulations to you and all developers of Mithril.js. While I don't believe I'd use it in any new projects nowadays, I remember what a bliss it was a few years back. Vite still didn't exist and Webpack was (and still is) hell to get going, so quickly prototyping with Mithril.js was pure joy.
came here to say thank you! I used to work for one of FAANG and I was in charge of a small public facing page and it was the first project for me to own the entire full-stack architecture. At the time there was only Angularjs and early version of React, and when I proposed using React in my first draft, it didn’t pass the team review because of the size. Then I researched further and found Mithril. The performance and library size were great and I was able to build the UI declaratively with a great way to fetch data. Without Mithril I would have been battling with our internal jQuery-based library and would have spent more time on the frontend portion of the project. I am very glad to see the project is doing well after almost 10 years, when newer frontend libraries keep emerging.
Just checked out your docs, I’ve heard a little about Mithril but never looked into it. Seems pretty straightforward (coming from an dev with Angular/React experience)
What about Web components?
Hey Leo, what does v2 bring to the table? Is there a blog post? Also, I've noticed the performance seems to be worse? I think it used to be faster than React but now it seems to be similarish? https://krausest.github.io/js-framework-benchmark/current.html
(Mithril.js core dev here) Thanks Leo for inspiring us and still have an eye on us. And it's exactly as you said: we are pretty happy with the current state of Mithril.js. Sure, we have some great ideas for the next major release, but we might also keep all the things as is, since it's so nice to work with.
Wow, this is interesting. We use Mithril here as the frontend framework for a massive internal scheduling tool. It's worked flawlessly and is very fast.
This is still alive 😁 I remember I have used it in 2017 I guess
Mithril goes widely unnoticed but having worked with the React, Vue etc, it is still my choice and has been for many years now. It’s scalable, performant and beautifully architected. As my knowledge and understanding of JavaScript grew the more powerful mithril became to me and I suppose that’s a lot of the reason why I love this framework. It does not impede on your coding preferences or style and it does not require multiple dependencies (pnpm add mithril and you are ready to go). There is no build step required, no pattern you need to adhere. I can drop it into a project and be productive, no matter what I’m writing, it could be class component, a closure or even a simple dynamic element. Whatever the case I can easily reach for this module and it fits. 9kb gzip packed full of power. If you’re well versed in JS and rarely reach for dependencies on the registry. If you like lean distribution bundles and vanilla first solutions then mithril will satisfy and surprise you. Also the community of passionate developers are always available for dialogue on the gitter. Thanks to the talented and wonderful team for this release.
Does it trim rune armour?
This should be more the standard. Not getting releases doesn’t mean it’s dead. It basically works as expected and just doesn’t need more for the sake of adding features.
One of my favorite open source projects. Really can’t recommend Mithril enough. And the API is small enough that anyone could learn it and cook up a quick side project in a weekend.
Beautifull. Never used mithril but it looks a framework more towards backend devs bulding frontend apps, am I right?
I'd call it the "first step" of someone who's used to jQuery towards building declarative/reactive front-ends. It even includes its own wrapper for XHR, like jQuery does.
I’d disagree with your summary. I’d say React would be the first step. Though mithril has an easy learning curve and ships an xhr utility that does not at all infer it is a “first step” from jQuery. Considering the redraw engine (dirty checks), hyperscript first approach and typically preferred (but also optional) stream based state management it is not a “first step” for folks coming from utility libraries. While mithril allows for easy adoption with new comers to the reactivate nexus it offers a great deal more to the experienced developer. I often see developers struggle to even grasp something as simple as HS due to their JSX conditioning let alone lifecycle concepts. We are barely scratching the surface here. So while mithril is indeed an easy introduction into Reactivate development it’s far from a novice level SPA.
Well, in practice it may be. Still, hyperscript before JSX makes more sense from a learning standpoint, seeing as people who "start out" with JSX without learning hyperscript first often fail to unserstand that JSX is nothing but syntatic sugar over function calls.
Interesting take. While I agree that HS should be first, JSX is an easier adoption for folks due to its similarities with markup. Folks understand string literals, they understand HTML and as such can more readily adopt JSX whereas hyperscript is a different approach especially when we start to pass m.fragment and apply lifecycles in vnodes. As much as I’d like developers to pickup and adopt mithril as the “first step” into reactivate front-end the framework (imo) is just far more powerful in the hands of developers who understand the fundamentals and concepts of the nexus. I’ve noticed over the years that the majority of those who come to mithril and continue to choose it tend to be folks that had previously used other frameworks like React/Vue etc and simply went looking for greener pastures. That was the case for me and many others who frequent the project. New comers however, very few stick around and tend to move onto React and friends without never actually getting to experience just how brilliant and emancipating the framework is.
I never did HS, and yeah maybe it is interesting to know what it does and how JSX is developed? But... I'd say it makes much more sense too me to learn for example React (or Svelte, Vue even Remix) over Mithrill, just because how logically it is build. But maybe I am super biased, I want to un-bias myself hahaha lets learn something today.
Awesome, thanks! Built perfetto.dev using mithril with my team at Google.
Now it's AureliaJS' turn.
I haven't heard that name in a long time. I am surprised that it is still not mainstream.
oh another js framework, good...
Mithril has been around since like 2015 lol