Live data from Hacker News

Show HN: My new JavaScript MVC framework

lhorie.github.io

71–80 of 167 posts

Re: Show HN: My new JavaScript MVC framework

#71
post #36

Here are my thoughts, but you won't like them. Stop with the frameworks. Learn Javascript. Learn CSS. Learn HTML. You'll find pretty quickly that what you need are libraries , not frameworks. Things like jQuery, underscore, etc...

Ehh I know Javascript, and know it well, along with HTML+CSS. My experience is that a very light framework can not only help structure things in a more sane way, but can provide a set of tools that make a mindset easier.

After building/using Composer.js (http://lyonbros.github.io/composer.js/) extensively I inevitably end up reimplementing parts of it on projects that don't use it because it makes some things so easy.

That said, if you're learning javascript, stay away from frameworks at all costs.

Re: Show HN: My new JavaScript MVC framework

#72

The approach we've taken in our anti-framework is that the model is your data (and the code you use to manipulate the data), the view is your HTML/CSS ( not a special templating language -- actual HTML), and the controller is automatic for simple stuff and custom for complex stuff. So the big example at the end of Mithril would, for us, be something like (we implement binding as a jQuery extension) $('.display').bind…

Sounds a bit like the pure js library but with jquery.

http://beebole.com/pure/

Re: Show HN: My new JavaScript MVC framework

#73

I've become a huge fan of simple things. When I was just starting out developing software, I was a big fan of huge integrated solutions. But as the years went on I loved well scoped, lean options. This is the reason why I like Backbone.JS instead of Angular. The reason why I like Go instead of Java. Mithril looks really promising! Don't let feature creep turn it into a behemoth! Keep it lean and mean, and excel at th…

I think this is the same taste-maturation that many woodworkers experience. At first, you salivate over these crazy, overly specific, over engineered power tools. Over time, you start to really love things that are stupidly simple instead, like a card scraper, or a hand plane.

I would buy your wood-things.

Re: Show HN: My new JavaScript MVC framework

#74
post #36

Here are my thoughts, but you won't like them. Stop with the frameworks. Learn Javascript. Learn CSS. Learn HTML. You'll find pretty quickly that what you need are libraries , not frameworks. Things like jQuery, underscore, etc...

Ehh. As a developer, I find the best way to understand a concept is to sometimes implement it from scratch. Sometimes your implementation may just be for your own edification on how the patten (doesn't) works, other times it can be useful for others.

Your view is limiting

Re: Show HN: My new JavaScript MVC framework

#75
post #60

Earlier quoted context omitted.

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…

Well, there is such a tool, actually. http://lhorie.github.io/mithril/tools/template-converter.htm... But while me and my coworker have been trying it out there seem to be quite a few bugs with it, and I'd much rather have it done at runtime (precompiled for production build) then have to translate it from my HTML-based template every time I make a change.

Can you file an issue on Github? I still need to make an automated version of this tool (and eventually be able to import from something like Mustache), and I want to make sure it's rock solid.

Re: Show HN: My new JavaScript MVC framework

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

Re: Show HN: My new JavaScript MVC framework

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

But DOM is separate from JavaScript.

Re: Show HN: My new JavaScript MVC framework

#78

The approach we've taken in our anti-framework is that the model is your data (and the code you use to manipulate the data), the view is your HTML/CSS ( not a special templating language -- actual HTML), and the controller is automatic for simple stuff and custom for complex stuff. So the big example at the end of Mithril would, for us, be something like (we implement binding as a jQuery extension) $('.display').bind…

Sounds a bit like the pure js library but with jquery. http://beebole.com/pure/

Ours is a fair bit more elegant and works both ways. It's also being used for multiple pretty complex projects so it's reasonably "battle-tested" (although nothing is in production yet, so not as battle-tested as it needs to be).

We also do not bind by class because that's a really bad idea. (Actually the way we bind is a lot like Angular, but without being a templating language.)

A key design requirement is that the model does not get polluted with special methods and properties to support the binding -- so (for example) if you have nice RESTful services, you can GET, bind, edit, POST/PUT and everything just works. For moderately complex cases we support "decorators" that live "off to the side" (i.e. do not pollute the model). Again, you can stick getters and setters in your model if you want to, you just don't need to.

Re: Show HN: My new JavaScript MVC framework

#79
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…

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

Re: Show HN: My new JavaScript MVC framework

#80
post #13

Quite similar to React? Probably about the same performance?

I don't see this as solving the same problems as React.

React is not "a templating language" that "uses a Virtual DOM", React is an implementation of _autonomous nestable components_, and that requires rerendering of HTML. Virtual DOM is just a way to achieve that rerendering better.

Post reply on HN