Live data from Hacker News

Show HN: My new JavaScript MVC framework

lhorie.github.io

101–110 of 167 posts

Re: Show HN: My new JavaScript MVC framework

#101
post #23
post #13

Quite similar to React? Probably about the same performance?

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

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.

Re: Show HN: My new JavaScript MVC framework

#102
post #29
post #4

Earlier quoted context omitted.

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

But this was built to solve problems the author was having at the time he/she created it. In the future, as the web evolves, those problems will change, and you're saying the framework shouldn't adapt to solve new problems?

I'm saying that's the only way to keep it from entering the inevitable malignant growth phase frameworks enter in after a bit because the author / community wants it to do everything. And we already have a ton of those, some popular, most not.

Re: Show HN: My new JavaScript MVC framework

#104
post #66

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 lib…

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

Re: Show HN: My new JavaScript MVC framework

#105

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 "java…

Not astroturfing AT ALL

The framework is completely free and MIT-licensed, so I suspect that a literal interpretation of your comment is absolutely correct.

Re: Show HN: My new JavaScript MVC framework

#106
post #66

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 lib…

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\">"; has a security hole. How dare the browser do what I said!

Stop comparing jQuery to MVC frameworks.

Re: Show HN: My new JavaScript MVC framework

#107
post #98

Earlier quoted context omitted.

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.

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.

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.

Re: Show HN: My new JavaScript MVC framework

#108
post #100

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"), ]) ]) ]) ]); };

While I admit I'm somewhat sympathetic to this reaction, it really is a cosmetic complaint. It's hardly uglier or more complex than ordinary html -- we're just used to html. Ofc there's some benefit to the technologies we're used to all things being equal, but I think architectural benefits trump concerns like this. I'm not making a case for or against Mithril, btw, just noting that this objection is a fairly surface…

How many times have you messed up a comma inside an array? And just for looping, this is literally constructing a web page out of it. There is no architectural benefit to this, all that's going to happen is that your going to fat finger some shit, and the compiler will complain to no end.

Guys, rule of thumb, architecture === directory names. Performance is an implementation detail.

Frameworks live and die by their APIs. The easier it is to work with, to read and write and reason with, the better it is.

But you know what, this can be easily proved. Someone take a stab at todomvc with this and let me know if it hurt or not.

Re: Show HN: My new JavaScript MVC framework

#110
post #98

Earlier quoted context omitted.

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.

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] cl…

[deleted]
Post reply on HN