5 ms·

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 f

by lhorie 13y ago

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

robzienert 13y ago
This is kind of an annoying format for answering questions. You can't see the context and it breaks the conversation thread.
pygy_ 13y ago
> 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 13y ago
  >> 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!
pedalpete 13y ago
Can I ask how long you've been working on it before releasing? Your github only shows it was pushed two days ago.
timmywil 13y ago
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! Stop comparing jQuery to MVC frameworks.
- lhorie 13y ago
  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.
  - 13y ago

by lhorie 13y ago

robzienert 13y ago

This is kind of an annoying format for answering questions. You can't see the context and it breaks the conversation thread.

pygy_ 13y ago

> 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 13y ago
>> 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!

pedalpete 13y ago

Can I ask how long you've been working on it before releasing? Your github only shows it was pushed two days ago.

timmywil 13y ago

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! Stop comparing jQuery to MVC frameworks.

lhorie 13y ago
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.
- 13y ago