Why I'm coding with Mithril

14 points by pelonpelon 11y ago ↗ HN

I have experience creating a very complex React app to organize a conference. It included registration, authentication, personalized schedules and calendars, news articles, up-to-the-minute updates, a store, physical pass(ID) verification, and a few dashboards for use by clients of my client. Honestly, it was a lovely experience.

Presently, 58% of users of my current client's site arrive via mobile and minified React tops 145kb, which takes a lot of time to deliver and unpack. I serve 1000 new users per week who can't rely on finding React in their browser cache. This is too much overhead. I am a little obsessed with under-one-second loading and 3 second attention spans. Non-minified React is 642kb and that's too much code for me to grok if I want to understand what my application is doing.

Then I found Mithril. It's faster than anything. It's tiny. It does only what it needs to do, no bloat. And it does most of the good stuff that React does. It's also FRP friendly, another current obsession of mine.

It's in the early stages, but it is so small and focused that it can be used anywhere. TODAY. mithril.js is small enough to understand in detail. Beyond the basic documentation is a blog and API docs written as precisely and as focused as the code. It's a testament to its quality that the earliest blog entries are applicable today. I recommend reading them from oldest to newest. They read more like a tutorial than a blog. Post a question to the Google Group and Leo will likely refer you back to a blog post because he's already covered your question.

Another sign that Mithril is of great quality: most public discussion about Mithril revolves around the philosophy and logic of app design, not code errors. When errors are discovered, Leo patches them within hours if not minutes.

Leo got so much right. Most things right. More than any other framework I know.

jf22 11y ago ↗

  todo.view = function() {
    return m("html", [
        m("body", [
            m("input"),
            m("button", "Add"),
            m("table", [
                m("tr", [
                    m("td", [
                        m("input[type=checkbox]")
                    ]),
                    m("td", "task description"),
                ])
            ])
        ])
    ]);
  };

That's some sample view code right?

The heck is that?

With IDE support being so good why would I ever subject myself to using non-html view code anymore? There is no way I want to do a complex site in that kind of syntax, that's just crazy.

insin 11y ago ↗

I tweaked React's JSX transformer to output Mithril-compatible code, so you don't have to deal with this sort of syntax:

https://github.com/insin/msx

Having done DOM building with nested function calls/arrays/objects for years prior to it, I can't go back to the necessary syntax-wrangling after having used JSX.

fellytone84 11y ago ↗

In my experience Javascript modes are usually as good or better than html/web modes so I don't think the problem is a lack of tooling.

As for the function, I'm curious to know what you get out of wrapping html in the m function.

lhorie 11y ago ↗

Hi, Mithril author here.

> With IDE support being so good why would I ever subject myself to using non-html view code anymore

As others have mentioned, preference for angled brackets can be solved with tooling. insin's MSX exists precisely to address this very concern, and it's dead simple to setup. As you might have noticed, Mithril's syntax is designed to look like the other language of the web: CSS. In practical terms, what this meant to me was to replace the usage of Emmett CSS-to-HTML expansion macro shortcuts in my text editor w/ a macro shortcut that spits out `m("")` instead. Coupled with simple IDE features like automatic bracket matching, I think you can get a typing experience that is very close to what is familiar to users of productivity tools like Jade/Haml/etc users (and with no preprocessor step required).

The actual reasons for templates to be pure js are slightly more technical: it gives better error reporting, proper scope/closure/variable shadowing rules, turing completeness (for the purposes of refactoring/abstraction, etc), it's friendlier to transpiled language users, it's lintable, it's compressable, it's statically analizable, etc.

Also, in my experience, complex apps tend to get heavier on logic than actual markup (this was actually the first thing my previous boss noticed when I gave him a simple code example when I was showing him the framework)