Reasons we use Mithril

[JAForbes]

Hey everyone!

It would be very helpful if everyone could say 1 or 2 words that summarise why they use Mithril instead of another MVC library.

If anyone and everyone involved in Mithril could just say in 1 word why they use mithril instead of another library. Hopefully we could aggregate and come up with a clear message to help with a redesign of the site. We are all here for a reason, the task is to make our reasons concise and precise.

[barneycarroll]

A tiny, elegant API surface frees you to think about solutions to your problems instead of trying to frame them in the language of the framework.

[JAForbes]

My original critique of the site from gitter:

WRT the mithril site, I don't think it's entirely a design issue. It is also a messaging problem.
When someone comes to the page, they want 1 question answered quickly.
"Why do I use mithril instead of a dozen other frameworks?"
And I don't think that question is answered succinctly or clearly. Angular says ~"I'm just like HTML but better" - a great pitch for people who hate JS
Backbone said: ~"Traditional, Proven Structures brought to the browser" , which at the time was a great pitch when JS seemed like a fragile jquery Wild West.
Mithril says "Safe, Robust, Fast, Brilliant, Small" and also "A tool to organize your code"
So basically everything and nothing.
So what do we think is great about mithril, what sets it apart? Why are we all here? That has to be condensed into 3-4 words, and emphasised.
I think "A Javascript Framework for Building Brilliant Applications" doesn't actually say much.
The most on message aspect of mithril, is the name itself.
Mithril is a metal that is Light, Flexible, Strong. So emphasise that further. A lot of people won't know what Mithril is, so the connotation is lost.

[ACXgit]

We chose Mithril because we were looking for a framework with two main features first: to be able to perform very fast on rendering and to be versatile and small (in size, API and learning curve). Mithril is great at both, and much more.
For me learning Mithril has been more learning JavaScript rather than anything else, and I can certainly say I'm a better coder now thanks to it :)

[StephanHoyer]

no fucking magic

[EirikBirkeland]

Unopinionated

[tropperstyle]

Batman's utility belt - Everything you need at arms length, but you barely even notice it.

[reminyborg]

Everything is vanilla functional JavaScript. Refactoring becomes easy and enjoyable.

[tinchoz49]

Great documentation and simple API.

[darsain]

Apart of reasons above (simple + small + fast), also JS views (no need for template compilation) is huge for me.

[stffrd]

Clean and Simple.

[stffrd]

A lot of LOTR refs, also.

[reminyborg]

Great when using and building npm modules.

[cavemansspa]

spacejack @spacejack 14:24

@JAForbes "A Javascript Framework for forging Brilliant Applications"

Concept image for the website:

[EirikBirkeland]

I can do something in Mithril without needing 20 dependencies in my package.json.

A LOTR style reference / logo would work. Just look at the popularity of Browserify. Perhaps Mithril can be the mithril magic wand complement to Browserify's wizard's hat.

[Bondifrench]

The one that rules them all: fast, functional and fun javascript

[Draggha]

I dabbled with Backbone, Angular 1.x, Ember, React and regularly looked into the documentation of other libraries and frameworks anytime a new version came out.

What initially drew me to Mithril was the promise to be a small library that gives you structure and eases the burden of thinking about DOM updates. Back then I built my fair share of web components/widgets with ES3 and jQuery. Mithril not only lifted the burden of thinking about side effects (DOM updates) but also gave me a very tiny bit of (MVC) structure. But this tiny bit just nailed it. Let me explain what I mean:

• POJOs: Mithril takes plain old JavaScript objects and doesn't require any magic functions or event system to work.
• m.prop: You can use the built in factory function m.prop to build property accessors, which does indeed trigger updates on the DOM when its value changes. Property accessors are just getters/setters bundled in one function. Building them yourself is very easy aswell, because you have m.startComputation, m.endComputation and m.redraw at your disposal.
• m.startComputation, m.endComputation and m.redraw: These methods are easy to learn and despite their simplicity very very powerful thanks to the configurable redraw strategy. To me, this is the selling point of VDOM. Don't burden yourself with DOM update cycles until you really really need it. That's where the redraw strategies will come in handy.
• Components all the way down: The "structure" that mithril gives you is very focused and self contained. Everything is a component. Every component can incorporate other components.
• Controllers as the single source of truth to the public: If the controller doesn't expose it, then it's not part of your component's public interface. Since components are just functions: look at what it returns (or what properties it will be instantiated with).
• A robust router: It just works. No complex configuration. Just declare a route and feed it your component(s).
• "Hyperscript": Mithril's way of declaring your HTML is simpler than most. I don't need to learn a many different template syntaxes since Mithril uses just one: JavaScript!
• Debuggable: Since Mithril doesn't need a complex build system, event pipelines, dependency injection containers or the like it can be debugged like your hand written code. Trust in the robustness of the library - redrawing, routing and generating property accessors - and debug everything else. Because anything that's left is YOUR code. No need for complex testrunner configurations and everything can be as tightly or loosely coupled as you want it to. It's your call. (That's also a very good feature concerning refactoring)

No matter what I built with it, be it SPAs or just some widgets for static HTML sites, it has always been a pleasure, because debugging my own code and that of my colleagues is way easier without many different framework abstraction layers sprinkled in between. Since I spend more time reading, understanding, testing and debugging code than writing it I really appreciate Mithril unintrusive structure.

jQuery is the swiss army knife for DOM interactions. Easy to learn and use for enrichment of static HTML pages. If you need something outside of its API, just add it on top or build a plugin.
Mithril is the swiss army knife for virtual DOM component interactions. Easy to learn and use for enrichment of static and dynamic web pages. If you need something outside of its API just add it on top or build a component.

[ludbek]

Its simple, flexible and powerful ;)

[KasperTidemann]

I have used Mithril for a number of different projects, ranging from small proofs-of-concept to large platforms with a wide array of functionality and requirements for desktop, mobile etc.

I love Mithril for being so well-thought through and lightweight. It contains just the basic features needed to create a fully-fledged web app (components, routes, models etc.). It's such a pleasure to work with.

[lzztt]

1. simple:
   compare to AngularJS and React. I rewrote my AngularJS 1.* apps with Mithril, instead of Angular 2
2. extremely fast:
   it is much faster than AngularJS and React in my tests.

[tomodian]

Lightweight is king on mobile web apps.

[lhorie]

I think I got a pretty good sample of testimonials, so I'm gonna close this. Thanks everyone!

[PeterMwangiNjoroge]

no dependencies, robustness, simplicity

[GusBeare]

more approachable
leaner
simpler
conquerable
surmountable
heartening

As a newbie and having fiddled about with Angular, Vue etc I found Mithril much more approachable and less intimidating. Setup was quick and easy. I'm often put off by all the tools you need just to get started with js dev. Grunt, Gulp, Bower, Brunch, Browserify, Webpack etc etc. Christ, all I want to do is build a simple web app.

Gandalf help me! How did we end up here? If I ever look at someone else's js project I find it ten times more difficult to work out what it's doing than C# projects I look at. Why did anyone think it help anyone to make things exponentially more complicated?

I am grateful that I'm not the only one that wants a simple life. And yeah.. sorry.. I am getting emotional.

[dead-claudia]

I'm just going to leave this forever open...

[amedgit]

why do not someone make some tutorial on youtube? it helps a lot a new developer to know it ;)

[ciaoben]

Here my 2 cents, from the mithril's gitter chat

I discovered thanks to the guy behind rayfeed (https://rayfeed.com/). We are in a chat together and he told us that he was using this. So I looked it.. and find it really interesting. At my work we use React, I am happy with it but honestly is very verbose (especially with redux) and IMHO once you learn the basic concept behind it that React has brought to mainstream, you became "magically" a better web dev, and you are ready to move out and learn how to use these concepts using the native DOM APIs and other libs/framework that are more minimal.

I am trying to start a side project, and decided to move away from React, for these reasons:

• hundreds of hour on youtube of talks at Google conf and similar on how to ship less js to the browser and taking advantages of new APIs to build PWA. To me all this seems over-engineered, need to ship less js? start with the framework, mithril size is 8kb and has a lot of utilities in it to build 99% of today web app frontends. I want to have less code, less magic. I don't think that I will need ever to think about the size of a project like this is a problem and architecture hard ways to reduce it (to me is hard to accept that 100kb are a problem, the browser def need to be WAY better in this). I am sure to be safe with mithril's 8kb.s

• become a better dev: in my experience, React does not play well with other libs. If you chose React you will be locked to search forever "react-datepicker", "react-calendar", etc.. and hope to find a good/maintained lib (and usually, when you find them, these are pretty fat in size). You can use jquery and other libs plugins, isolating the DOM nodes used by them shouldComponentUpdate but in React there is something that makes you look dirty when you do this 😃. Obvs is a really stupid thing to say, but I find it
  toxic when the community is too much purist. We need to build experiences and things that work, that it.
  Mithril is way more minimal, leaves you space for the other libs (it take only 8 Kbs.. seriously.. this is great) and has less magic running under it so it makes me feel safer.

• the docs: when I've read the docs of mithril I've got emotional... an API for making request embedded in, pages that explain how to animate properly, etc... I find it amazing, to me, a person who wants to build stuff this is great. It is the first time that I find technical docs focused on the final experience and not too much on super tech, philosophical stuff.

Sorry for my poor english!

[ohenepee]

From a beginner mindset... after I heard about Web Frameworks and I wanted to learn one of them... I started seeing things like "React has a steep learning curve and Vue.js has the lowest learning curve", I also saw things like 1kB frameworks and the what-not... but the only things I really cared about was EASY TO LEARN & PERFORMANCE/BENCHMARKS... After trying out Vue, which took me over 5 days... I knew I wasn't perhaps understanding what lowest/low learning curve meant in Vue's case. That was no where near easy, maybe easy but took must to grasp, too much load, too many APIs, too many subsystems. When I learned Mithril (I did that several months before trying Vue.js btw), I finished it in under 100 minutes and built a production-facing app with it: so simple, so easy, such little mental/cognitive load, so little to learn. I recently tried that 1KB framework named HyperApp and that's a serious lie, they've just partitioned the codebase, an example is their router, its in a different repo, add all those other repos up and you'll get the big lie... I finished it in about 3 hours (its simple but t took me longer to grasp b'cos it wasn't interactive like Mithril's, so all I was doing was ready a plain old README.md on their repo), also coming with their v2 is a lot of bloat and cognitive load, so I ditched them and made this round trip back to Mithril.

I think the BEST selling point for Mithril is:
The easiest JavaScript Framework to learn, such little mental load, grasp the whole of Mithril in less than 60 minutes

The first phrase will pull a lot of beginners especially from Google Search for the search query "easiest javascript framework" (I can't remember how many times I've done that though and in all it brings up nothing meaningful, so I think its a great pitch)...

The above pitch is 99% possible for any web framework beginner who is already fluent in JavaScript.

[tomc278]

"Light as a feather, but as hard as dragon scales."

[ghost]

I think the best thing is what it doesn't have. No transpiler, no command line tool, no scaffolding. Just 8kb, a small API, and everything you need for the front end of an SPA.

[ww9]

Just wanted to say that Mithril is one of the best software I've had the pleasure to work with in my entire 20y+ dev career working both in backend and frontend. Some points that standout to me:

✅ truly small: No gotchas like needing to add extra 50kb of libs to do basic things like routing and requests.
✅ featureful yet simple: Events, routing, requests and dom diffing packaged in a coherent way.
✅ sensible conventions: Auto redraw after events and requests, m('text') just works when prototyping and other small things feels very ergonomic.
✅ mithril.js file is readable and hackable.
✅ low cognitive load: only one way to do most things. Concepts are simple enough to fit inside the mind within a week of practice.
✅ great documentation: concise but detailed. Contains both reference and idiomatic use guide.
✅ smooth learning curve: I'll suggest Mithril to every dev wanting to get started with SPA libs even if their end-goal is to learn Angular, Vue or React to use at work. I feel that Mithril doubles as a great way to get started with the mindset change required when writing SPAs using DOM diffing libs.
✅ really fast: The project I'm working on renders thousands of highly nested HTML elements at any given time with thousands of registered event handlers to build a very interactive UI. Yet it's so responsive that it feels like a fine-tuned static HTML+CSS page.
✅ low entry barrier: no JSX, ES6 or any transpiling required. I can't stress enough how important it for newcomers to be able to just copy-paste simple ES5 code into an index.html file and see it working without hassle. And then realize that production code doesn't have to be much different than what they just wrote.

I've either worked with or written Proof of Concepts in Angular, React and Vue before. Angular felt overengineered, often got in the way and node_modules from a simple Hello World reduced my hope in humanity a bit. React and Vue required unreasonable amounts of glue lib to do basic things, the end result was that their node_modules didn't looked much better either and it required extra discipline to keep code maintainable with helper libs being used all the time.

As someone who's on the far spectrum of code minimalism and pragmatism, frontend development was frustrating for years until recently when I had the chance to use Mithril in a new project at work. It's been nothing but success so far. Team is ahead of schedule, frontend code is simple, small and maintainable. Suddenly even interns can grok frontend code with little trouble and the faster Save-Refresh-View loop helps too. Most importantly, we're able to accommodate unplanned requirements easily because the code is simpler yet still fully componentized.

Thank you Mithril team and contributors.