HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
MithrilJS
mithril.js
JavaScript2014–2025
MithrilJS / mithril.js

mithril.js

A JavaScript Framework for Building Brilliant Applications

Web Development
Explore on GitHubRead Hacker News discussions
25Distinct people
34Mentions
0Explicit recommenders
14.5KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

A JavaScript Framework for Building Brilliant Applications

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 3:30:57 AM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year34 dated mentions

Observed mentions: 2014-03-24 17:00:10 UTC to 2025-05-12 00:10:30 UTC.

0123452014-01-01 00:00:00 UTC to 2015-01-01 00:00:00 UTC (exclusive): 5 mentions; 0 submissions, 5 comments20142015-01-01 00:00:00 UTC to 2016-01-01 00:00:00 UTC (exclusive): 4 mentions; 0 submissions, 4 comments2016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 5 mentions; 1 submissions, 4 comments2017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 5 mentions; 0 submissions, 5 comments2018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 4 mentions; 1 submissions, 3 comments20192020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 4 mentions; 0 submissions, 4 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 2 mentions; 2 submissions, 0 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 2 mentions; 1 submissions, 1 comments2025

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20142014-01-01 00:00:00 UTC2015-01-01 00:00:00 UTC505
20152015-01-01 00:00:00 UTC2016-01-01 00:00:00 UTC404
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC514
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC505
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC101
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC413
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC404
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC000
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC220
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC202
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC000
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC211

What Hacker News says

5 sources
lhorie·Jul 17, 2014
If anyone's interested in anedoctes from a library dev point of view, I've my framework listed there (it's called Mithril), and microjs is not a big source of traffic despite microjs being around for a while. Microjs displays popularity from the release repo, which in my case is low compared to the development repo ( https://github.com/lhorie/mithril.js ), so even the little information that is displayed in the microjs site is not super useful for someone trying to figure out what libraries are worth looking into. Myself, I primarily use it as a starting point resource for looking at how someone might have tackled a small-ish domain, to minimize getting tripped by caveats I might not be familiar with.
In Microjs: JavaScript Micro-Frameworks and Micro-Libraries
lhorie·May 9, 2014
That topic was brought up here: https://github.com/lhorie/mithril.js/issues/68 Generally, you only need to manually call start/endComputation when integrating to 3rd party code that needs to update Mithril managed bindings. In the latest release, I tweaked the rendering aggressiveness to allow redraws after exceptions in event handlers, and I updated the docs wrt `try/finally` blocks in integration scenarios. One other thing people could do that I don't think should go in Mithril core is to call m.redraw inside window.onerror. Of course, I'm open to other suggestions, if you have any.
In Flux Application Architecture
lhorie·Apr 4, 2014
As always, the helpfulness of the people here is really great, so thank you :) I do have a mailing list here ( https://groups.google.com/forum/#!forum/mithriljs ), which I made a bit more prominent on the site just a few minutes ago, and some of us have been using the github issue tracker ( https://github.com/lhorie/mithril.js/issues?state=open ) for suggestions and general Q&A. I have a few ideas of things I'd like to write about in more detail so I'll probably put an article out soon. @ChuckMcM: there are a few good reasons to push on the marketing front: - more popularity means more bugs found and fixed, and thus better software - developing a community increases the quality of the ecosystem around the project exponentially. For example, one criticism I heard a few times at release was solved by a contributor before I even got the chan
Read the rest
ce to take a stab at it ( https://groups.google.com/forum/#!msg/mithriljs/lGiNpog2mbc/... ). I feel that community involvement is a really important factor to take the project to the next level. - semi-related to the previous point, many things on the project roadmap for example are things that anyone looking for a side project can pick up and do. Some don't even require you to know anything about the framework. I'm really put off by the high barrier of entry to contribution to projects like Angular, and I feel that giving people of all levels the chance to crank some code is a win-win for everybody. - another related point: different people tell different stories. It's one thing for me to put out a lot of examples and reading material (which I do try to do w/ the docs on the site), but often, people do things that I never anticipated. They can write better, more focused articles and share them with audiences that I might not have even known existed. And even if they're just retweeting something I wrote, their social reach is different from mine: a lot of people that might find Mithril useful don't read HN, but they might hear about it from a friend that does. - a somewhat unique reason to Mithril is that it has a pretty stable core already, and the project needs to move forward in some front in order for it to be seen as an "active" project. Also, it's marketing 101 to stay on top of people's minds. If they keep hearing about Mithril from different sources, then they're more likely to spend a little of their valuable time to try it out and hopefully fall in love and join the community.
In Ask HN: Ideas on promoting an open source project?
lhorie·Mar 24, 2014
> This AST is later combined with data (typically plain old JavaScript objects, or POJOs) to construct a lightweight data-bound ‘parallel DOM’, which can run in the browser or on the server. Through this, it is able to make smart decisions about how to update the real DOM in the most conservative manner possible. > Because it only touches the parts of the DOM it needs to, you can write your templates in the way that makes the most sense for your app, without having to worry about the performance headaches of constantly trashing the DOM or the code headache of wiring up a plethora of view objects. Huh, the solution he described is basically the technique I use in Mithril[1], except that Mithril templates don't need the extra HTML parsing step because they pretty much are the AST. My bare-bones approach received some criticism here last wee
Read the rest
k for not being "pretty" (for the "HTML is pretty" definition of "pretty"), but it allows better debuggability[2], and opens the doors for some interesting FP techniques, among other things. Templating seems to be a hot button these days, but it's unfortunate that it's such a complex topic. Discussions about performance like this article are great, but it's hard for non-framework devs to keep all the other facets of template design in their heads when trying to evaluate the bazillion choices in the market. [1] http://lhorie.github.io/mithril/ [2] https://github.com/lhorie/mithril.js/issues/16
In String Templating Considered Harmful

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.