
Show HN: My new JavaScript MVC framework - lhorie
http://lhorie.github.io/mithril/
======
sergiotapia
I've become a huge fan of simple things. When I was just starting out
developing software, I was a big fan of huge integrated solutions. But as the
years went on I loved well scoped, lean options.

This is the reason why I like Backbone.JS instead of Angular. The reason why I
like Go instead of Java.

Mithril looks really promising! Don't let feature creep turn it into a
behemoth! Keep it lean and mean, and excel at the one thing it was made to do!

~~~
the_cat_kittles
I think this is the same taste-maturation that many woodworkers experience. At
first, you salivate over these crazy, overly specific, over engineered power
tools. Over time, you start to really love things that are stupidly simple
instead, like a card scraper, or a hand plane.

~~~
midas007
Cooking is the same way.

A few, simple, fresh ingredients prepared quickly and correctly can be much
more amazing than a complicated 20 ingredient recipe that takes 2 hours to
prepare.

------
lhorie
Hi, Mithril's author here. I'll just put a big comment here, and hopefully
everyone can see it.

@stronglikedan: I don't have plans for extending the core (in fact, keeping it
small and modular is a major focus point for me). I do have a list of things I
want to tackle next (see the roadmap page), but I'll most likely release them
separately from core.

@hcho: re: integrating w/ jQuery: see the integrating w/ other libraries page
in the guide section. There's a simple example w/ select2 there.

@abjorn: those are excellent points. Re: turing completeness: my take is that
things like good error messages in the view layer are more important than
trying to prevent people from doing stupid things (that's what code reviews
are for). Re: Bindings: I'm most familiar w/ Angular ones and yes, their bidi-
bindings are really convenient, but they fail in some 5-10% of the use cases
for me (either by being too aggressive or not expressive enough). So, that's a
conciseness vs power trade-off in design from my personal experience. Re:
templating, you can take the model-level utilities and integrate w/ other
templating libraries. I do provide some comparisons w/ React and a few other
frameworks in the misc section of the guide, as well as design rationales in
the main guide page. TL;DR I use other frameworks full-time and I've done
homework before I settled on the current implementation :)

@hanburglar I do provide a tool to convert HTML to Mithril (although not
automated yet), see the "useful tools" page.

@timmiwil: you're right, jQuery is not MVC (I mention this in the comparisons
page). The point is that with idiomatic jQuery, the app developer is
responsible for knowing when to use .text() instead of .html(), whereas with,
say, idiomatic Angular, that's not a concern, ever. jQuery "templating" tends
to get pretty hard to audit as widgets become more complex (see select2 source
code, for example)

@tzaman: I do contribute to Angular and other projects that I use as time
permits (mostly bug reports)

@BaconJuice: it's a side project, but a scratch-an-itch one that I work on
pretty much every night. Planning on continuing work on it for the foreseable
future. I'm also considering introducing it at my day job as well.

@all: thank you for the feedback, I really appreciate :)

~~~
pygy_
_> thank you for the feedback, I really appreciate :)_

Well, thanks for the framework :)

Apparently, you missed my (now deleted) question:

_> It would be nice if you could document the browser requirements._

We're even, since I had missed the answer, which lies at the very end of the
misc section of the documentation:

_> Mithril allows developers to support browsers all the way back to IE6 and
Blackberry._

Wow! This should IMO be on the home page.

    
    
        ----    ----    ----
    

_Edit: Is it possible, for SEO, to load Mithril with a pre-rendered page and
have it take over like React?_

~~~
phektus
>> Mithril allows developers to support browsers all the way back to IE6 and
Blackberry. > Wow! This should IMO be on the home page.

Agreed! I'm in!

------
EvanYou
Author of Vue.js here, I'm glad you included Vue in your framework
comparisons. Here's some thoughts regarding your comments on Vue.js: the
reason Vue chose to use ES5-only features is that it enables Vue to provide
plain POJO syntax without having to resort to dirty checking or virtual DOM
diffing. Granted the auto-magical POJO syntax is a somewhat leaky abstraction,
but I'd argue that not all leaky abstractions are bad (since by definition any
non-trivial abstractions are leaky) - it all depends on its leakiness vs. the
benefits provided by the abstraction. TCP is the canonical example of a leaky
abstraction in Spolsky's original post yet it has been the foundation of
everything we build on the web all along. In fact, even the concept of virtual
DOM is a leaky abstraction in itself. My point is, I don't think the leaky
abstraction argument raises anything inherently problematic about Vue.js.

That said, I really like the project because I'm also a big fan of simplicity.
Curious to see if there will be a TodoMVC implementation with Mithril for
easier horizontal comparisons of actual code.

~~~
jpmonette
There is a partial TodoMVC implementation available here -
[https://github.com/jpmonette/todomvc-
mithril](https://github.com/jpmonette/todomvc-mithril)

------
ulisesrmzroche
Have you successfully tried this out in a real app? Why would you want to
structure your dom inside an array? Seem pretty crazy, my dude.

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

~~~
chc
I think the idea is that it's simple — it's just a basic data structure in the
language and can be generated or manipulated with just simple JavaScript. This
is similar to why Lisp programs being Lisp data structures is interesting.
Intriguingly, it looks like the API is compatible with React's JSX. With that,
you could write this as:

    
    
      @jsx m
      todo.view = function(ctrl) {
          return (
            <html>
              <body>
                <input/>
                <button>Add</button>
                <table>
                  <tr>
                    <td><input type="checkbox"/></td>
                    <td>Desk description</td>
                  </tr>
                </table>
              </body>
            </html>
          );
      }

~~~
ulisesrmzroche
Adding some more css declarations, id, data-hooks, etc., and make it span 100+
lines, like in real life. Scares me just thinking about it.

~~~
chc
Are those things you wouldn't have to do under any other system, or which
would be significantly simpler there? Because I'm not seeing it. You seem to
be saying "This involves building a web page" — which is true, but would be
regardless.

~~~
ulisesrmzroche
Yes, it would be simplificantly simpler to edit html if it wasn't stuck in
between two strings, for one, let alone inside an array.

todo.view = function(ctrl) { return m("html", [ m("body class='application", [
m("input class='add input input-sm input-md"), m("button class='btn btn-
success button-green", "Add"), m("table class='table table-strped table-row",
[ m("tr class='tr'", [ m("td", [ m("input[type=checkbox] class='checkbox input
input-sm' id=firstName name=firstName") ]), m("td class='td", "task
description"), ]) ]) ]) ]); };

I honestly can't tell you what the hell that is supposed to be anymore. Also,
you guys are using invalid html for everything. Your example is not going to
validate on anything.

~~~
lhorie
I think you're too caught up on syntax and missing the big picture. The m()
method is simply a helper utility that returns a POJO. You can write the code
in coffeescript if js syntax bother you, or you can go nuclear and implement a
frontend or a preprocessor that take some popular templating syntax and spit
out the appropriate data structure. The conversion tool I provide is a small
step in that direction, but, with Mithril being at a mere v0.1, it still needs
more work done to be fully automated.

Also, just FYI, the selector syntax follows CSS rules, so you'd write
m("body.application"), not m("body class='application'")

~~~
ulisesrmzroche
Programs are for humans to read and only incidentally for computers to
execute. Syntax is the whole picture.

~~~
lhorie
Well, I already told you which directions Mithril can go in terms of making
syntax more to your liking. If you're too put off by js templates and not
willing to spend time helping push the project in a direction you like, you
can always try other frameworks or come back later when I have a more HTMLy
frontend option available.

------
abjorn
Overall I like it, except for the templates.

It's perfectly possible to not have FOUC with traditional template languages
like mustache, and I don't think having "turing completeness" in your
templates is a good thing. Frameworks like Ember.js have also shown that you
don't need to manually write bindings to handle when your models change.

That being said, I do see the advantage gained with the virtual DOM you
generate from the templates. I'd be interested to see if it was possible to
integrate other templating languages in via plugin.

~~~
jenius
Entirely agreed, this is what I was about to say as well. Being able to use
html templates for me makes apps much less confusing and much more organized.
Moving your html into your javascript just doesn't seem right. If there was a
way that it would accept a mustache/underscore/other precompiled template I'd
be all about it. But constructing html out of javascript functions and objects
just doesn't sit right with me.

~~~
hamburglar
I actually had the same thought, but I also get that some people don't like
HTML-based templates for various reasons. My next thought was whether or not
you could just augment this framework by providing a utility that converts an
HTML-based template into the view that mithril expects and make both camps
happy. As an optional contrib module, of course -- I'm not suggesting he start
heaping on additional framework features already. :)

edit: I just wanted to add that I read through the guide expecting to find yet
another half-baked framework but the whole thing seems well thought out and I
like the philosophy alluded to in the guide. I'm definitely going to try this
for my next mini-project.

~~~
abjorn
Well, there is such a tool, actually.
[http://lhorie.github.io/mithril/tools/template-
converter.htm...](http://lhorie.github.io/mithril/tools/template-
converter.html)

But while me and my coworker have been trying it out there seem to be quite a
few bugs with it, and I'd much rather have it done at runtime (precompiled for
production build) then have to translate it from my HTML-based template every
time I make a change.

~~~
lhorie
Can you file an issue on Github? I still need to make an automated version of
this tool (and eventually be able to import from something like Mustache), and
I want to make sure it's rock solid.

------
timmywil
The tests don't make sense. jQuery is not an MVC framework and should not be
tested as if it were. It's worth noting that both Backbone and Angular use
some version of jQuery (lite or otherwise), so comparing that to your own way
of using jQuery doesn't correlate. I could use jQuery to append elements in a
way that was much faster than and just as short as what you've done in your
test. Also, did you know you can append image elements with events using
document.appendChild? It must be a security issue! But seriously, don't even
include it in the tests. It is a JavaScript library that serves a lower-level
purpose than MVC frameworks.

~~~
JetSpiegel
It has reached the point where Javascript Framework coders don't know
Javascript.

Looks like Javascript IS the Assembly of the Web.

~~~
nawitus
But DOM is separate from JavaScript.

~~~
hmsimha
DOM is separate from Ecmascript, but is actually one of the 3 components of
Javascript (along with Ecmascript and the BOM). This is at least according to
_Professional Javascript for Web Developers_ (you can see it on 'page 3' in
the Amazon preview).

~~~
nawitus
The sources I've read (Douglas Crockford or Wikipedia) clearly state that DOM
is separate from JavaScript.

------
Tloewald
The approach we've taken in our anti-framework is that the model is your data
(and the code you use to manipulate the data), the view is your HTML/CSS (
_not_ a special templating language -- actual HTML), and the controller is
automatic for simple stuff and custom for complex stuff.

So the big example at the end of Mithril would, for us, be something like (we
implement binding as a jQuery extension)

$('.display').bind(data);

Where .display selects the root node of the bound UI, and data is our object.

Which is simpler and less code, I think. (Oh and our binding library has
jQuery as a dependency, but is sub 3kB minified and gzipped.)

That said, we haven't put our libraries on github yet :-(

~~~
buckbova
Sounds a bit like the pure js library but with jquery.

[http://beebole.com/pure/](http://beebole.com/pure/)

~~~
Tloewald
Ours is a fair bit more elegant and works both ways. It's also being used for
multiple pretty complex projects so it's reasonably "battle-tested" (although
nothing is in production yet, so not as battle-tested as it needs to be).

We also do not bind by class because that's a really bad idea. (Actually the
way we bind is a lot like Angular, but without being a templating language.)

A key design requirement is that the model does not get polluted with special
methods and properties to support the binding -- so (for example) if you have
nice RESTful services, you can GET, bind, edit, POST/PUT and everything just
works. For moderately complex cases we support "decorators" that live "off to
the side" (i.e. do not pollute the model). Again, you _can_ stick getters and
setters in your model if you want to, you just don't need to.

------
markovbling
your "getting started" page is like a crash course in building websites with
javascript - just forwarded it to a bunch of friends

it felt like you were giving a smart person a crash course in javascript

wish more apps sturctured their tutorials like this

great job!

One thing: it feels like it's aimed at people who are already competent at
javascript

but your tutorial isn't too many steps away from a being solid "javascript for
absolute beginners" guide

So would be cool if you made it slightly more beginner friendly, like I'm sure
you're losing a lot of engagment and users because they read the first line of
your guide and immediately think it's too complicated

"Mithril is a client-side Javascript MVC framework, i.e. it's a tool to make
application code divided into a data layer (called "Model"), a UI layer
(called View), and a glue layer (called Controller)"

Like I'd suggest adding a VERY simple sentence about why you'd want to use
javascript AT ALL

both on the guide and the start page

like if someone landed on your page and they were good at HTML and css but
never really programmed, they could probably use your framework to build their
first programming project if you made it a little more beginner-friendly

great work! :)

~~~
_dark_matter_
why don't you

use some punctuation and

not separate your thoughts out on different lines?

Not trying to be mean, this is just hard(er) to read!

~~~
markovbling
Sorry - hadn't planned on making my comment that long but will definitely keep
your feedback in mind next time I reply to a comment.

------
SNACKeR99
I am really interested in this, and am going to give it a go on my next
project. Its areas of responsibility are contained and well-defined, the
syntax is nicely concise, and it really feels like plain old javascript, which
gives me the comfort I can get under the hood if I need to, without massive
conceptual/abstraction overload.

If I am iffy on anything, it would be the templating language, but I suppose a
React-type HTML syntax could be optionally layered over top without
interfering with anything else. And there is something secure about
javascript-rendered HTML in that you are much less likely to have unclosed tag
issues, etc.

But for me, having experimented with some of the slower performers like
angular, performance is a huge draw, and I am willing to write my templates in
js if that's what it takes to get it.

------
Zelphyr
Here are my thoughts, but you won't like them. Stop with the frameworks. Learn
Javascript. Learn CSS. Learn HTML. You'll find pretty quickly that what you
need are _libraries_ , not frameworks. Things like jQuery, underscore, etc...

~~~
AznHisoka
That's similar to my viewpoint. Stop with all the frameworks - what new,
powerful functionality will it provide your users that existing things can't
do (ie JQuery, raw JS)?

~~~
snicker
the point of a framework is speedy development. less lines of code for
results. the tradeoff is often bloat, which one should (ideally) refactor out
later. Angular can get overwhelmingly slow if you're not careful with your
code, but gosh dang, you sure can whip an app up pretty fast

~~~
Bahamut
For most apps, I've found that slowness is not a problem with Angular. You can
do some nasty things though if you're not careful though, definitely agree
with that. If you have flaws elsewhere in your codebase, including the
backend, it may be possible that in practice, the effects may trickle down to
your frontend code with Angular - it has happened in an app I've worked on
with a couple of other developers, in which flaws with the api performance
caused us to implement some subpar workarounds that triggered many $digests &
forced us to spend a day or two on just optimization.

Angular can be quite fast compared to jQuery in an app of substance. It is not
constantly reading/writing to the DOM in most cases, which saves a lot on the
performance front. It is also a smaller library than jQuery, and you're not
naively applying global or complicated selectors. Plugins rewritten to be pure
javascript + Angular also can have a much smaller footprint & be more powerful
to boot, such as the Angular UI Bootstrap project (5 KB minified & gzipped as
opposed to 15-35 KB? I forget Bootstrap's js size) & contains all of the power
of Angular to modify your functionality with them & more.

------
scrrr
First impression after reading across the docs: Compact, fast, seems to
contain most important things. I like it.

~~~
stronglikedan
Unfortunately, they all start out this way it seems. Hopefully, this one will
remain this way.

~~~
tluyben2
The way to keep it that way is to never add even 1 new feature and only fix
bugs. That's not a bad idea actually; if you don't, it'll end up like _every_
other framework on earth. So it's a good niche to say 'this is it' and keep it
exactly like that even though it 'lacks features'.

~~~
stronglikedan
I like that idea. Keep the core frozen. With a good API, users can extend it
to their liking, and complicate it all they want.

~~~
iLoch
Sorta like Backbone... People definitely love adding plugins and definitely
don't count it as a negative when comparing to other JS MVC frameworks......

------
mtford
Looks very clean. Especially having just tried a read through the angular
docs. Bleurgh. Take the advice of the others in this thread and avoid bloating
this and maybe it will take off!

------
BaconJuice
Hi lhorie, I like this. I want to use this. How long will this supported is my
concern. Or is this a fun side hobby you worked on and plan on moving on to
the next with no future updates?

Cheers.

~~~
guywithabike
It's open source. You provide the support and updates.

------
boyaka
I've been using the dform library [link] to create my DOM. I'm creating an
input form used to query a database with PHP and generate a chart from the
data using FusionCharts. I've been considering utilizing frameworks to help
with form creation, manipulation, and query generation/execution/processing,
but I've decided to stick with just these two libraries for the former and raw
PHP for the latter. I also use PHP to enable/disable parts of my form via if's
and file includes.

I really like dform's flexibility. I have been able to add every HTML elements
that I've needed with the same syntax for every one, making it very simple to
stick them into PHP loops to generate the elements based on the query results.
I've learned a lot about writing jQuery functions while using it.

FusionCharts is very specific in what it does, and is compatible with many
languages. I have actually learned to use it's classes in both PHP and
JavaScript so that I can create any part of the chart I please in either
language, and it is capable of transmitting data in both JSON and XML even
though it uses XML internally. I've briefly taught myself the differences
between the formats and have gone from manually creating XML, to learning that
JSON is way better, to automatically converting my arrays into JSON data.

I feel that I've kept my project quite lean indeed, and was actually worried
about not accomplishing a lot, not being complex enough. But I have
intentionally been trying to avoid complexities so that I can make it easy to
pick up and use, just include jquery, dform, and the FusionCharts.js/.php (and
source code).

[link]
[https://github.com/daffl/jquery.dform](https://github.com/daffl/jquery.dform)

------
bjconlan
The templating language reminds me a little of what spacebars (htmljs)
probably looks like if a nice mustache facade wasn't put in front of it.
(which goes back to Gee's comment about react... but I guess anything these
days that promotes a 'virtual dom' will probably be tarnished with that brush
from first glance)

I love the simplicity and independent direction this micro-framework provides.
It's very 'non-magical' which I think makes it far more appealing.

If you end up solving the HATEOAS/ember-data sideloading/'embedded foreign key
data loading' problem I think this will be my goto library (though this
probably falls out of the microframework requirements also ;)

------
matthiasak
tiny, small, idiomatic javascript;

uses POJOs; has just enough 'binding'; uses routing and basic promise/A+
implementation.

I'd say this is good and as high level as one should go if they want to churn
really good performance out of an app.

Keep it coming mate, and link with me on Twitter. I used a number of micro
frameworks and my own glue to make my own mini-framework using much of the
same concepts, only I used a templating engine called doT instead of declaring
my HTML structure in JS (although I know it is easily possible to generate
view code with a tool/script with HTML as input).

@matthiasak mkeas dot org

------
fiatjaf
Aside from templates, this is the same as
[https://github.com/moot/riotjs](https://github.com/moot/riotjs)

~~~
explorigin
I thought riot relied on jQuery and was basically decreed to be more marketing
than substance. This seems to have a lot of substance.

------
maninalift
I like the small, unmagical, well-defined API.

That strength is also a weakness though. Particularly because for coffeescript
(or my favourite, the related LiveScript) it doesn't result in the super-cute
syntax of e.g. TeaCup[1][2].

[1] [https://github.com/goodeggs/teacup](https://github.com/goodeggs/teacup)

[2] Markaby begat CoffeeKup begat CoffeeCup and DryKup which begat Teacup

------
runj__
It's pretty, I like the rendering. A more complex example in the docs could
probably be useful though, something like a bootstrap form.

------
swalsh
This actually fills a good niche, if i'm looking for a monolithic framework
that trys to do a bunch of things, angular fits the bill. I like that this
does one thing, and seems to do it exceedingly well (fast). I'm not in the
market for a new framework right now, but the next time I am... i'd consider
it, if it stays small and compact like it is today.

------
cordite
I know react is not an MVC framework, but I think you should add it in for
comparisons since it uses similar rendering concepts

~~~
jmulho
The author comments on react here:
[http://lhorie.github.io/mithril/comparison.html](http://lhorie.github.io/mithril/comparison.html)

------
findjashua
Thanks for making this, this looks really really good!

I'm a backend guy beginning to venture into front-end stuff (recently picked
up JS for a Node project at work), and the extensive documentation is
incredibly helpful for newcomers like myself.

PS: I'd be very interested in some performance comparisons with Om and Vue.

------
maninalift
I think the m.prop getter/setter creation is a good compromise between the
"magical" creation of properties employed by Vue and Ractive and the
cumbersome use of SomeFramework.set("propertyname", value) employed by other
MV* frameworks.

I can't think of a good argument against it.

------
grannyg00se
I like the license, I like the level and style of documentation, I like the
lean scope, and I like the timing as I've just started looking into an MVC
framework to learn. I was going to choose react over angular but now I'm going
to choose this over either.

------
SNACKeR99
I just came back to say that the documentation really is beyond excellent.

------
Jxnathan
Off-topic: how do you apply animation to your logo on activation of the
browser tab? I loaded your page in a new tab, but the logo animation didn't
fire until I viewed that specific tab.

~~~
sergiotapia
The three rings are in a span. So it's content 'o' in span, the 'o' in :before
and 'o' in :after.

Then he uses a -webkit-animation to translate the positions of each ring.

    
    
        @keyframes logo {
        	from {opacity:0;transform:scale(2) rotate(359deg);}
        	to {opacity:1;transform:scale(1) rotate(0deg);}
        }
        @-webkit-keyframes logo {
        	from {opacity:0;-webkit-transform:scale(2) rotate(359deg);}
        	to {opacity:1;-webkit-transform:scale(1) rotate(0deg);}
        }

~~~
Kiro
But does that explain how it's not triggered until you click the tab?

~~~
pastjean
This is browser specific to trigger animations on tab open

------
killertypo
just a bit of a nitpick, but your getting started page uses the word
"performant" [http://english.stackexchange.com/questions/38945/what-is-
wro...](http://english.stackexchange.com/questions/38945/what-is-wrong-with-
the-word-performant)

the debate around the word just leaves a bad taste in my mouth. after reading
arguments from both sides I would tend to agree: until the word is a word, it
just sounds like marketing buzzword garbage.

~~~
lutusp
> ... until the word is a word, it just sounds like marketing buzzword
> garbage.

Fair enough, but remember that a word becomes a word simply by usage, not by
edict. The old Webster's rule was that, if a word appeared in ten recognized
publications with a consistent meaning, it (the word and the definition) would
be included in the next edition of the dictionary. I'm sure there's a similar
rule in play today.

The fluid and pragmatic nature of words and their meanings can be gauged by
noting that "literally" and "figuratively" now mean the same thing:

Link: [http://www.merriam-
webster.com/dictionary/literally](http://www.merriam-
webster.com/dictionary/literally)

Quote:

1 : in a literal sense or manner : actually <took the remark literally> <was
literally insane>

2 : in effect : virtually <will literally turn the world upside down to combat
cruelty or injustice — Norman Cousins>

------
ken47
This is very promising. I like the philosophies underpinning this framework,
and once it is in a mature state, I could certainly see myself using it in a
production environment.

------
b0z0
This is some pretty amazing code, actually. An MVC in 400 lines? Awesome. I
could learn from this for days, lack of semicolons and one-line loops
notwithstanding.

------
hcho
So, how do I integrate existing JQuery plugins? In most real life scenarios
there will be a few plugins which one would like to bring in.

------
omphalos
With that style of view, I suppose it's probably pretty easy to adapt Mithril
to support server-side rendering.

------
danneu
This is the kind of simplicity that brought me to Clojure for the past couple
years.

------
leo_mck
I would love to see a comparasion with knockoutjs/durandal too...

------
Geee
Quite similar to React? Probably about the same performance?

~~~
dangoor
I was actually wondering why this wouldn't just use React for the view. Then
it could leverage all of the work going on with React (server-side rendering,
possibly rendering from within a Web Worker, etc.)

~~~
jonahx
Given the philosophy leo outlines, I'd guess he's going for something slimmer.
This is 3k vs react's 29k. I am curious to know how it's achieving the same
thing in so much less code, or rather, what react can do that mithril can't.

------
tzaman
I don't mean this in a bad way, but do we really need another Javascript
framework? Wouldn't author's energy be more useful when contributing to one of
the existing ones?

~~~
tzaman
Not sure why I'm getting downvoted, it was a serious concern I expressed, with
0 intent of insulting anyone

~~~
hamburglar
You're getting downvoted because this guy thought it was an interesting
problem to think about, sat down and put some effort in, came up with
something he liked (and which appears to be very good) and wanted other people
to see it, and your input was, "isn't this a waste of time? People have done
this before!"

The fact that frameworks are appearing at a ridiculous rate is also the
_reason_ people still feel compelled to make their own: the existing ones
sometimes feel thrown together and flawed in obvious ways, so people
automatically think about ways they could be better and try those things out.
The result is progress (edit: sometimes the result is a bag of crap, but
that's beside the point).

No, we don't need more frameworks. And yet that still isn't a good reason to
stop building them, if for no other reason than to explore for yourself what
goes into building one (if that's your interest).

------
it_learnses
seems a lot like React. I haven't used it, but isn't it also built around the
idea of Shadow Doms?

------
jakiestfu
new function(window){}(this) is kinda weird to me. Sorry that's nothing
valuable to add to your code.

~~~
hamburglar
Correct me if I'm wrong, but what this does is: 1) allows the code to be run
in an environment where 'window' is not the global object (perhaps for
testing), and 2) in a browser, gives the caller the option to isolate the
module code so it's not allowed to touch 'window'.

------
johnnymonster
do you have a todomvc example :)

~~~
criswell
The guide is based off the building of a TODO app.
[http://lhorie.github.io/mithril/getting-
started.html](http://lhorie.github.io/mithril/getting-started.html)

------
ing33k
nice and clean

------
niklasber
Why?

