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)

[maranomynet]

For me Mithril's small size and high power-to-weight ratio makes it ideal for writing all sorts of embedded widgets, that load fast and don't bog down a page that may already have ton's of HTML and other scripts running. Mithril's small API also makes it easy to learn and incredibly fun to play with. So a very satisfying, expressive library that delivers a nice punch.

[dead-claudia]

@Morklympious Not quite sold on those two fonts for the logo, BTW. In my opinion, a logo should be clearly readable and recognizable, but a highly stylized font doesn't really cut it.

[pygy]

Regarding team size, one of the advantages of Mithril is that it scales down remarkably.

I may be wrong, but it looks like most gitter regulars are solo devs or part of small teams. The posterchild being ornicar (the Lichess author).

I wonder how large are the teams of @lhorie and @tivac, and what methodologies they use to coördinate them.

[tivac]

My team is myself + 4 programmers. In general each programmer is working on a single project at a time by themselves though. We collaborate on all sorts of topics/problems but the day-to-day programming interaction is mostly 1:1 programmer:project.

[hugufc]

fast for free!

[maranomynet]

@isiahmeadows I agree about the logotype, but a stylized "M" (e.g. Hobbiton Brushhand) as a logo might be a nice touch.

[JAForbes]

@pygy this is a great sentiment, but also easily misinterpreted as a detriment in some circles. Some people may read "scales down" as "doesn't scale", even though the inverse is true. So wording is important.

I like how succint @hugufc last comment is, though saying a library is fast is like saying a browser is fast (it's not the main point of differentiation anymore because they are all fast). But I still like it.

I agree with @isiahmeadows. The fonts are cool but they don't read. @maranomynet Stylized M is a great idea though!

[aardno]

Since the name is mithril, it should be like a rock-style font with a hammer behind (hammers create mithril, right?)

Slogan/tagline recommendation should be 'MithrilJS - quaint with no restraints'

Selling point would be that mithril is the cornerstone of virtual dom and hypertext, giving the luxury of supporting up to ie6 while also maintains the speed and quality of modern frameworks, thus giving a well-rounded solution of 'keeping it all together' without 'the stress of tomorrow'. Let's hash this out, i'm not bad at these things.

[aardno]

Here are some font tests (freeware)

Rock it

D3 Stonism

I left out .js on purpose, and lowercase due to brand trends

[JAForbes]

@rdsteg We're not discussing how to design the site, or choosing fonts. Let's keep it on topic.

Selling point would be that mithril is the cornerstone of virtual dom and hypertext

Why is it the cornerstone of vdom and hypertext?

giving the luxury of supporting up to ie6 while also maintains the speed and quality of modern frameworks

I think this isn't differentiating mithril from many frameworks. But, I didn't know mithril supported ie6 and up, If so, that should be better advertised, but its also becoming less and less relevant every day.

Thus giving a well-rounded solution of 'keeping it all together' without 'the stress of tomorrow'. Let's hash this out, i'm not bad at these things.

I don't know what you mean by 'keeping it all together', honestly this just seems like puff. Let's keep it sincere and respect the intelligence of those we are communicating to.

The topic is: Why do we use this framework instead of another. Not: How can we best sell mithril.

[aardno]

I think you're taking 'selling point' without context, it's the reason to use mithril vs cito, vue, etc and why you should join the community. The whole point of is to attract users, right?

Anyways, if it's too vague then conjoin the minimalist features with the lowercase font and use mithril because 'its tiny, fast, and unopinionated'.

I don't know what you mean by 'keeping it all together', honestly this just seems like puff

Agreed, it doesn't mean anything. In respect to intelligence, the api speeks for itself, not the frontpage. Look at Haskells home, 'An advanced purely functional programming language' is their selling point.

Taking out the benchmark on the page and replacing it with a link to benchmarks is one step forward, but the tagline and design are more important

[dead-claudia]

@JAForbes @rdsteg @maranomynet

I wouldn't mind if you all decided to file a separate issue to discuss the design of the website. I like the idea of redesigning the website (the current one kind of sucks IMHO), but it's pretty off-topic here.

[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" :-1:
• If you need to find a Mithril Developer, you have to search by: "JavaScript Developer" :rocket:

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