I credit mithril and it’s fantastic community of knowledgeable devs with really changing my learning style at the outset of my dev career. Essentially from learning by reading, and becoming overwhelmed (as is often reported in the js world), to learning by doing and using technology. I’m sure this happens to many other people through different routes but I personally experienced it through this community. Seeing people so actively discuss things with new users and the amount of other general interesting discussion that happens in the mithril Gitter channel makes it one of my favourite places on the web. There is a strong desire for simplicity and a strong anti bloat sentiment from the devs over there. I like it a lot. I’m referring to you, Pygy, Leo, tivac, barney, porsager, jaforbes and foxdonut. I have built and deployed a few mithril apps in production early in my career and I’m glad I had the chance. I wonder now how new js devs starting with frameworks like vue can learn to work with the language rather than than the framework when every part of it is wrapped up in a reactivity system. I would worry that a lot of vue devs would come to mithril and not understand why the string literals they are passing down to components are not being set in the parent.
Anyway that’s enough. Cheers to mithril and it’s great devs, if you like mithril check out bss and Wright from porsager and meiosis from Foxdonut.
Second this. Mithril.js is absolutely incredible, and my coworkers are often surprised at how quickly I can dive into a React project and fix an issue because I don't carry the baggage of doing things "the react way".
Every now and then I use software tools where rather than complaining about how x or y should be different, everything seems to be the best possible version of something I'd have come up with myself, and I have zero complaints. Mithril.js is one of those tools.
You're not "in a Mithril project", you're basically just using javascript but the VDOM is expertly and minimally handled by some key functions.
Participating in the project via Gitter was very welcoming as well. Long live Mithril!
Some people are way better at finding issues than others, even in other's code bases.
Another good skill to have though, that is unfortunately not super duper common either, is being able to figure out and match conventions and patterns in code bases when introducing changes.
I have nothing but great things to say about mithril. It has a wonderful and well documented API that maintains simplicity but manages to cover the entire project (no hidden APIs or undocumented features) to the credit of the mithril community the focus in simplicity is grained into the project from the bottom up.
I have to say that it’s been nothing short of amazing and is the reason I took JavaScript much more seriously.
The community is awesome and very welcoming. The gitter chat is always active and people are happy to chat and answer questions. I credit them with being able to move quickly with mithril.
At my job my entire team uses it and everyone so far has loved it. It’s been great!
I love Mithril. I would encourage every React/Vue developer to try it for a small project. Not to convince them to switch (I use all 3), but because I think using tools designed by smart people with a minimal mindset is valuable. Also I really like the hyperscript approach. It just fits my brain.
Last I checked, Mithril hyperscript couldn't handle SVG, which is a non-starter for dataviz work. Anyone know if that's still the case?
That's great to hear. I'm almost wondering if I'm getting my history mixed up. Maybe it did work when I tried it (~ a year ago) but I just stumbled on old information and gave up.
Or maybe I'm thinking of a different hyperscript implementation.
It is great to see Mithril again on front page of HN, it is one of the most simplest and easiest modern JS frameworks. I only know flarum [0] as a project which has used Mithril mixed with jQuery [1] and personally, I am quite amazed how snappy it is.
Aside, Flarum's scrubber/scrollbar is brilliant and a massive upgrade to how you have to navigate a traditional message board like phpbb where you kinda guess at arbitrary pagination til you're where you want to be.
Good example of using a SPA to improve UX of a "document-based" app.
Another example of this sort of SPA improvement is when clicking on a list-view item brings up an overlaying modal of the item-detail page which is nicer when user is browsing rapidly.
Mithril is probably my favorite widget framework. I will still use React for larger applications because of the breadth of third-party modules. That said, Mithril and Preact start to make me question React. I'm sure a React developer would say that 10k LOC and 70MB worth of repository is completely necessary for the functioning of React, but part of me thinks there are too many cooks and only one pot. React is elegant, but I don't think its abstractions are simple enough.
I needed to build a fairly complex tree-table in our legacy ES5 app and I initially turned to Vue to build the first prototype. I'm a big fan of Vue, but for the first time with Vue I found myself really fighting against the framework. In particular Vue's templating system and lack of template fragments make it hard to create complex HTML table elements as they require a strict structure. Another issue is our ES5 app already has its own build system so we'd either be stuck with using Vue without Webpack (which in Vue is a really inferior experience) or attempting to use both build systems which is a bit cumbersome.
While researching Vue template fragments I discovered Mithril has had support for fragments since its inception (React recently also added support for fragments). I had always discounted Mithril. I'm not sure why. Perhaps it's the simple homepage, the seemingly brief documentation, hyperscript, or the lack of HN hype. Wow was I ever so wrong. The documentation is short because the API surface area is tiny and this is a GOOD thing. I never felt like I was writing framework code or trying to figure out the Mithril way of doing things. It pretty much gets out of your way. Hyperscript, which I thought I would hate, turned out to be one of my favorite parts of using Mithril especially when I paired it with Tailwind CSS. Since Hyperscript is pure JavaScript, doesn't require a build step, and is the standard way of writing Mithril components, integrating Mithril into our legacy JS app was absolutely dead simple.
I've been using it for some time now, and the biggest plus for me, besides the very simple to understand API and the manual redraw feature, is the ease one can find setting it up for a project.
Even with webpack or some other complex bundle, someone without any formation can really quickly set it up and get to code without worrying much about the internals of webpack etc.
Setting up Webpack manually is a pain, but honestly if one uses create-react-app, everything is done for you and you just start coding your app: you have transpiling of ES6 (at least, I don't know about ES7), you can install and include other packages, etc. etc.
True. If you're creating an app that will be used in production then of course you need to use npm, webpack and other tools.
But if you're new to a framework and just want to experiment then being able to create an html file with a couple of script tags and writing code removes many barriers to entry.
React, Vue and many others already offer this, I thought it was worth mentioning that Mithril does this too.
That link preloads mithril in a web playground and you're ready to go in a couple of seconds.
You can even download and continue development locally should the need arise - without the gorilla and the jungle hiding behind it.
The biggest problem I find with that is if the template/tool gets some deprecated/critically flawed dependencies, for tweaking it can be ignored but not for production or critical systems.
Also taking the time to set up your project with what's just needed will allow to dodge a lot of bullets of breaking or useless dependencies, malicious dependency update tc.
Sure. If you still want to be React-like, that is! But React, Preact are still view libraries right? Mithril is a (reasonably) complete framework. It's sufficiently similar to React that if you know React, you can get productive in Mithril very fast. I guess mithril is for people who want a full framework with no fluff that gets out of the way.
> But React, Preact are still view libraries right?
No, they're component-oriented. View suggests you're doing MVC or similar. You don't need an M & C with React -- you will likely need to add react-router, but react + react-router (or preact + preact-router) is all the 'framework' you need for most apps.
Ok. For that matter, Mithril is also component-oriented and router is included.
And what I meant by react being a view library is that react by itself only handles the UI part and you need to get additional libraries to handle stuff like routing and talking with the server. This stuff is provided by mithril itself.
It seems you're missing the point. React and Mithril both employ virtual DOM, both use components and both allow higher abstractions that provide ways to manage complexities that arise in front-end development. Jquery and HTML don't do that.
I tried both Mithril and React and found Mithril to be simpler than React as it 'gets out of the way'.
I invite you to read this for more detailed comparison :
I had a similar experience. It made me understand how front-end javascript frameworks actually work (in general). The no-fluff approach taken by the framework meant that code was clear and descriptive docs helped (reminds me of Django's docs sometimes). I wish there were more tutorials though.
Loved mithril when I used it a few years ago. Simple clean and effective. The source code was very straight forward if you needed to investigate deeper.
Looks interesting, but I found the fact that they say
| Be wary of aggressive performance claims, as benchmarks used by some of these projects are known to be out-of-date and flawed (in the sense that they can be - and are - exploited)
on a page full of aggressive performance claims[0] slightly ironic
Guilty as charged. That page hasn't been updated since the v1.0 release, we've been focusing on code improvements.
V2 is around the corner (mostly bug fixes, some of which required subtle breaking changes (i.e. things that most users won't run into but it would not have been honest to make it a minor semver bump). We'll revisit the home page before the release.
Mithril has a very open and inviting community and will definitely accept PRs. I reccomend popping into the Gitter channel if you’d like to discuss things further
I think what they are trying to say is that try everything yourself and see and don't just blindly believe in benchmarks.
And also mentioned on the same page is this :
In the spirit of demonstrating typical performance characteristics, the benchmarks presented in this comparison page are implemented in an apples-to-apples, naive, idiomatic way (i.e. the way you would normally write 99% of your code) and do not employ tricks or advanced optimizations to make one or other framework look artificially better. You are encouraged to contribute a PR if you feel any DbMonster implementation here could be written more idiomatically.
This follows Reacts style of 'functions instead of templates'. I don't think it's a good idea.
I think React will be the Java of our time. It caters to engineers who want everything to be well defined and typed. And to large corporations which don't care about heavy build processes.
Looking at what happened to Java: It's still used a lot. But not by new and exciting companies or indie developers.
I think we will see the same with React. It will stay around for decades. But the exciting new projects of the next ten, twenty years will not be written in it. They will be written by lighter tech stacks. Just like FB was initially not written in strictly typed Java but in loosely typed PHP.
It would follow then that an engineer having to look at a React project in the future might have an initial reaction not foreign to an engineer having to deal with a legacy Angular 1.x codebase today: recoil.
I'm asking why you prefer hyperapp because Mithril has router and xhr capability built-in, and hyperapp doesn't seem to have those features. But hyperapp is really tiny though. :-)
There are addons for routing and HTTP requests for hyperapp, and they add trivial amounts to the bundle size.
The reason to use hyperapp IMO is it is far closer to the actual Elm-style FRP model, and as such includes functional state management out of the box, in a far less awkward and boilerplate heavy way than Redux provides.
If I understand correctly, HyperApp enforces the so-called SAM pattern, but that's it. Calling this "state management" seems to me an exaggeration. And why would one use a view framework to do (domain/application) state management? It doesn't sound right.
Can someone summarize with an example that shows why this has benefits over React? I read the first few examples and it seems simple enough, but I've bought into the whole JSX benefit and don't see how those first few examples allow me to write less code and code that is closer to the HTML I'll eventually be rendering. Is it the tooling that mithril allows me to forget about? Is it something special that mithril gives me a novice who doesn't realize I'm being held back by using React?
Usually, what I hear from folks is that you come out of using Mithril with more transferable knowledge than something like React.
One example that comes to mind was when someone realized you could implement an incredibly simple atomic CSS composition framework by basically doing this:
/* some atomic CSS */
.primary-color-700 {color:blue;}
.pad-700 {padding:1em;}
/* a bog standard CSS selector string */
const MyWidget = '.primary-color-700.pad-700';
/* a Mithril element */
m(MyWidget) // <MyWidget /> in JSX
So you can get a fairly aggressive CSS optimization scheme for basically free, and you can iteratively improve the quality of your atomic CSS as you learn more about plain CSS / semantic taxonomy practices. And meanwhile, you're still just writing bog standard CSS and Mithril templates. There's no compile-time shenanigans to dedupe styles, no extra library runtime, and CSS is actually CSS so if you server-render you stay on the browser's streaming rendering happy path instead of waiting blocked on scripts.
Now compare with what one would do with most frameworks: one would pick some CSS-in-JS library, get things done and over with, but probably learn nothing interesting in the process and have little idea of what sort of code is actually getting shipped to customers.
I've also bought into JSX. I use JSX in all my Mithril projects.
Advantages over React: Routing built in. Smaller/faster. You don't get numb to the word "dangerously" being used routinely for data that you trust.
Debatable: Mithril does not wrap native browser events. This is an advantage because what you learn about events applies outside the framework. It may also be a disadvantage; debatable.
Disadvantage: React is a more attractive keyword on your resume and in job listings.
As web-development is not my primary trade, I found that MithrilJs was the right amount of abstraction to get into it.
Small API, modular, as close to Javascript as it could get and with the help of the folks in the Gitter channel and the invaluable pearls of wisdom in Leo's blog in the earlier days of the framework, my code became more functional and much more readable.
For me, it's kind of the swiss army knife of Frameworks.
The main problem with steering away from templates is that designers who know HTML are immediately alienated from the code base. Same thing with CSS as objects instead of using real CSS.
When working with libs that use HTML templates such as Vue, it's still possible for designers to be integrated in the development process. But with HyperScript, JSX, or Mithril, anyone contributing to the codebase has to know JavaScript.
If they can’t learn basic JavaScript, they should not be touching the code base with a ten foot pole. Designers can still design, but through mockups and comments passed to people qualified to modify code.
It's a collision between half the industry telling designers they need to know HTML and CSS to do the CSS work themselves (instead of Software Engineers, because they apparently don't want to deal with it) while the other half of the industry makes it ever harder to do so.
Consistency isn't exactly a high point when it comes to industry signaling vs reality.
I love getting PRs from designers on my Vue project at work. They enjoy not having to wait on me and I enjoy focusing on application logic instead of CSS tweaking.
This is one of the biggest reasons I see people citing for Vue>React. I think it's a very easy argument to defend, but I'm sincerely curious how big of a role this plays. Is it really that common to change the HTML/CSS of an app without also requiring changes to the underlying JavaScript? I have no doubt it happens, but I'm wondering if it happens often enough to justify claiming superiority of one popular web framework over another.
Beyond that, out of HTML, CSS, and JavaScript, by far I find CSS the most difficult to work with and get to behave the way I want. Are there really a lot of designers who are experts at this language but don't know any JS?
I think you might be able to measure some of this. I wonder if you could look at some popular web apps that have separate HTML/CSS/JS files and look at the proportion of commits where only the UI changes, vs commits where you have to change the UI and the JS. The hypothesis being that in general you need to change your JS, and thus require a full developer anyway.
Problem with this approach is, that it only works for fairly simple stuff. Todays webapps have pretty complex UI with a lot of ramifications and complex dependencies of widgets. Such things are much easier to build if you have a full fledged programming language (javascript) and not only a limited (turing-incomplete) templating language.
So your approach might work for simple apps, more ambitious stuff will get overly complicated.
That is imho one of the strength of mithril.js: Simple things are trivial, complicated things are pretty straight forward to solve.
Interesting, I don't have much experience with either, but I thought Mithril was kinda succeeded by Aurelia, which makes it a less attractive choice for a new project. Good to see there's still stuff going on.
You're probably thinking of Durandal, which was the predecessor of Aurelia (along with some brief history involving Angular, IIRC). Mithril is an entirely different project by different people, I believe.
You can use mithril.js without m.request, but then you have to dispatch redraw events when you finished handling the request[^1]. It also provides a promise API for web requests in old browsers, i.e. without fetch(). If I choose not to use m.request, I would have to find another XMLHttpRequest wrapper and bind it to Mithril.
Wow, thank god. Just what we need. Another JavaScript framework.
Hey, yeah, we looked at your resume, but
we noticed that you don’t have any hobbit.js
experience. We’re a pretty serious project
and hobbit does a lot of heavy lifting for
us, so we’re going to pass for now, but we’ll
keep you in or file in case anything comes up.
Thanks so much! Best of luck!
Anyway that’s enough. Cheers to mithril and it’s great devs, if you like mithril check out bss and Wright from porsager and meiosis from Foxdonut.
Every now and then I use software tools where rather than complaining about how x or y should be different, everything seems to be the best possible version of something I'd have come up with myself, and I have zero complaints. Mithril.js is one of those tools.
You're not "in a Mithril project", you're basically just using javascript but the VDOM is expertly and minimally handled by some key functions.
Participating in the project via Gitter was very welcoming as well. Long live Mithril!
Would they not want your solution to conform to existing solutions; which (regardless of being idiomatic to React) would be idiomatic to the codebase?
It's not many hands on one project but everyone taking care of their own projects, so it's a bit different where I'm at right now.
Another good skill to have though, that is unfortunately not super duper common either, is being able to figure out and match conventions and patterns in code bases when introducing changes.
I have nothing but great things to say about mithril. It has a wonderful and well documented API that maintains simplicity but manages to cover the entire project (no hidden APIs or undocumented features) to the credit of the mithril community the focus in simplicity is grained into the project from the bottom up.
I have to say that it’s been nothing short of amazing and is the reason I took JavaScript much more seriously.
The community is awesome and very welcoming. The gitter chat is always active and people are happy to chat and answer questions. I credit them with being able to move quickly with mithril.
At my job my entire team uses it and everyone so far has loved it. It’s been great!
Last I checked, Mithril hyperscript couldn't handle SVG, which is a non-starter for dataviz work. Anyone know if that's still the case?
SVG works fine with Mithril now, and has for a while. Here's a quick sample: https://flems.io/#0=N4IgZglgNgpgziAXAbVAOwIYFsZJAOgAsAXLKEAG...
Or maybe I'm thinking of a different hyperscript implementation.
[0]: https://discuss.flarum.org/
[1]: https://github.com/flarum/core/blob/master/js/package.json
There's also https://flems.io a snappy web playground with an open source embeddable core[2] ( shameless self promotion :P )
[0]: https://github.com/veloce/lichobile
[1]: http://lichess.org
[2]: https://github.com/porsager/flems
Good example of using a SPA to improve UX of a "document-based" app.
Another example of this sort of SPA improvement is when clicking on a list-view item brings up an overlaying modal of the item-detail page which is nicer when user is browsing rapidly.
I needed to build a fairly complex tree-table in our legacy ES5 app and I initially turned to Vue to build the first prototype. I'm a big fan of Vue, but for the first time with Vue I found myself really fighting against the framework. In particular Vue's templating system and lack of template fragments make it hard to create complex HTML table elements as they require a strict structure. Another issue is our ES5 app already has its own build system so we'd either be stuck with using Vue without Webpack (which in Vue is a really inferior experience) or attempting to use both build systems which is a bit cumbersome.
While researching Vue template fragments I discovered Mithril has had support for fragments since its inception (React recently also added support for fragments). I had always discounted Mithril. I'm not sure why. Perhaps it's the simple homepage, the seemingly brief documentation, hyperscript, or the lack of HN hype. Wow was I ever so wrong. The documentation is short because the API surface area is tiny and this is a GOOD thing. I never felt like I was writing framework code or trying to figure out the Mithril way of doing things. It pretty much gets out of your way. Hyperscript, which I thought I would hate, turned out to be one of my favorite parts of using Mithril especially when I paired it with Tailwind CSS. Since Hyperscript is pure JavaScript, doesn't require a build step, and is the standard way of writing Mithril components, integrating Mithril into our legacy JS app was absolutely dead simple.
Even with webpack or some other complex bundle, someone without any formation can really quickly set it up and get to code without worrying much about the internals of webpack etc.
But if you're new to a framework and just want to experiment then being able to create an html file with a couple of script tags and writing code removes many barriers to entry.
React, Vue and many others already offer this, I thought it was worth mentioning that Mithril does this too.
npx create-react-app MyApp
There is nothing to install, and you have a complete playground to experiment.
That link preloads mithril in a web playground and you're ready to go in a couple of seconds. You can even download and continue development locally should the need arise - without the gorilla and the jungle hiding behind it.
Also taking the time to set up your project with what's just needed will allow to dodge a lot of bullets of breaking or useless dependencies, malicious dependency update tc.
https://preactjs.com/
No, they're component-oriented. View suggests you're doing MVC or similar. You don't need an M & C with React -- you will likely need to add react-router, but react + react-router (or preact + preact-router) is all the 'framework' you need for most apps.
And what I meant by react being a view library is that react by itself only handles the UI part and you need to get additional libraries to handle stuff like routing and talking with the server. This stuff is provided by mithril itself.
Well, you (or the author) are comparing it to React in your title, so of course people assume that you're targeting React devs.
Now you're saying that it's something different?
I tried both Mithril and React and found Mithril to be simpler than React as it 'gets out of the way'.
I invite you to read this for more detailed comparison :
https://mithril.js.org/framework-comparison.html#react
If you include those in preact they may have similar size.
| Be wary of aggressive performance claims, as benchmarks used by some of these projects are known to be out-of-date and flawed (in the sense that they can be - and are - exploited)
on a page full of aggressive performance claims[0] slightly ironic
[0]https://mithril.js.org/framework-comparison.html
Guilty as charged. That page hasn't been updated since the v1.0 release, we've been focusing on code improvements.
V2 is around the corner (mostly bug fixes, some of which required subtle breaking changes (i.e. things that most users won't run into but it would not have been honest to make it a minor semver bump). We'll revisit the home page before the release.
And also mentioned on the same page is this :
In the spirit of demonstrating typical performance characteristics, the benchmarks presented in this comparison page are implemented in an apples-to-apples, naive, idiomatic way (i.e. the way you would normally write 99% of your code) and do not employ tricks or advanced optimizations to make one or other framework look artificially better. You are encouraged to contribute a PR if you feel any DbMonster implementation here could be written more idiomatically.
https://500tech.com/blog/all/is-reactjs-fast/
I think React will be the Java of our time. It caters to engineers who want everything to be well defined and typed. And to large corporations which don't care about heavy build processes.
Looking at what happened to Java: It's still used a lot. But not by new and exciting companies or indie developers.
I think we will see the same with React. It will stay around for decades. But the exciting new projects of the next ten, twenty years will not be written in it. They will be written by lighter tech stacks. Just like FB was initially not written in strictly typed Java but in loosely typed PHP.
The reason to use hyperapp IMO is it is far closer to the actual Elm-style FRP model, and as such includes functional state management out of the box, in a far less awkward and boilerplate heavy way than Redux provides.
Usually, what I hear from folks is that you come out of using Mithril with more transferable knowledge than something like React.
One example that comes to mind was when someone realized you could implement an incredibly simple atomic CSS composition framework by basically doing this:
So you can get a fairly aggressive CSS optimization scheme for basically free, and you can iteratively improve the quality of your atomic CSS as you learn more about plain CSS / semantic taxonomy practices. And meanwhile, you're still just writing bog standard CSS and Mithril templates. There's no compile-time shenanigans to dedupe styles, no extra library runtime, and CSS is actually CSS so if you server-render you stay on the browser's streaming rendering happy path instead of waiting blocked on scripts.Now compare with what one would do with most frameworks: one would pick some CSS-in-JS library, get things done and over with, but probably learn nothing interesting in the process and have little idea of what sort of code is actually getting shipped to customers.
Advantages over React: Routing built in. Smaller/faster. You don't get numb to the word "dangerously" being used routinely for data that you trust.
Debatable: Mithril does not wrap native browser events. This is an advantage because what you learn about events applies outside the framework. It may also be a disadvantage; debatable.
Disadvantage: React is a more attractive keyword on your resume and in job listings.
EDIT: Forgot my example - https://medium.com/front-end-hacking/how-it-feels-to-learn-j...
When working with libs that use HTML templates such as Vue, it's still possible for designers to be integrated in the development process. But with HyperScript, JSX, or Mithril, anyone contributing to the codebase has to know JavaScript.
Consistency isn't exactly a high point when it comes to industry signaling vs reality.
Beyond that, out of HTML, CSS, and JavaScript, by far I find CSS the most difficult to work with and get to behave the way I want. Are there really a lot of designers who are experts at this language but don't know any JS?
I think you might be able to measure some of this. I wonder if you could look at some popular web apps that have separate HTML/CSS/JS files and look at the proportion of commits where only the UI changes, vs commits where you have to change the UI and the JS. The hypothesis being that in general you need to change your JS, and thus require a full developer anyway.
So your approach might work for simple apps, more ambitious stuff will get overly complicated.
That is imho one of the strength of mithril.js: Simple things are trivial, complicated things are pretty straight forward to solve.
[^1]: https://mithril.js.org/autoredraw.html#after-mrequest
Yet-another-js-framework