Ask HN: Why are so few people using/talking about Mithril.js?

[demetriusnunes]

I see a lot is being talked about React, AngularJS (even Ember): tutorials, performance benchmarks, posts, videos, libraries, etc.

But recently I found out about Mithril.js and it seems to me that is technically superior than most of it competitors (in terms of performance, ease of use and size), and yet, pratically nobody is talking about it.

Is this just a marketing issue or am I missing some crucial point here?

[lhorie]

(Mithril author here)

I think perception plays a big role. There are fairly large and high traffic apps[1] built w/ Mithril, but when someone is taking a risk to learn a new thing (and there's a lot of that in js), of course something used by google or facebook feels "safer" to learn than something used by mashape, guild wars 2 or lichess. I've seen the "might no longer be supported later" fear being mentioned more than a few times, even though the reality is that it's not really a solo project anymore - it has almost a hundred contributors - and has a fairly sizeable ecosystem[2][3]. There are even Mithril jobs[4] out there.

Another somewhat ironic issue is that Mithril's main appeal is its lack of ceremony. It doesn't ask you to drink the revolutionary koolaid of "bi-directional data binding" or "immutable unidirectional data flow" or whatever other fanciness you can explain to others to make yourself look good. It's just a tool to get stuff done. And even though that's an important metric, it's not exactly newsworthy.

re: ES6: to clarify, you can use ES6 w/ Mithril. The issue in question has to do w/ trying to shoehorn ES6 classes to be components (which are normally plain objects in Mithril). Things like arrow functions actually make things cleaner in places where you'd otherwise use a .bind for example.

[1] https://github.com/lhorie/mithril.js/wiki/Who-Uses-Mithril

[2] https://github.com/lhorie/mithril.js/wiki/Community-Projects

[3] https://github.com/lhorie/mithril.js/wiki/Components

[4] https://github.com/lhorie/mithril.js/wiki/JOBS

[bjourne → lhorie]

It's version is 0.2.0 which is low. Authors generally use the 0.x series of numbers to indicate that their software "isn't ready" or "production quality" and breaking api changes might come. So if you want to encourage mass-adoption of Mithril, you ought to bump the version number to 1.x.

[alexc05 → lhorie]

Mithril is now driving a number of corporate enterprise apps in production. Quite large companies are running the apps and using them daily.

Now that I've worked in react, angular, and mithril I really do think it's the best of the three.

Though I haven't used mithril since I learned about webpack's hot module replacement so I'm not sure if they work well together (but its amazing with react).

Mithril is incredibly lightweight and quick to learn. The utils you've written with respect to rest integration are so quick to pick up and use...

I'm actually thinking about pulling mithril into a react project just for the request side of things.

Anyways, mithril is in my opinion so far, the best of the three.

[lhorie → alexc05]

For hot reloading, I've seen some people use amok. Here's a quick tutorial: https://gist.github.com/barneycarroll/de16bdff255344873439

[twunde]

It's partially marketing and partially support-based. React and Angular were released with a lot of fanfare by Facebook and Google respectively (and with a lot of documentation) after being used inhouse. This meant that there was already a decent number of developers familiar with the framework, already proven as "web-scale", and indicated that there would be good support for it going forward. This meant that it was an easy sell to CTOs. Mithril.js came out after React and was released by a lone developer. While it was well-documented it didn't have the amount of documentation as react and angular, was supported by one developer and didn't have a large install base of existing users. I'm starting to see it being used by more companies but it's certainly a harder sell than angular or react

[kapv89]

For me, its mainly because of React Native. React is a pretty decent View layer abstraction, and being able to use same concepts in developing UIs for all the platforms I want to target is a very big plus. I was fiddling with mithril before react-native came out, but ever since its release, I have just stopped looking at any other JS framework.

[mariust]

I for one, just found out about it, based on your link, so maybe this is related to marketing or to the fact that people are afraid to use 'non big names' libraries until they prove they are worth a try, because if you are a business and start development on a tiny library and after 5 months you see that it's no longer supported you have: option a) support further the development with your team option b) rewrite with an other framework

Both options are costly and that's maybe one of the reasons.

[artminister]

I was a Mithril user before i moved to React. Mithril is really easy to use, reading blog post of lhorie was a bliss. But the community and code was just not moving ahead. Nothing changed, nothing exciting in roadmaps and I wasnt learning anything new.

React was just as easy as Mithril. And for big projects, React brings in a better structure and performance. React ecosystem is full of amazing people, there is always something new that i want to learn. Flux, Redux, Relay, RN, the list just goes on.

[mxvanzant]

IMBA is another unknown but excellent Javascript library for UIs and is also a language derived from CoffeeScript. So far I've used it on two projects and I am really liking it. It has some quirks and not much doc. Your best bet is to look at all of the sample code and read the Issues forum.

[aprdm]

I've a friend who has been using in production and couldn't be happier.

[codegeek]

With all due respect to Mithril author, I would say it is perhaps the brand name ? React = facebook, Angular = Google, Mithril = ? But then I have no idea about Ember or Knockout. So may be I am wrong.

[AngeloR]

Just found out about it as well - and it seems way better than any of the others. It'll probably default to being my standard front-end framework. It abstracts just the right parts of things.

[rubiquity → AngeloR]

Do you always marry the person you go out on a first date with?

[izolate]

Doesn't seem to have good ES6 support from what I can gather. I can be wrong, I don't know enough about Mithril.

[hackerboos → izolate]

No you are right. ES2015 support is an open issue.

[eecks]

What is superior about Mithril? If I run into a problem with React or Angular, it's probably already been solved.

[lhorie → eecks]

The main reason I wrote Mithril was that we had a large Angular codebase at work and we had ongoing problems with performance and poor error reporting (swallowed errors, un-actionable errors, etc).

[alexc05 → eecks]

It is very lean and it is JavaScript only.

There is very little in mithril that is "opinionated" so you can be up and running very quickly.

It has a few very key built-in methods that make working with apis easier but they're based on (or possibly exactly) taken from the versions you know. As an example m.request uses a format nearly identical to node's request module.

Compare to angular where you MUST use dependency injection, you must use their templating, must use their XYZ internals. Very heavy to pick up and build correctly. Very slow whan you get to scale.

Compare to react where you've got to use JSX, which means adding transpilers, maybe some sort of gulp-watch, should probably use flux, do things in their opinionated way.

Once you "get it" they each have their pros and cons.

My preference so far is mithril but I am in the middle of giving my react project a fair chance so that opinion may change by the time I go live.