[fortytw2]

I used to use mithril for almost every new project I'd start, but I've switched over to using React w/ Hooks for just about everything for two main reasons:

- toolchain support is a lot less finicky and better supported (you can use parcel and it "just works") - should I need to bring in a obnoxious third party library, it's far more likely to exist in a react world than mithril

If you're just building something small / on your own, mithril is definitely worth a shot though, it's relatively pleasant to use and packs in some very handy XHR related helpers

[lhorie]

I dunno, I see a lot of react codebases at my day job, and my experience is that libraries are all over the place. The really popular libs are often framework agnostic (e.g. lodash, date-fns, etc), but there's also a long tail of questionable quality libs: some react packages only work with webpack, some use unusual idioms (e.g. having to reference a node_modules path for some css, which doesn't fly with yarn 2), some are unmaintained, etc.

I've also seen cases where people were not aware that high quality vanilla libs exist, e.g. react-dnd vs dragula

There are a lot more wrapper libs for react, that is definitely true, but FWIW, I've come to despise them. Often you end up running into governance/versioning issues (e.g. one moving part releases a new version but you're stuck with the old one because a wrapper author doesn't have time to fix the breaking change, or are MIA, etc), or there are missing/broken pass-through options or whatever...

[pdfernhout]

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 components 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.

[filoeleven]

Hooks were what made me choose React to migrate to from AngularJS at work. I really like the concept of (state) => ui, but had no interest in react’s former class-based API. It was too complex. With hooks, I can write code in a more functional style, and even though they’re a little weird I think it results in more maintainable code.

I really wanted to push for using Reagent in Clojurescript, or something like re-frame that uses it, since CLJS has much better enforcement of and support for immutability-by-default and function composition. Everything that custom hooks do is handled by plain CLJS functions. It feels closer to meeting the design goals of React than React itself does, even with hooks.

It’s a hard sell though when I’m the only one at the company who knows the language. Maybe someday...