Live data from Hacker News

Show HN: My new JavaScript MVC framework

lhorie.github.io

31–40 of 167 posts

Re: Show HN: My new JavaScript MVC framework

#31
post #9

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

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

Looks like Javascript IS the Assembly of the Web.

Re: Show HN: My new JavaScript MVC framework

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

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.

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

Re: Show HN: My new JavaScript MVC framework

#35
post #18
post #16

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

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.

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.

Re: Show HN: My new JavaScript MVC framework

#37
post #15

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?

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

Re: Show HN: My new JavaScript MVC framework

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

Re: Show HN: My new JavaScript MVC framework

#39
post #18

Earlier quoted context omitted.

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.

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

Definitely, and there are other benefits in parallelizing the work stream if you have people that do layout and styling, but aren't necessarily up to constructing a page in a javascript framework.

Re: Show HN: My new JavaScript MVC framework

#40
post #18

Earlier quoted context omitted.

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.

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

>converts an HTML-based template into the view that mithril expects

So basically XAML?

Post reply on HN