
Release of Mithril 1.0 - carlmungz
http://mithril.js.org/
======
gregmac
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](http://mithril.js.org/change-
log.html)

~~~
epidemian
> 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 :)

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

------
jarpineh
Shameful plug: For interested ClojureScripters there's my adapter:
[https://github.com/jussiarpalahti/mathom](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.

------
yomly
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

~~~
patricius
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](http://mithril.js.org/jsx.html)

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

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

~~~
lhorie
> 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).

~~~
baconomatic
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.

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

~~~
jbucaran
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](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.

~~~
jdubray
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.

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

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

~~~
pygy_
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.

