Live data from Hacker News

Show HN: My new JavaScript MVC framework

lhorie.github.io

91–100 of 167 posts

Re: Show HN: My new JavaScript MVC framework

#91

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

I think the idea is that it's simple — it's just a basic data structure in the language and can be generated or manipulated with just simple JavaScript. This is similar to why Lisp programs being Lisp data structures is interesting. Intriguingly, it looks like the API is compatible with React's JSX. With that, you could write this as:

  @jsx m
  todo.view = function(ctrl) {
      return (
        
          
            
            Add
            
              
                
                Desk description
              
            
          
        
      );
  }

Re: Show HN: My new JavaScript MVC framework

#92
post #77

Earlier quoted context omitted.

But DOM is separate from JavaScript.

Only theoretically. Javascript is a way to manipulate the DOM, no matter whan those nutters who run it on servers say.

Nope, it's the truth. You can have JavaScript without the DOM in a Node.js or a CouchDB environment, for example.

Re: Show HN: My new JavaScript MVC framework

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

>Stop with the frameworks.

>Things like jQuery, underscore, etc...

Sounds great until you have a team of 5 developers maintaining at least a semi-huge code base over the course of some years. Some people leave, new join the team.

Then you really start appreciating frameworks if only for their conventions to structure the code. Top coders can write web apps with jQuery and underscore alone, but everyone else is better off following some conventions.

Re: Show HN: My new JavaScript MVC framework

#94
post #91

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

I think the idea is that it's simple — it's just a basic data structure in the language and can be generated or manipulated with just simple JavaScript. This is similar to why Lisp programs being Lisp data structures is interesting. Intriguingly, it looks like the API is compatible with React's JSX. With that, you could write this as: @jsx m todo.view = function(ctrl) { return ( Add Desk description ); }

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.

Re: Show HN: My new JavaScript MVC framework

#95

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.

Re: Show HN: My new JavaScript MVC framework

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

Well, that's a good start, but I was referring to a 'utility' in the sense of a utility method that does it at runtime, as you say.

Re: Show HN: My new JavaScript MVC framework

#97
Author of Vue.js here, I'm glad you included Vue in your framework comparisons. Here's some thoughts regarding your comments on Vue.js: the reason Vue chose to use ES5-only features is that it enables Vue to provide plain POJO syntax without having to resort to dirty checking or virtual DOM diffing. Granted the auto-magical POJO syntax is a somewhat leaky abstraction, but I'd argue that not all leaky abstractions are bad (since by definition any non-trivial abstractions are leaky) - it all depends on its leakiness vs. the benefits provided by the abstraction. TCP is the canonical example of a leaky abstraction in Spolsky's original post yet it has been the foundation of everything we build on the web all along. In fact, even the concept of virtual DOM is a leaky abstraction in itself. My point is, I don't think the leaky abstraction argument raises anything inherently problematic about Vue.js.

That said, I really like the project because I'm also a big fan of simplicity. Curious to see if there will be a TodoMVC implementation with Mithril for easier horizontal comparisons of actual code.

Re: Show HN: My new JavaScript MVC framework

#98
post #91

Earlier quoted context omitted.

I think the idea is that it's simple — it's just a basic data structure in the language and can be generated or manipulated with just simple JavaScript. This is similar to why Lisp programs being Lisp data structures is interesting. Intriguingly, it looks like the API is compatible with React's JSX. With that, you could write this as: @jsx m todo.view = function(ctrl) { return ( Add Desk description ); }

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.

Re: Show HN: My new JavaScript MVC framework

#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 one.
Post reply on HN