[lhorie]

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.

[timmywil]

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.

[timmywil]

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.

[lhorie]

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

[camus2]

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

[lhorie]

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.