Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: My new JavaScript MVC framework

lhorie.github.io

Post reply on HN
Print view View original

151–160 of 167 posts

Re: Show HN: My new JavaScript MVC framework

#151

Post by Tloewald »

ulisesrmzroche wrote: post #95
Tloewald wrote: post #47

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…

You're not using actual HTML, you're wrapping dom elements in your own special functions. You've made a templating langauge, like it or not.

Am I using code to do binding? Yes. Do we bind to HTML or something that -- after being parsed -- turns into HTML? HTML.

The advantages are significant. First -- you have to know HTML. Second -- all the code that works on HTML works on HTML.

We use data attributes to make the binding work. The data attributes are a "template language" if you will, but it's not breaking HTML (and if you read our attributes they make sense without much documentation).

Re: Show HN: My new JavaScript MVC framework

#152

Post by ulisesrmzroche »

thefreeman wrote: post #138
jpmonette wrote: post #130

Earlier quoted context omitted.

There's a sample TodoMVC posted here - https://github.com/jpmonette/todomvc-mithril . If you have any idea to improve, feel free to send a pull request!

https://github.com/jpmonette/todomvc-mithril/blob/master/js/... Looks pretty painful, but I do think adapting JSX could be a pretty painless solution so I don't look at it as a deal breaker. I am still yet to find a javascript templating solution that I don't have at least 1 or 2 issues with.

Honestly, that looks worse than I thought it would. Are you guys familiar with the whole, programs are for humans to read it, and incidentally for computers to execute?

Re: Show HN: My new JavaScript MVC framework

#153

Post by ulisesrmzroche »

lhorie wrote: post #125
ulisesrmzroche wrote: post #107

Earlier quoted context omitted.

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…

I think you're too caught up on syntax and missing the big picture. The m() method is simply a helper utility that returns a POJO. You can write the code in coffeescript if js syntax bother you, or you can go nuclear and implement a frontend or a preprocessor that take some popular templating syntax and spit out the appropriate data structure. The conversion tool I provide is a small step in that direction, but, with…

Programs are for humans to read and only incidentally for computers to execute. Syntax is the whole picture.

Re: Show HN: My new JavaScript MVC framework

#154

Post by lhorie »

camus2 wrote: post #148
lhorie wrote: post #120

Earlier quoted context omitted.

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

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

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.

Re: Show HN: My new JavaScript MVC framework

#155

Post by ulisesrmzroche »

Tloewald wrote: post #151
ulisesrmzroche wrote: post #95

Earlier quoted context omitted.

You're not using actual HTML, you're wrapping dom elements in your own special functions. You've made a templating langauge, like it or not.

Am I using code to do binding? Yes. Do we bind to HTML or something that -- after being parsed -- turns into HTML? HTML. The advantages are significant. First -- you have to know HTML. Second -- all the code that works on HTML works on HTML. We use data attributes to make the binding work. The data attributes are a "template language" if you will, but it's not breaking HTML (and if you read our attributes they make s…

No, if you're compiling at some point into HTML, then by definition, you're not writing HTML. HTML doesn't have functions in its spec (function m()) That's breaking HTML right there.

Re: Show HN: My new JavaScript MVC framework

#156

Post by lhorie »

ulisesrmzroche wrote: post #153
lhorie wrote: post #125

Earlier quoted context omitted.

I think you're too caught up on syntax and missing the big picture. The m() method is simply a helper utility that returns a POJO. You can write the code in coffeescript if js syntax bother you, or you can go nuclear and implement a frontend or a preprocessor that take some popular templating syntax and spit out the appropriate data structure. The conversion tool I provide is a small step in that direction, but, with…

Programs are for humans to read and only incidentally for computers to execute. Syntax is the whole picture.

Well, I already told you which directions Mithril can go in terms of making syntax more to your liking. If you're too put off by js templates and not willing to spend time helping push the project in a direction you like, you can always try other frameworks or come back later when I have a more HTMLy frontend option available.

Re: Show HN: My new JavaScript MVC framework

#157

Post by timmywil »

lhorie wrote: post #120
timmywil wrote: post #106

Earlier quoted context omitted.

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…

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

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.

Re: Show HN: My new JavaScript MVC framework

#158

Post by lhorie »

jpmonette wrote: post #130
ulisesrmzroche wrote: post #108

Earlier quoted context omitted.

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

There's a sample TodoMVC posted here - https://github.com/jpmonette/todomvc-mithril . If you have any idea to improve, feel free to send a pull request!

Looks roughly how I'd expect. Personally I don't find it unreadable, except for the 8-spaces-in-a-tab thing (which is not really relevant anyhow). Anyways, few things I see:

- I'm not sure why you're doing `return m("#todo-app"), [...]` on line 15 of the view, it looks like a typo

- I would probably have written a keyboard utility function similar to m.withAttr to keep the e.keyCode stuff out of the controller and remove the anonymous function in the view

- I generally prefer inline ternary syntax instead of a if statement at the top for the "clear" button.

- the pluralize snippet can also be pulled out into a utility method

- I also tend to favor this syntax: m("input#new-todo[placeholder='What needs to be done?']") if the value of the attribute is static (line 18)

Re: Show HN: My new JavaScript MVC framework

#159

Post by timmywil »

timmywil wrote: post #157
lhorie wrote: post #120

Earlier quoted context omitted.

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

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…

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.

Re: Show HN: My new JavaScript MVC framework

#160

Post by lhorie »

timmywil wrote: post #159
timmywil wrote: post #157

Earlier quoted context omitted.

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…

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.

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

Post reply on HN