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 :)
You've missed the point. You're comparing MVC frameworks to jQuery as if that made sense, which it doesn't.
As I said, Angular and Backbone use jQuery. So you're just comparing how you've used jQuery (as if that's how any jQuery user would do it) to how they've used jQuery. There is no such thing as "idiomatic" jQuery templating. There are only plugins and libraries that use jQuery to do templating. In fact, what you've done in the jQuery rendering test is incredibly bad practice and is greatly discouraged in the jQuery community. Again, your tests don't make sense.
If you need me to explicate my pointer further, the jQuery "security test" is you asking jQuery to do something stupid and it following orders. It's absurd. You might as well add a native test saying that document.documentElement.innerHTML = "a\"><img src=\"javascript:;\" onerror=\"alert('alert box should not appear')\">"; has a security hole. How dare the browser do what I said!
Many people are at a stage where they're using jQuery to build large apps and wondering what benefits a framework provides. Not having to worry about script injections is one of the benefits that frameworks bring to the table. This is a perfectly sensible thing to point out, imho, given both tools are used for the purpose of building web applications.
The technical implementation of the jQuery test is flawed on purpose, and that's the point. People make mistakes, some don't know better.
Are you arguing that every jQuery dev team in the world audits their code for stuff like:
- bla.text(firstName + " " + lastName)
+ bla.html(firstName + " " + lastName) // bug fix 1234: make name not wrap
Or that somehow the jQuery community is gonna catch that in your application? Or that your innerHTML example (given a user-defined string) does not have a security hole? That you're gonna find that commit from the junior guy at 3am at crunch time? That "the developer should know better" is a good security strategy? Are you saying that one API that makes it hard to make mistakes not comparable to one that makes it easy to? That's the absurd claim, imho.
Like it or not, jQuery is the big elephant in the room, so yes, I'm going to compare to it, to the extent where it makes sense. Is it an apples to apples comparison? No. Neither is the comparison w/ React. But those comparisons are useful to some people, so I provide them.
Sigh. I would hope that you were not confusing my statements to mean that I don't think jQuery can be used badly (by the way, having seen jQuery used poorly is no justification for your tests) or that I don't understand the security hole presented. I want people to take responsibility for how they use tools like jQuery and I think your tests are an unfair and blatantly misleading representation of jQuery as a library.
Now, having gotten that off my chest, I'm not going to go off and disparage your framework. I want to thank you for your library and your contribution to open source, because I think that has eminent value often overlooked.
> your tests are an unfair and blatantly misleading representation of jQuery as a library
Sure, that's a fair point given that my explanation in the homepage is skimpy. I did try my best to word it in a way not to diss jQuery as a project: "if you see an alert box, ensuring security with that framework is more work for you". If you have a better idea on how to phrase this point, I'm open to suggestions.
> Many people are at a stage where they're using jQuery to build large apps
Nobody's using jQuery only to build large single page apps,that's not true. Comparing jQuery which a DOM manipulation library to any framework that manage the application lifecycle is dishonest.
It would be like comparing underscore to AngularJS,makes no sense.
Hmm, I think you're underestimating legacy code. I can name two very large projects in my company that do use jQuery as the main client-side library, as well as numerous other smaller ones (granted, these projects are not SPAs).
Back to the point, jQuery and Mithril are more similar than your analogy tries to make it sound. jQuery does AJAX/CORS and Deferreds and .data() and a whole lot of non-DOM stuff that people use when building their apps. There's some stuff that doesn't map like jQuery animations not having a Mithril counterpart or Mithril routing not having a jQuery-core counterpart, but that's cherrypicking the stuff that is different and saying "look, they're different!", while ignoring the similar, comparable aspects.
Also, I'm not sure how familiar you are w/ underscore or Angular, but both have a templating system and utilities to work with lists of data, so there are definitely points that can be compared. These comparisons are really not at all like comparing something like restangular to hoverIntent, so implying that they're equally imcomparable seems like the dishonest and non-productive argument to me, imho.
@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 :)