loading...

Why I choose Mithril.js

jcs224 profile image Joe Sweeney ・4 min read

These days, it's really difficult to choose a JavaScript framework to begin a new project. It would seem that React is the front-runner, but what about this revolutionary Vue thing? Should I use Angular because Google supports it, making it more appealing to large companies? But it's so much different from the original AngularJS... What about mobile development capabilities with React Native, or NativeScript? Would if React's license changes again? Should I switch?

Honestly, I find this decision-making pretty exhausting, but I also don't want to make the "wrong" choice. However, as I've learned with most things in life, I feel best when I make decisions based on my own values rather than what others purport to be the "correct" or "popular" choice. I've always felt like a little bit of a rebel, but it's only because I have specific requirements that the popular options don't fulfill. In the case of front-end frameworks, it can be quite difficult to objectively field whether a certain framework is best for my project or development style, simply because of the incredible marketing hyperbole behind each of these frameworks.

So, what would an ideal JavaScript framework look like to me?

Simple API

The fewer concepts I have to learn, the less guilty I feel about not knowing all the cool features I'm missing out on that probably aren't relevant to me anyway.

Great out-of-the-box performance

Nobody likes a slow site. And, as a developer, I don't want to have to work unreasonably hard to make a site performant. This should just be the default to start, while perhaps requiring a bit more care as the project grows.

Fast initial load

Less code in the library means saving precious bandwidth when loading it on a web page. This is especially important on mobile.

Doesn't require a build step

Many web pages on the web today are not single-page apps built with Webpack. Sometimes, I just want to throw some JS on a regular ol' web page to add a little bit of dynamic behavior.

Community support

It shouldn't be difficult to find help when I run into problems.

Encourages vanilla JavaScript

I don't believe we need to "apologize" for JavaScript by covering it up with a bunch of duplicate functionality that bloats the code and adds more overhead to our learning. I'd rather spend more time in the wonderful MDN docs learning proper JavaScript.

Interacts with other libraries easily

There is an extremely rich ecosystem of JavaScript libraries out there to help with all kinds of stuff. We shouldn't be afraid to use them if they don't have a framework-specific implementation.

So, is there a framework that satisfies all of these requirements, and more?

Well, yes, I believe there is! This would be a pretty unsatisfying article otherwise, wouldn't it?

Enter Mithril

For the last two years or so, I've quietly (or, sometimes not-so-quietly) been using Mithril in my day jobs where I had complete autonomy over the project at hand. I've used it to build tiny, internal company tools as well as a heavily-visited digital campus map for a university. I've used it both in the context of an existing PHP-rendered application without any sort of build chain, as well as a full-on single-page app with routing, ES6, hot-module reloading, and all that good stuff. It excels wonderfully in both scenarios, and it doesn't pressure anyone into a particular way of doing things.

Okay, enough soliloquy. Let's dive into some code.

This is basically the "Hello World" of Mithril:

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <meta http-equiv="X-UA-Compatible" content="ie=edge">
    <script src="https://cdnjs.cloudflare.com/ajax/libs/mithril/2.0.4/mithril.min.js"></script>
    <title>Hello, Dev!</title>
</head>
<body>
    <script>
        m.render(document.body, m('h1', 'Hello, Dev!'))
    </script>
</body>
</html>

While this example may not be very flashy, it is impressive how little code is needed to instantiate Mithril and render something.

Okay, let's try something a little bit more involved, if not quite common. Here is a todo list app, built with Mithril and Bulma. I'll attempt to demonstrate a complete implementation with as little code as possible:

There is a bit of code for a simple todo list, but the implementation of Mithril-specific stuff is quite low, in my opinion. There are a couple of functions for generating random IDs and finding the index of an object in an array by ID. There is also a data model for storing the todos, as well as logic for adding, deleting, completing, and uncompleting the todos. The only Mithril-specific code involves the layout and rendering of the component, which constructs a virtual DOM that outputs to HTML (similar to most of the other current major frameworks).

If you want to see an example of a Mithril app that I've built that's currently in production, check out the Montana State University digital campus map.

To sum it up, if you're happy with your existing front-end setup, just keep using that. No point switching from something you're comfortable with. But, if you are craving something a bit simpler, without giving up too many productivity benefits, I'll think you'll be quite delighted with it!

In future posts, I'll go over some of the more advanced and nitty-gritty features of Mithril. And, if any of you have more questions about the framework, comment here or in the excellent Mithril Gitter chatroom!

Posted on by:

jcs224 profile

Joe Sweeney

@jcs224

PHP/JavaScript developer professionally, moonlight hacker with a bunch of other stuff.

Discussion

markdown guide