
Mithril.js – A modern client-side Javascript framework - dammitfoo
https://mithril.js.org/
======
duval
I credit mithril and it’s fantastic community of knowledgeable devs with
really changing my learning style at the outset of my dev career. Essentially
from learning by reading, and becoming overwhelmed (as is often reported in
the js world), to learning by doing and using technology. I’m sure this
happens to many other people through different routes but I personally
experienced it through this community. Seeing people so actively discuss
things with new users and the amount of other general interesting discussion
that happens in the mithril Gitter channel makes it one of my favourite places
on the web. There is a strong desire for simplicity and a strong anti bloat
sentiment from the devs over there. I like it a lot. I’m referring to you,
Pygy, Leo, tivac, barney, porsager, jaforbes and foxdonut. I have built and
deployed a few mithril apps in production early in my career and I’m glad I
had the chance. I wonder now how new js devs starting with frameworks like vue
can learn to work with the language rather than than the framework when every
part of it is wrapped up in a reactivity system. I would worry that a lot of
vue devs would come to mithril and not understand why the string literals they
are passing down to components are not being set in the parent.

Anyway that’s enough. Cheers to mithril and it’s great devs, if you like
mithril check out bss and Wright from porsager and meiosis from Foxdonut.

~~~
RodericDay
Second this. Mithril.js is absolutely incredible, and my coworkers are often
surprised at how quickly I can dive into a React project and fix an issue
because I don't carry the baggage of doing things "the react way".

Every now and then I use software tools where rather than complaining about
how x or y should be different, everything seems to be the best possible
version of something I'd have come up with myself, and I have zero complaints.
Mithril.js is one of those tools.

You're not "in a Mithril project", you're basically just using javascript but
the VDOM is expertly and minimally handled by some key functions.

Participating in the project via Gitter was very welcoming as well. Long live
Mithril!

~~~
shady-lady
> can dive into a React project and fix an issue because I don't carry the
> baggage of doing things "the react way".

Would they not want your solution to conform to existing solutions; which
(regardless of being idiomatic to React) would be idiomatic to the codebase?

~~~
RodericDay
I usually find the issue, point it out, then they make sure they implement the
fix in a way that is not alien to their codebase.

It's not many hands on one project but everyone taking care of their own
projects, so it's a bit different where I'm at right now.

~~~
Rapzid
Some people are way better at finding issues than others, even in other's code
bases.

Another good skill to have though, that is unfortunately not super duper
common either, is being able to figure out and match conventions and patterns
in code bases when introducing changes.

------
no_wizard
Of course what I am about to say is my opinion

I have nothing but great things to say about mithril. It has a wonderful and
well documented API that maintains simplicity but manages to cover the entire
project (no hidden APIs or undocumented features) to the credit of the mithril
community the focus in simplicity is grained into the project from the bottom
up.

I have to say that it’s been nothing short of amazing and is the reason I took
JavaScript much more seriously.

The community is awesome and very welcoming. The gitter chat is always active
and people are happy to chat and answer questions. I credit them with being
able to move quickly with mithril.

At my job my entire team uses it and everyone so far has loved it. It’s been
great!

------
anderspitman
I love Mithril. I would encourage every React/Vue developer to try it for a
small project. Not to convince them to switch (I use all 3), but because I
think using tools designed by smart people with a minimal mindset is valuable.
Also I really like the hyperscript approach. It just fits my brain.

Last I checked, Mithril hyperscript couldn't handle SVG, which is a non-
starter for dataviz work. Anyone know if that's still the case?

~~~
porsager
Yeah, hyperscript really doesn't get the attention it deserves.

SVG works fine with Mithril now, and has for a while. Here's a quick sample:
[https://flems.io/#0=N4IgZglgNgpgziAXAbVAOwIYFsZJAOgAsAXLKEAG...](https://flems.io/#0=N4IgZglgNgpgziAXAbVAOwIYFsZJAOgAsAXLKEAGhAGMB7NYmBvEAXwvW10QICsEqdBk2J4s+LLQCuDABQATWtSk4G+AEa15ATwoACYAB00evQDcIMAO6I9sgJR6AvAD5jp01lkByOGYDm3vpGJh6mFtYADrQATsS23gAMeskAjIlpGUHuHuw5YV7e1BAx1LDIkFBQTjEw8gC6yNQAHk4ArImN1NrtncgxvfXe9hT5HoW11MRBBmNhlVAJ6lBSMNmhYabNth2jG5vaO4l7mx5WEPLEhLbpx3MehDAQ-
iQ3Gfes9mNfaJ+UNLQsJFoDAYnh1Bh1DByFQ4NCYFMIPQEDx0ohUgBONgcECYHB4fDUOACAHCZg8Nj1KhQCBoADWKNQuK4YggVxi0H+Uhi5B4JGIkTgiAA9MKZJE6f5CYDhVg2YQOVAAAKpfCqgBssvlivw-H+xG0kW4IDg1A5kVErHqrCAA)

~~~
anderspitman
That's great to hear. I'm almost wondering if I'm getting my history mixed up.
Maybe it did work when I tried it (~ a year ago) but I just stumbled on old
information and gave up.

Or maybe I'm thinking of a different hyperscript implementation.

------
piotrkubisa
It is great to see Mithril again on front page of HN, it is one of the most
simplest and easiest modern JS frameworks. I only know flarum [0] as a project
which has used Mithril mixed with jQuery [1] and personally, I am quite amazed
how snappy it is.

[0]: [https://discuss.flarum.org/](https://discuss.flarum.org/)

[1]:
[https://github.com/flarum/core/blob/master/js/package.json](https://github.com/flarum/core/blob/master/js/package.json)

~~~
porsager
Lichobile[0] (lichess[1] mobile version) is also made with mithril.

There's also [https://flems.io](https://flems.io) a snappy web playground with
an open source embeddable core[2] ( shameless self promotion :P )

[0]:
[https://github.com/veloce/lichobile](https://github.com/veloce/lichobile)

[1]: [http://lichess.org](http://lichess.org)

[2]: [https://github.com/porsager/flems](https://github.com/porsager/flems)

------
anonytrary
Mithril is probably my favorite widget framework. I will still use React for
larger applications because of the breadth of third-party modules. That said,
Mithril and Preact start to make me question React. I'm sure a React developer
would say that 10k LOC and 70MB worth of repository is completely necessary
for the functioning of React, but part of me thinks there are too many cooks
and only one pot. React is elegant, but I don't think its abstractions are
simple enough.

------
nogridbag
I recently rediscovered Mithril.

I needed to build a fairly complex tree-table in our legacy ES5 app and I
initially turned to Vue to build the first prototype. I'm a big fan of Vue,
but for the first time with Vue I found myself really fighting against the
framework. In particular Vue's templating system and lack of template
fragments make it hard to create complex HTML table elements as they require a
strict structure. Another issue is our ES5 app already has its own build
system so we'd either be stuck with using Vue without Webpack (which in Vue is
a really inferior experience) or attempting to use both build systems which is
a bit cumbersome.

While researching Vue template fragments I discovered Mithril has had support
for fragments since its inception (React recently also added support for
fragments). I had always discounted Mithril. I'm not sure why. Perhaps it's
the simple homepage, the seemingly brief documentation, hyperscript, or the
lack of HN hype. Wow was I ever so wrong. The documentation is short because
the API surface area is tiny and this is a GOOD thing. I never felt like I was
writing framework code or trying to figure out the Mithril way of doing
things. It pretty much gets out of your way. Hyperscript, which I thought I
would hate, turned out to be one of my favorite parts of using Mithril
especially when I paired it with Tailwind CSS. Since Hyperscript is pure
JavaScript, doesn't require a build step, and is the standard way of writing
Mithril components, integrating Mithril into our legacy JS app was absolutely
dead simple.

------
Artemix
I've been using it for some time now, and the biggest plus for me, besides the
very simple to understand API and the manual redraw feature, is the ease one
can find setting it up for a project.

Even with webpack or some other complex bundle, someone without any formation
can really quickly set it up and get to code without worrying much about the
internals of webpack etc.

~~~
dammitfoo
Yes, exactly. Using JSX is also easy for development purposes if you don't
like hyperscript syntax. Just add babel.min.js file and use

    
    
      <script src="https://unpkg.com/babel-standalone@6/babel.min.js"></script>
      <script type="text/jsx">
      /** @jsx m */
      // your can use jsx here
      </script>
    

and bingo! You can use JSX. No need to use npm, webpack, etc.

~~~
nkkollaw
Setting up Webpack manually is a pain, but honestly if one uses create-react-
app, everything is done for you and you just start coding your app: you have
transpiling of ES6 (at least, I don't know about ES7), you can install and
include other packages, etc. etc.

~~~
dammitfoo
True. If you're creating an app that will be used in production then of course
you need to use npm, webpack and other tools.

But if you're new to a framework and just want to experiment then being able
to create an html file with a couple of script tags and writing code removes
many barriers to entry.

React, Vue and many others already offer this, I thought it was worth
mentioning that Mithril does this too.

~~~
nkkollaw
I don't know. Creating the HTML file, finding a CDN, and adding script tags
take more than:

npx create-react-app MyApp

There is nothing to install, and you have a complete playground to experiment.

~~~
porsager
[https://flems.io/mithril](https://flems.io/mithril)

That link preloads mithril in a web playground and you're ready to go in a
couple of seconds. You can even download and continue development locally
should the need arise - without the gorilla and the jungle hiding behind it.

------
untog
A lighter-weight and largely API-compatible replacement for React: Preact.

[https://preactjs.com/](https://preactjs.com/)

~~~
dammitfoo
Sure. If you still want to be React-like, that is! But React, Preact are still
view libraries right? Mithril is a (reasonably) complete framework. It's
sufficiently similar to React that if you know React, you can get productive
in Mithril very fast. I guess mithril is for people who want a full framework
with no fluff that gets out of the way.

~~~
allover
> But React, Preact are still view libraries right?

No, they're component-oriented. View suggests you're doing MVC or similar. You
don't need an M & C with React -- you will likely need to add react-router,
but react + react-router (or preact + preact-router) is all the 'framework'
you need for most apps.

~~~
dammitfoo
Ok. For that matter, Mithril is also component-oriented and router is
included.

And what I meant by react being a view library is that react by itself only
handles the UI part and you need to get additional libraries to handle stuff
like routing and talking with the server. This stuff is provided by mithril
itself.

------
rajangdavis
Haven't used it in a while, but it definitely shaped my understanding about
functional programming as it relates to javascript.

~~~
dammitfoo
I had a similar experience. It made me understand how front-end javascript
frameworks actually work (in general). The no-fluff approach taken by the
framework meant that code was clear and descriptive docs helped (reminds me of
Django's docs sometimes). I wish there were more tutorials though.

------
kylnew
Loved mithril when I used it a few years ago. Simple clean and effective. The
source code was very straight forward if you needed to investigate deeper.

------
kevsim
Looks interesting, but I found the fact that they say

| Be wary of aggressive performance claims, as benchmarks used by some of
these projects are known to be out-of-date and flawed (in the sense that they
can be - and are - exploited)

on a page full of aggressive performance claims[0] slightly ironic

[0][https://mithril.js.org/framework-
comparison.html](https://mithril.js.org/framework-comparison.html)

~~~
pygy_
Mithil maintainer here.

Guilty as charged. That page hasn't been updated since the v1.0 release, we've
been focusing on code improvements.

V2 is around the corner (mostly bug fixes, some of which required subtle
breaking changes (i.e. things that most users won't run into but it would not
have been honest to make it a minor semver bump). We'll revisit the home page
before the release.

~~~
ameen
Do you accept PRs for website and documentation? Thanks!

~~~
duval
Mithril has a very open and inviting community and will definitely accept PRs.
I reccomend popping into the Gitter channel if you’d like to discuss things
further

------
DougHo
This follows Reacts style of 'functions instead of templates'. I don't think
it's a good idea.

I think React will be the Java of our time. It caters to engineers who want
everything to be well defined and typed. And to large corporations which don't
care about heavy build processes.

Looking at what happened to Java: It's still used a lot. But not by new and
exciting companies or indie developers.

I think we will see the same with React. It will stay around for decades. But
the exciting new projects of the next ten, twenty years will not be written in
it. They will be written by lighter tech stacks. Just like FB was initially
not written in strictly typed Java but in loosely typed PHP.

~~~
skrebbel
You might be right, but I think you underestimate how lightweight React felt
compared to all the alternatives when it was first released.

------
ynniv
An even smaller framework that doesn't have its own components (I use
bootstrap with it): [https://maquettejs.org/](https://maquettejs.org/)

------
oweiler
Nowadays I'd recommend HyperApp over mithril.js.

~~~
dammitfoo
I'm asking why you prefer hyperapp because Mithril has router and xhr
capability built-in, and hyperapp doesn't seem to have those features. But
hyperapp is really tiny though. :-)

~~~
oweiler
Because HyperApp also has state management built in.

~~~
The_suffocated
If I understand correctly, HyperApp enforces the so-called SAM pattern, but
that's it. Calling this "state management" seems to me an exaggeration. And
why would one use a view framework to do (domain/application) state
management? It doesn't sound right.

------
xrd
Can someone summarize with an example that shows why this has benefits over
React? I read the first few examples and it seems simple enough, but I've
bought into the whole JSX benefit and don't see how those first few examples
allow me to write less code and code that is closer to the HTML I'll
eventually be rendering. Is it the tooling that mithril allows me to forget
about? Is it _something special that mithril gives me_ a novice who doesn't
realize I'm being held back by using React?

~~~
lhorie
(Mithril author here)

Usually, what I hear from folks is that you come out of using Mithril with
more transferable knowledge than something like React.

One example that comes to mind was when someone realized you could implement
an incredibly simple atomic CSS composition framework by basically doing this:

    
    
        /* some atomic CSS */
        .primary-color-700 {color:blue;}
        .pad-700 {padding:1em;}
    
        /* a bog standard CSS selector string */
        const MyWidget = '.primary-color-700.pad-700';
    
        /* a Mithril element */
        m(MyWidget) // <MyWidget /> in JSX
    

So you can get a fairly aggressive CSS optimization scheme for basically free,
and you can iteratively improve the quality of your atomic CSS as you learn
more about plain CSS / semantic taxonomy practices. And meanwhile, you're
still just writing bog standard CSS and Mithril templates. There's no compile-
time shenanigans to dedupe styles, no extra library runtime, and CSS is
actually CSS so if you server-render you stay on the browser's streaming
rendering happy path instead of waiting blocked on scripts.

Now compare with what one would do with most frameworks: one would pick some
CSS-in-JS library, get things done and over with, but probably learn nothing
interesting in the process and have little idea of what sort of code is
actually getting shipped to customers.

~~~
xrd
This is really useful. Thank you.

------
Bondifrench
As web-development is not my primary trade, I found that MithrilJs was the
right amount of abstraction to get into it. Small API, modular, as close to
Javascript as it could get and with the help of the folks in the Gitter
channel and the invaluable pearls of wisdom in Leo's blog in the earlier days
of the framework, my code became more functional and much more readable. For
me, it's kind of the swiss army knife of Frameworks.

------
pier25
The main problem with steering away from templates is that designers who know
HTML are immediately alienated from the code base. Same thing with CSS as
objects instead of using real CSS.

When working with libs that use HTML templates such as Vue, it's still
possible for designers to be integrated in the development process. But with
HyperScript, JSX, or Mithril, anyone contributing to the codebase has to know
JavaScript.

~~~
slaymaker1907
If they can’t learn basic JavaScript, they should not be touching the code
base with a ten foot pole. Designers can still design, but through mockups and
comments passed to people qualified to modify code.

~~~
pier25
If markup and styling are not in JavaScript, designers do not need to touch
JavaScript at all.

~~~
vanadium
This is where the whole fight over what "separation of concerns" in the front-
end means scores a clean point for the traditional definition.

------
MatekCopatek
Interesting, I don't have much experience with either, but I thought Mithril
was kinda succeeded by Aurelia, which makes it a less attractive choice for a
new project. Good to see there's still stuff going on.

~~~
bigmanwalter
Mithril is far superior to and simpler than Aurelia.

------
sebringj
Good thing designers have chrome DOM inspect. :) very terse script, nice idea.

------
tobyhinloopen
Why include XHR in a view framework?

~~~
idoubtit
You can use mithril.js without m.request, but then you have to dispatch redraw
events when you finished handling the request[^1]. It also provides a promise
API for web requests in old browsers, i.e. without fetch(). If I choose not to
use m.request, I would have to find another XMLHttpRequest wrapper and bind it
to Mithril.

[^1]: [https://mithril.js.org/autoredraw.html#after-
mrequest](https://mithril.js.org/autoredraw.html#after-mrequest)

------
the_new_guy_29
YAJSF ?

Yet-another-js-framework

~~~
cmx66
but a good one :D

