HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
pdfernhout
choose-mithril
Web Development2020–2025
pdfernhout / choose-mithril

choose-mithril

Why I prefer Mithril over Angular and React

3Distinct people
7Mentions
0Explicit recommenders
55GitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Why I prefer Mithril over Angular and React

GitHub

Where it is used

No documented product use has been verified yet.

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 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 5:04:57 PM 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 year7 dated mentions

Observed mentions: 2020-11-24 03:11:40 UTC to 2025-05-09 22:14:51 UTC.

01232020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 3 mentions; 1 submissions, 2 comments20202021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 2 mentions; 1 submissions, 1 comments20222023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 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): 1 mentions; 0 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
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC312
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC101
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC211
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC000
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 UTC101

What Hacker News says

7 sources
Yes, I noticed that similarity too a bit -- from the use of a "HyperScript"-like approach (although Mithril can be used with JSX too). https://mithril.js.org/hyperscript.html Aberdeen is innovative in that it's great to be able to avoid the VDOM in a technical sense. For fun, years ago, I messed around with a different technical approach of just rendering HTML from code directly (similar to Aberdeen to that extent), but instead of an observables-ish idea, I used Mithril's approach of hooking into the event listening system to trigger redraws by wrapping event handlers. Of course, I quickly ran into the issue of losing state like cursor insertion points in editors when re-rendering (which is what motivates the vdom approach). I can wonder if maybe the HTML standard itself could be upgraded somehow to support that approach of replacement o
Read the rest
f HTML widgets but with retained widget state if an ID or such remains the same? While I applaud Aberdeen as an experiment, with Aberdeen, it seems problematical developer ergonomics to have everything be a reactive pipeline of some form of observables or signals. It's not especially more terrible than many other systems (e.g. Angular in practice, encouraging the use of RxJS Observables as a new way of encouraging writing hard-to-understand code). As Aberdeen has the previously mentioned innovation of avoiding the vdom, overall it might be a win for people who like that style of coding. But by comparison, I have found Mithril is so much easier to work with -- given the core idea of just assuming the UI is "dirty" after any listened-for event happens and re-rendering it. It's true though that Angular has a "Zones" approach to redraw when state changes which hides a lot of complexity but has OK developer ergonomics similar to Mithril in that sense -- until you get mired in RxJS code encouraged by the platform (at least when I last used it seven or so years ago). And then Angular code get mired in various other Angular-isms which requires bloated code in practice with lots of files to do the simplest component. Yes, you can try to work around a proliferation of files, but that is not the Angular way, or at least was not several years ago. And Angular advocates would argue the standardization is a big win for larger projects with multiple developers. YMMV. Also, dsego, thanks for submitting to HN in 2022 the essay I wrote on all that (which I just saw thinking prompted by seeing this article to check if it had already been submitted somehow): https://news.ycombinator.com/item?id=25194873 For others, this the essay which goes into more depth comparing developer ergonomics of React, Angular, and Mithril from my experience: "Why I prefer Mithril over Angular and React" https://github.com/pdfernhout/choose-mithril For a simple Mithril example with no special Observable or signal magic, see, say: https://kevinfiol.com/blog/simple-state-management-in-mithri... let count = 0; const Counter = { view: () => m('div', m('h1', 'Counter'), m('p', count), m('button', { onclick: () => count += 1 }, '+'), m('button', { onclick: () => count -= 1 }, '-') ) }; m.mount(document.body, Counter); The state is stored in just a regular JavaScript variable ("count" in this case), not a wrapped something or other special object (like Aberdeen or any other Observable or signal approach requires). This is made possible in Mithril in this case by the onclick method being transparently wrapped bu the HyperScript "m" function (or JSX equivalent) to call m.redraw() after the click event is handled. As with Mithril's HyperScript approach of leveraging JavaScript to generate HTML instead of inventing a weird non-standard templating system like JSX, Mithril's wrapping of event handlers leverages the ability to just simply define state in JavaScript closures or objects -- or whatever other more complex approach you want including even RxJS observables (as long as m.redraw() is called as needed if you make data changes outside an event handler). Lego Horie, Mithril's original inventor, just was brilliant with Mithril at creating great developer ergonomics.
In Show HN: Aberdeen – An elegant approach to reactive UIs
Developer here who has been programming over 40 years (since I was a teenager in the late 1970s). I know I am stretching things a bit here, but IBM mainframes, multi-user Forth systems, and distributed QNX systems ranging from the 1970s to the 1980s -- not to mention UNIX systems -- could all support remote procedure calls or interprocess/interapplication scripting across standard APIs to some extent (for a loose sense of process or application, especially with Forth). Even Smalltalk back then could do that to an extent but mostly from a single-user perspective in the sense that Smalltalk is mostly about message-passing objects. Essentially, you could have a system that could talk to itself or other similar systems in standard ways. Yeah, there have been so many cycles of forgetting and reinventing with new generations of programmers. Alt
Read the rest
hough it is true some things improve even as sometimes other things decay for a constantly changing kaleidoscope of opportunities and risks (a bit like host/parasite arms races in evolutionary cycles). https://en.wikipedia.org/wiki/History_of_CP/CMS https://www.forth.com/resources/forth-programming-language/ https://en.wikipedia.org/wiki/QNX https://www.qnx.com/developers/docs/qnx_4.25_docs/tcpip50/pr... And also from the 1960s-1970s: https://en.wikipedia.org/wiki/PLATO_%28computer_system%29 "Although PLATO was designed for computer-based education, perhaps its most enduring legacy is its place in the origins of online community. This was made possible by PLATO's groundbreaking communication and interface capabilities, features whose significance is only lately being recognized by computer historians. PLATO Notes, created by David R. Woolley in 1973, was among the world's first online message boards, and years later became the direct progenitor of Lotus Notes." And from a different perspective, what is email but a standard way to do a remote procedure call to hopefully invoke some behavior -- even if a human may often be in the loop? https://en.wikipedia.org/wiki/History_of_email And from the 1930s an earlier Paul Otlet invented the idea of using a standard 3x5 index card to store and transmit information (mainly metadata): https://en.wikipedia.org/wiki/Paul_Otlet "Otlet was responsible for the development of an early information retrieval tool, the "Repertoire Bibliographique Universel" (RBU) which utilized 3x5 inch index cards, used commonly in library catalogs around the world (now largely displaced by the advent of the online public access catalog (OPAC)). Otlet wrote numerous essays on how to collect and organize the world's knowledge, culminating in two books, the Traité de Documentation (1934) and Monde: Essai d'universalisme (1935)." For another example of cycles, my current favorite UI technology is Mithril+HyperScript+Tachyons for JavaScript (although Elm is great too conceptually, and likely inspired Mithril and React in part) which is so easy to use from a developer ergonomic point of view in part by (simplifying with a very broad brush) re-inventing the OpenGL video game paradigm of redrawing everything (with behind-the-scenes VDOM optimizations) from essentially a global state tree whenever the UI is considered "dirty" because someone touched it. Mithril is so much easier to use than UI systems that are all about creating dependencies (like most Smalltalk systems) or which require storing and updating state in carefully managed components (like React) or similar constrained models. But sadly React+JSX+SCSS has so far won the mindshare war despite overall worse developer ergonomics. I hope that cycle continues to turn someday and the Mithril approach will win out (if maybe in some other implementation by then). https://github.com/pdfernhout/choose-mithril Frankly it has been frustrating over the decades to see great ideas lose out for a time to lesser ones with better marketing or other institutional advantages or other non-technical issues (Forth vs. DOS, CPM vs. DOS, Smalltalk vs. Java, Mithril vs. React) or which better fit with the familiarity of developers with earlier systems (HyperScript vs. JSX, Lisp vs. C++). Yet, I can also still be hopeful things may improve as social dynamics and technical dynamics change over time in various ways. Like was said about JavaScript which I mainly program in now: "It is better than we deserve..."
In Ask HN: Why can't I learn anymore?
Hi Leo. Thanks for creating Mithril. Likewise at work I currently have to deal with React and its challenges. I have previously built other applications in Mithril (and still do in my spare time). I much prefer Mithril and lobbied for its use at work. But sadly React has so much mindshare which was persuasive to management. The only plus to that situation of using React was that I increasingly saw firsthand how much better the developer ergonomics are for Mithril over React -- and eventually wrote the essay about that linked below called "Choose Mithril". :-) As an example on libraries and React patterns, the emphasis on Redux for React in particular can rapidly create messy bloated codebases that are hard to maintain. That is due to the accidental complexity in React by its premature optimization of requiring use of setState() on compone
Read the rest
nts to queue redraws -- which Redux then tries to hide to support global state. Mithril by contrast makes it possible for developers to store state however they want by the brilliance of (by default) just assuming any time the user touches the UI (via anything with an added event handler like for a button press) that the UI needs to be rerendered (unless the developer choose otherwise). Here's a longer list of reasons why I prefer Mithril to React: https://github.com/pdfernhout/choose-mithril "tl;dr: Choose Mithril whenever you can for JavaScript UI development because Mithril is overall easier to use, understand, debug, refactor, and maintain than most other JavaScript-based UI systems. That ease of use is due to Mithril's design emphasis on appropriate simplicity – including by leveraging the power of JavaScript to define UIs instead of using an adhoc templating system. Mithril helps you focus on the essential complexity of UI development instead of making you struggle with the accidental complexity introduced by problematically-designed tools. Many popular tools emphasize ease-of-use through looking familiar in a few narrow situations instead of emphasizing overall end-to-end simplicity which -- after a short learning curve for Mithril -- leads to greater overall ease-of-use in most situations." And a key point from the conclusion: "The fact that Leo Horie's Mithril -- a project started by one brilliant, kind, and generous person and now supported by a few volunteers -- can attract as much interest and support as it does relative to Facebook's React and Google's Angular (both backed by millions of dollars of paid development and free publicity) implies a lot about Mithril's technical advantages and developer ergonomics." As another example, over the winter vacation, I helped my kid make an interface in Mithril+HyperScript+Tachyons as a graphical memory monitor for Windows with a simple Node.js backend. He had essentially never used JavaScript before but had previous used Lua for game scripting, C++ for the Arduino, and a bit of Java for Minecraft. And while he still would have a lot to learn about HTML/CSS/JavaScript to do Web UI stuff entirely on his own, now at least he knows he could build more such interfaces -- including for embedded devices. Mithril+HyperScript+Tachyons essentially just was so easy to use and explain that it got out of the way -- and so almost all our time was spent discussing JavaScript issues, and the application design, and other libraries the application needed. That ease of learning Mithril shows how it is a mistake for management to choose React on the assumption that they need to pick the most popular platform to have the easiest hiring of developers. Mithril's short learning curve means even if you need to hire UI developers who have never used Mithril, any reasonably competent developer can get up to speed quickly. In short, Mithril+HyperScript+Tachyons(OrOtherAtomicCSS) is an awesome combination that is much more fun to develop in than React. You rock, Leo!!! Thanks again for making the programming world a better place.
In Alternative lightweight UI library to modern day frameworks
I outline in a ~20 page whitepaper why Mithril for JavaScript/TypeScript UIs (plus Tachyons for Atomic CSS) is a better choice over React and Angular for Single-Page Applications based on experience with all three: https://github.com/pdfernhout/choose-mithril "tl;dr: Choose Mithril whenever you can for JavaScript UI development because Mithril is overall easier to use, understand, debug, refactor, and maintain than most other JavaScript-based UI systems. That ease of use is due to Mithril's design emphasis on appropriate simplicity – including by leveraging the power of JavaScript to define UIs instead of using an adhoc templating system. Mithril helps you focus on the essential complexity of UI development instead of making you struggle with the accidental complexity introduced by problematically-designed tools. Many popular tools emphas
Read the rest
ize ease-of-use through looking familiar in a few narrow situations instead of emphasizing overall end-to-end simplicity which -- after a short learning curve for Mithril -- leads to greater overall ease-of-use in most situations. ..." Two key points there are that React's setState(..) approach to minimize redrawing is a premature optimization (which then leads to wastelands of endless opaque boilerplate like Redux) -- and also JSX is completely unnecessary and counter-productive compared to just using HyperScript API to define interfaces in plain JavaScript/TypeScript without needing to introduce extra compilation steps or more complex tooling. Another key point is that Atomic CSS like Tachyons and similar approaches obviates the need for all kinds of specialized CSS encapsulation complexity. Mithril and Tachyons leverage the flexibility of HTML, JavaScript, and CSS without trying to reinvent too many other complex layers above them -- layers which typically just create more problems in the end via accidental complexity unrelated to actually creating UIs. In general that analysis applies to most current JavaScript-based UI libraries. Elm (which perhaps helped inspire Mithril as a vdom) or ClojureScript or other similar tools might be exceptions though for people willing to put the time into learning those languages (which compile to JavaScript) and dealing with integration issues. So, in reading the article and also much discussion here and elsewhere, much of that verbage to my mind fits into the category of seeing (yet again) inexperienced or otherwise constrained developers picking one problematical tool and struggling with it and then jumping to another one with different (perhaps lesser) issues again without having broadly surveyed what is out there or understanding key concerns like simplicity. Of course what is much more painful is working in organizations where such faddish choices are then forced on developers who know better (as is often the case, including sadly why I know so much about Angular and React even after years of experience using Mithril successfully). That said, once a critical amount of time and money has been spend in getting developers to use a particular solution like React, then yes, there is the sunk cost which makes it easier for an organization to do other projects in it and maintain them. Just like why a lot of other legacy software persists... Just like Facebook could promote React aggressively over alternatives (even when React had the problematical patents clause in its license), I'm reminded a bit of when Java overtook Smalltalk in part due to huge amounts of money pumped into advertising and promoting it (including by IBM, which ironically eventually had two good Smalltalks of its own). Every tool has its strengths and weaknesses in different situations (including Mithril and Tachyons). And I can accept that broad industry adoption is a plus for any tool for availability of developers and third-party libraries. Still, it's sad for me -- after having implemented UIs for about four decades in hundreds of different ways -- that when I find something like Mithril that works really well for current needs and has (all things considered) great developer ergonomics and a great (if small) supporting community, it is mostly ignored. While Mithril+Tachyons+ES7 works differently than Smalltalk and related UI libraries, that combination makes UI development almost as fun as it was in Smalltalk -- but with broader reach because HTML+CSS+JavaScript is now everywhere. For good or bad, I guess Mithril will remain a "secret weapon" like Smalltalk used to be. :-)
In No One Ever Got Fired for Choosing React
Try using plain ES7+ (with async/await) JavaScript with Mithril (for defining components and their behaviors) and Tachyons (for Atomic CSS for styling). I like that combination best after having used Smalltalk and a variety of GUI builders (including Delphi and ones for Smalltalk and NewtonScript) and Angular and React. (TypeScript is OK too for bigger projects where documenting interfaces wins out over speed of development in plain JavaScript...) And having dealt with GUI builders with special formats and coding implication related to objects sending special events, I'd much rather just write plain code in one language in a text editor than wrestle with a limited WYSIWYG tool. Mithril's brilliance is assuming the UI is dirty if you have touched it in some way (mouse click, keystroke, etc.) and always rerendering after the event is handle
Read the rest
d (except if you want to optimize that). That leads to UI code which is much easier to reason about than arbitrary networks of dependencies like older UI toolkits emphasized. That style of UI development feels a lot more like, say, programming a continually-rerendering video game in for OpenGL than programming a dependency-based UI for VisualWorks/NeXTSTEP/Delphi/VB/etc.. More on all that by me: https://github.com/pdfernhout/choose-mithril "tl;dr: Choose Mithril whenever you can for JavaScript UI development because Mithril is overall easier to use, understand, debug, refactor, and maintain than most other JavaScript-based UI systems. That ease of use is due to Mithril's design emphasis on appropriate simplicity – including by leveraging the power of JavaScript to define UIs instead of using an adhoc templating system. Mithril helps you focus on the essential complexity of UI development instead of making you struggle with the accidental complexity introduced by problematically-designed tools. Many popular tools emphasize ease-of-use through looking familiar in a few narrow situations instead of emphasizing overall end-to-end simplicity which -- after a short learning curve for Mithril -- leads to greater overall ease-of-use in most situations." And I say that even having been an official NeXTSTEP developer once upon a time -- after I gave Steve Jobs my business card when I met him after he gave a talk at Princeton and he got me into the developer program (after my paperwork to join that developer program had previously apparently been ignored with its aspiration to build a system where any piece of data could be linked to any other piece of data). Even reading through all the glorious NeXT developer info, I never felt I could afford the NeXT hardware though as much as I wanted it (the short warranty gave me pause too) -- so my career as an independent software developer went in different directions. After reading the article and comments here, I can wish I had just thought to go work for NeXT instead of wanting to be a customer...
In What was it like to be a software engineer at NeXT?

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.