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

[dead-claudia]

Me:

1. It's fast. If it takes more than 100 ms to do the initial render (not pre-rendered) on something small, I have issues.
2. It's small. I'd rather load 8kb for a framework than 20kb< for a library (e.g. jQuery, React)
3. I don't like strong opinions. Mithril definitely has some opinions, but only on how to structure your views. React is so immutability-driven that it gets in the way of things, since JS is not naturally immutable. And don't get me started WRT Angular (especially 1)*, Backbone (why don't classes with explicit message handlers work?), or similar.
4. It's simple. I don't have to spend over a month just to start something. I don't need any special Yeoman generator template just to get the basics set up. Heck, I don't even need to preprocess my code at all, if I don't want to. Regardless, it's just as natural.
5. It's just JS, without most of the extra frameworky magic. When you learn Angular, you're learning how to program in Angular, not JS. If you're learning React, you have to learn JSX. The only DSL you need to learn with Mithril is with the views, but that's it. The controller is a plain JS class, nothing more.

* Well...Angular 2 is definitely an improvement in this front, but it's still not where it should be.

[JAForbes]

Thank you everyone for contributing. I'm suprised how singular the comments have been.
Even just overnight it seems we have a pretty clear consensus on why we choose mithril:

Many of you are extolling the virtues of it just being Javascript/not some opinionated framework DSL. And a related sentiment: the lack of build tool or complex setup.

There is clearly a lot of frustration within this community with framework and build tool burnout. And mithriljs solves that problem with a tiny api surface that is not prescriptive.

There is also clearly a similar frustration in the programming community at large. We probably all have witnessed opinions on the recent left-pad situation with npm, and Java programmers writing about how hard it is to get a simple app running these days. No matter how you see these events, there is clearly demand for exactly what mithril achieves.

I belive the key is to position it as a utility/library that replaces the need for a framework.
That mithril has something that many other framework's don't, elegance.

Elegance is beauty that shows unusual effectiveness and simplicity

Mithril is in a different category to larger frameworks, but just because it is a "micro framework" that doesn't mean you are settling for a less complete solution. I think we should avoid the word framework entirely, because it leads to playing a game Mithril won't win.

We should also make it clear large production codebases use Mithril instead of a larger framework, and that the world didn't end. It'd be great to feature RuneAudio, lichess, Guild Wars, Flarum etc on the home page to assuage any fears that mithril is only suited for hobby projects.

So please keep it coming! :)

[spacejack]

I really like Bondifrench's description. The big frameworks seem decidedly "not fun". Mithril was very enjoyable to discover. Several times I wrote a bit of code thinking "That couldn't be it? What else do I have to hook up?" and boom it worked.

By the way, I was kind of joking when I suggested sword & sorcery imagery. I mean, I'd be all for 70s van art style, but I could see how it might not be the right way to go. :)

[JAForbes]

@spacejack @Bondifrench

The big frameworks seem decidedly "not fun".

Yeah, I agree. Fun is maybe more important than any other factor. If we don't enjoy working with a tool we will write poor quality code / be depressed / give up.

[EirikBirkeland]

I think a lot of potential Mithril users would want to know "does it scale?". Angular and others may have its purpose somewhere, or maybe people are victim to the hype machine? If we can convince more people to get off the hype wagon and contribute to Mithril and help build a bigger ecosystem of packages, that would be great.

[ciscoheat]

I can get closer to MVC as it should be than with any other framework. Focus can be on your actual objects, when you skip viewmodels, that is. ;)

[ciscoheat]

@EirikBirkeland just curious, in what areas should/could Mithril scale?

[EirikBirkeland]

So, an argument would be that you can preserve a proper separation of concerns, which is currently not the case for some popular frameworks.

@ciscoheat What I had in mind is whether it's suitable for so-called "large" projects, e.g. a dev team of 5+ developers and a lot of code, like 100k+ lines, many iterations and shifting requirements along the way.

[ciscoheat]

@EirikBirkeland yes, where "proper" is not always separated, whereas the popular frameworks usually enforce a total M,V,C separation, and V is not even considered an object. Mithril keeps that open.

I see what you mean, I think it really is suitable for large projects (I explain why in the MVC article), the problem could be to make those large teams feeling comfortable with a small, clever tool like Mithril, instead of the sense of "security" from larger frameworks. A security that will eventually bite back, in my experience, because the focus will be on the structure, not the architecture.

Not wanting to start some raging debate here, but Drupal is a good example. A huge structure, hundreds of hours required to become proficient, but then you can do almost anything. But you can do that in less time with much simpler tools however, and then you will have more freedom, which is a double-edged sword of course. I think it's ultimately about trusting yourself, not a structure forcing you to think in a certain way.

Maybe the scope got larger than your question, but I'd use a framework with ideas like this for sure. :)

[pdfernhout]

@JAForbes I like your metaphoric comparison that Mithril (like its fictional namesake) is "Light, Flexible, Strong". I agree many people will not understand that Tolkien reference, so it should be made explicit.

@ciscoheat is insightful to say: "But you can do that in less time with much simpler tools however, and then you will have more freedom, which is a double-edged sword of course. I think it's ultimately about trusting yourself, not a structure forcing you to think in a certain way."

I like Mithril because it does not get in the way. Mithril makes it possible to leverage JavaScript/TypeScript to the full power of the language. I agree Mithril is "fun" in that sense.

Ultimately, a software developer in the web space needs to learn about the DOM, CSS, and JavaScript as well as some notions of good design. It is probably better to commit to learning all that up front (or as you go) using Mithril than to spend a lot of time learning a big framework which locks you in to its way of doing things and then may be passed by eventually. Even if one moves on from Mithril for some reason someday (given so much vdom innovation), the lessons learned using Mithril will be applicable to any web project. So, an investment in using Mithril is an investment in yourself as a web software developer -- not an investment in promoting somebody else's big all-encompassing complex framework.

Mithril itself is also easy to learn (aside from needing to know about DOM, CSS, and the basics of good design). If you write your code well (a big "if" in some situations), a Mithril application is probably easier to maintain for some new developer given the short learning curve of Mithril than if the web application was written in a big framework. This is because, with so many frameworks out there, it is likely the next developer will not know the specific framework you chose, and so they will have a big learning ahead of them to learn the framework before they can understand what the application code does or how to change it. If there was only one framework that might not be an issue, but there are several ones out there and new ones are constantly being written, making the odds low of a match between any random new developer and any chosen huge framework.

I also like working with the HyperScript API (which is "m" in Mithril and "h" in other libraries like Maquette or virtual-dom). Especially when using Mithril with TypeScript, I like that an IDE or the TypeScript compiler can flag errors that would not be obvious if much of the code was pushed into a separate HTML template. As someone coming to web development from many years working in languages like Java, Delphi, C++, and Python, I like that Mithril with HyperScript supports writing web UIs in a programming language -- not a markup language like HTML or XML where coding is an afterthought. And I say that having been on a team at IBM Research years ago helping implement and refine XML standards. :-)

I feel working with HTML-based templates is a holdover from the first days of the web compared to HyperScript. The days when a "designer" could modify HTML files used as templates to make significant changes to how an application works are fading away. We still need good designers, but I feel we should accept that designers will need to learn the HyperScript API (and a bit of programming to do that) if designers want to do more than just modify CSS files and provide wireframes and style guideline documents. I don't feel the lack of designers' programming abilities should be a limiting factor forcing programmers to spend a lot of time programming in what are essentially not programming languages (HTML templates like in many frameworks or XML templates like React's JSX).

That said, I'm developing in Angular2 right now to help out with a pre-existing project where I had no involvement in the technology choice. And I feel the Angular2 work takes longer and is more complex to understand and maintain than if I could be writing it in Mithril. Angular2 wants you to do everything the Angular2 way given its "change detection" (using "dirty checking" and enhancements), making it hard to integrate code written in other approaches into an Angular2 app (like code that generates reports from assembling HTML snippets). Angular2 does have some good points of course. But compared to Mithril, Angular2 feels mostly obsolete even though it is still in beta and has huge numbers of people working on it at Google and elsewhere. I miss Mithril. :-(

[barneycarroll]

@pdfernhout I deeply agree with everything you've just said. It's gratifying to hear you talk about the Hyperscript idiom as a sea-change in writing structured views vis-a-vis XML derivatives from a position of design investment in the latter — and in particular your assertion that it isn't unreasonable to conceive of 'designers' using it — since a large part of the sales strategy for monolithic web app frameworks rests on the assertion that it is inordinate to suggest that these designers are wedded to opening and closing tags with angle brackets: something I find disingenuous, condescending and fundamentally regressive in the scope of aspiration it sets for web design and development.

Not wanting to take this tangent too far, but I think it's worth noting what the sales pitch for monolithic web frameworks gives people:

• A managerial / tech lead ability to limit the scope of workers' abilities and remit, thanks to a dogmatic separation of concerns within API/DSL silos that restrict based on feasibility or the deferred wisdom of idioms decreed upstream.
• Deferring the scope of technical feasibility to an external entity with higher management buy-in.
• The ability to hire & fire and justify other managerial / technical decisions based on said scope.
• The ability for the worker bees in such a culture to both limit the scope of their responsibility and correspondingly overstate their ability based on deferred 3rd-party wisdom.

As much as I find all of the above fundamentally distasteful — as an ambitious craftsman, a teacher, and a consulting developer for hire in a thriving web economy — there's no denying the appeal of these things based on economic and political concerns that are often ingrained on a subliminal level.

For what it's worth, I really enjoy working with Mithril and conversing with and assisting people working with Mithril because so much of the above disappears — people will occasionally be drawn to Mithril and feel an urge to ask for help in bending Mithril towards these cultural trappings ("can I get this with classes?" and "why isn't the technical solution to the problem we just solved a simple API call?" are returning favourites) — but it's fundamentally easier to reason about people's tangible problems when dealing with Mithril precisely because it doesn't advertise itself on the basis of addressing issues rooted in political / cultural tangents. As such, I must admit to being ironically grateful that Mithril doesn't advertise itself as a competitor to these frameworks — which is not to say I think we should desist from finding more elegant ways of representing the library :)

[stffrd]

Semi-related re: getting some sweet look for it. These fonts make it look SO GOOD.

Hobbiton Brushhand (freeware license)

Elven Common Speak (freeware license)

[beukeshu]

Having worked with Angular/Backbone/React, Mithril had me because:

• When I read the documentation, it just made sense
• When I started using it, it just worked
• No magic
• Library not framework
• 0 to production code in less then 24 hours

[aardno]

@beukeshu

Agreed, 'it just works'. It is a framework though, but it's so unopinionated and small that it feels like a library.

[tinchoz49]

• If you need to find an Angular Developer, you have to search by: "Angular Developer" 👎
• If you need to find a Mithril Developer, you have to search by: "JavaScript Developer" 🚀

[aardno]

@tinchoz49 It really seems like teams want specialized developers and this is a growing trend I see. I know developer's don't like it, but sadly facebook and google are pushing this trend.

It's not the only reason, but I love how mithril's development is purely open source, not a corporate PR stunt or a race towards revolutionary.

To add to the discussion, mithril brings the pro's of both ember and react. We can jot out projects quickly which are also maintainable and fast with mithril.

[sjungwirth]

I ultimately chose to use it because the syntax is so much better than React's messy JSX. Fast, light, straightforward are all awesome bonuses.

[sebastiansandqvist]

One of the biggest benefits at first was the documentation. It is fantastic because it not only explains how Mithril can be used, but how applications can be structured well with Mithril.

I've also found that code written with Mithril tends to be very elegant and concise.

Before using Mithril I was very much into React. One of the things with React that bothered me was that there was so much bloat you'd need in order to have just a basic functioning app. Besides React itself, you'd need a way to manage state, you'd need a way to make ajax requests, you'd need React-Router, and likely another module to glue that together with the state (something like react-router-redux). And then the community would encourage also using Immutable js, and some flux implementation, and the list would go on. With almost zero application code, you could already have a 1MB application.

Mithril, while smaller/lighter/faster than React, came with almost everything I needed for a fairly complex application. With Mithril, I have more application code than library code, fewer dependencies, and a lot less to glue together. Not dealing with classes and not being forced to transpile just for a quick prototype were other perks. Performance improvements were icing on the cake.

[orbitbot]

I'd like to add that the gitter chat has been extremely responsive and active in helping out with any issues I have faced. Mithril allows developers to focus on solving their problem domain in a way that makes sense to them.

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