I used Mithril for a prototype app a couple years ago, and it was one of those projects that is awesome to get into: the documentation is short but complete, and you can basically learn it and produce a usable app in an afternoon.

One of the things I really liked is there's really no sense of 'magic': as I was learning it, it just clicked and I could basically picture how the framework had been implemented. So many times when I'm learning another framework/library it gets to the point where I just think "Whatever, I don't understand why I have to do this particular boilerplate and though it seems dumb to me, I'll just do it because that's the way it works".

Ultimately we ended up building with Vue (team decision, and I don't remember the precise reasons now) which is similar in many ways, but I did really enjoy Mithril. With 1.0 out I'm going to have to find an excuse to give it a shot again.

----

The changelog [1] is a great example of why the Mithril docs are so great. Each entry shows a code example of old and new usage.

[1] http://mithril.js.org/change-log.html

> One of the things I really liked is there's really no sense of 'magic'

Absolutely! And besides making it feel much less 'magic', Mithril's simplicity also reflects on the tooling, bundle sizes, and general code complexity needed to get things going.

I did a small-to-medium-sized project using Mithril last year, and felt like the learning curve was super smooth; no hard bumps at all. The development progress felt quite steady during the project, and the bundle sizes and speed of the app were always fine; it felt very snappy.

Recently i worked on a different project with a React+Redux (+react-router, +Glamor, +Babel, +Webpack, +whatnot) stack, and i don't know if it was the project itself that required so much more complexity, or that we made the wrong decisions regarding architecture, but everything felt bloated. Bundle sizes nearing the 1MB mark; "build" times of dozens of seconds on beefy development machines; and a level of boilerplate code that reminded me of my Java EE days (but with none of the type safety... besides React's verbose PropTypes).

I can't say i feel too hot about the current trends of front-end development :/

I hope that simpler libraries like Mithril get more traction :)

I've enjoyed Mithril for a while now, and you will be pleasantly surprised with the rewrite (i.e., the 1.0 version). It's different in quite a few ways and does away with the confusing controller concept for one thing.

But best of all might be lhorie's wisdom (and of course the contributors) that you can consume from the documentation.

Clear documentation and lack of magic are what I love about it too. I originally learned Mithril by porting an existing react app, and the newer version was so much easier to debug that I ended up keeping it. The amount of indirection in React makes subtle bugs very hard to localize.

That changelog is mind-bogglingly good

Thank you so much for making "What is Mithril?" the very first thing on your website!

> Mithril is a modern client-side Javascript framework for building Single Page Applications.

Shameful plug: For interested ClojureScripters there's my adapter: https://github.com/jussiarpalahti/mathom

I was looking at upgrading it to Mithril 1.0 this past weekend, but new Cljs release's new JS support landed just then. So, now I'm trying to deduce how to get my upgraded build configuration working again...

I believe you can pretty much write Mithril with Lisp/Clojure flawor:

    (nm "div"
      [(nm "h1" "Mithril app with data persistence")
       (nm "div" username)
       (nm "div" [(text "username" username 40 #(update :username %))
                  (nm "button.pure-button" {:onclick #(persist)} "Persist")])
       (nm "div" [(nm "textarea" {"rows" 10 "cols" 40} (get-item "data"))]))

Router and XHR/Ajax also work. I haven't yet used Mithril's components, but with 1.0 those too seem more straightforward.

This is a pretty cool library, for the people coming from React, the context switch for creating components needs not be so great:

For a stateless component which is implemented as a pure function, where you would normally write:

  myPText(myText) {
    return <p>{myText}</p>
  }

In mithril you would write:

  myPText(myText) {
    return m("p", myText)
  }

So the same vein of thinking can take you pretty far, but the benefit is that everything is Javascript so there is less context switching between framework and language!

EDIT: code snippet

Furthermore, you can easily use JSX in Mithril the way you do in React, and in React you can also use the JavaScript syntax instead of JSX (e.g. React.DOM.div).

Reference: http://mithril.js.org/jsx.html

A few month ago I was looking for a JS library for a SPA project. After days of WTF moments with those hip JS libraries and their insane tooling I was lucky to find Mithril. I was productive since day one with it. Thank you for providing this ray of hope in JS land.

Does Mithril implement something akin to Redux? Otherwise, I'd argue that those graphs related to size aren't quite correct.

Also, fetch isn't required for either React or Vue.js, could certainly just use the built XHR API to get down even further.

> Does Mithril implement something akin to Redux

Depends on what you mean by "akin". The core of Redux is just a few lines of code with a set of very opinionated conventions surrounding it, plus a bunch of utilities that people may or may not use. Angular's services serve a similar purpose to redux, but the approach is quite different. Mithril's idiomatic approach is similar to Redux in the sense that it's largely convention-based, but it doesn't actually require any specialized code. We could talk about non-idiomatic options, but from my observations, Redux is the most popular state management convention/library set for React and vuex is to Vue what Redux is to React.

In any case, were talking about a 2kb difference, so it's not like it makes that much of a difference.

Fetch is not required by any library, but a) realistically nobody uses the XHR API directly and b) projects typically do require XHR capabilities. If we're going to be removing things, note that Mithril and Angular are modular and can also be trimmed down if the comparison criteria involves removing things like XHR. Also, if "using the built-in XHR API" means re-inventing basic things like querystring parsing, then a library starts to look a lot more appealing again, and at that point, we're back to the point that Mithril's XHR utilities are smaller than most others that have comparable feature sets (e.g. Axios, superagent).

I'm not expecting there to be a huge difference, but it looks silly to include non-standard features for both React and Vue.

As for performance, do you have a setup that we could see that shows how those are generated? Just genuinely curious.

Well, maybe we just disagree on this point, but I think it makes more sense to compare apples to apples. To frame in a different way, given that Mithril isn't solely a view library, would you say it makes more sense to compare against a typical Backbone setup including dependencies like jQuery, or just compare against Marionette alone?

The performance numbers are explained in more detailed in the frameworks comparison page (they're dbmonster average render times). There are links to each implementation (they are all naive, using production-mode versions).

Perhaps we do disagree, that's okay! I think a fair comparison would be Mithril vs Backbone, but not necessarily with using jQuery as you could use Zepto.

I think it's really tough to do comparisons well and what it really comes down to, in my opinion, is how useful the library more so than the size and performance (within reason).

Also, my mistake on missing the links to the implementations in the comparison. Perhaps there needs to be a bit more contrast between the copy and the links?

Anyways, I've used Mithril and I think it's great, just wanted to make sure that the comparisons were fair.

Is redux considered "standard" in react land? I thought a lot of projects don't make use of it.

Redux is an opinionated implementation of the SAM pattern for React. The same pattern can be seen in the Elm Architecture.

• http://sam.js.org

Now, I don't know how old this pattern is, or whether it was already commonplace 15 years ago. I was introduced to these ideas first through Redux, then learned Elm, the found SAM.

I am the author of the SAM pattern. It is based on the semantics of the work of Dr. Leslie Lamport who got a Turing award for it (TLA+ - Temporal Logic of Actions). TLA+ was popularized by Amazon as a tool to help fix complex defects in AWS.

SAM fixes three approximations that we have been using in Software Engineering for Decades:

- actions can manipulate application state

- assignments are equivalent to mutation

- there is no need to define precisely what is a programming step (for instance when you write a = b + c, is that a step or is it 3 steps: read b,c, compute b+c, mutate the value of a)

To a certain degree, Redux and Elm are trying to address these three approximations as well, but they do it from a FP point of view, not from a TLA+ point of view.

Their definition of action aligns with the one of event and their approach to mutation is immutability. The main difference between SAM and Redux/Elm is the way side-effects are treated. SAM embraces side-effects (in particular asynch calls) while Redux/Elm don't know how to deal with them. Redux for instance breaks its principle #1 (single state tree) by introducing Sagas.

SAM is a factoring of your code that fits in one line of code: V = State(Model.present(Action(event))).then(nextAction)

No need for a nebula of libraries or inventing a whole new language.

Redux-thunk makes it async aware without breaking the convention.

Marcus Feitoza wrote an example of the SAM pattern with mithril https://jsfiddle.net/mfeitoza/pvdLkny7/

It is not, almost everything can follow SAM patern, but Redux, as is used by everyone, doesn't follow the pattern.

that is correct

I'd say it's a standard when you are getting into bigger applications, but the Redux docs do say that you might need it: http://redux.js.org/

So, I wouldn't consider it a standard for doing performance/size comparisons.

> Also, fetch isn't required for either React or Vue.js, could certainly just use the built XHR API to get down even further.

While true, Mithril does have an XHR interface built in, while Vue doesn't and I don't think React does, so it's a fair comparison to include those in the bundle.

Complete sidenote: Here is an example with something Redux-like done with Mithril:

https://github.com/lhorie/mithril.js/blob/next/examples/todo...

There's a stream lib (not included in core, it's a separate package), which fulfils some data flow concerns. The DbMonster implementation could have used those. TBH using Redux for DbMonster is a bit besides the point of the exercise IMO.

How does Mithril play with TypeScript? I am tempted to give it a shot...

There are unofficial typings, which will likely be merged at some point. The v0.2 branch had typings, but v1 is a rewite from scratch and those don't apply anymore.