3 ms·

todo.view = function() { return m("html", [ m("body", [ m("input"), m("button", "Add"), m("table", [

by jf22 12y ago

todo.view = function() { return m("html", [ m("body", [ m("input"), m("button", "Add"), m("table", [ m("tr", [ m("td", [ m("input[type=checkbox]") ]), m("td", "task description"), ]) ]) ]) ]); }; That's some sample view code right? The heck is that? With IDE support being so good why would I ever subject myself to using non-html view code anymore? There is no way I want to do a complex site in that kind of syntax, that's just crazy.

insin 12y ago
I tweaked React's JSX transformer to output Mithril-compatible code, so you don't have to deal with this sort of syntax: https://github.com/insin/msx https://github.com/insin/msx Having done DOM building with nested function calls/arrays/objects for years prior to it, I can't go back to the necessary syntax-wrangling after having used JSX.
fellytone84 12y ago
In my experience Javascript modes are usually as good or better than html/web modes so I don't think the problem is a lack of tooling. As for the function, I'm curious to know what you get out of wrapping html in the m function.
lhorie 12y ago
Hi, Mithril author here. > With IDE support being so good why would I ever subject myself to using non-html view code anymore As others have mentioned, preference for angled brackets can be solved with tooling. insin's MSX exists precisely to address this very concern, and it's dead simple to setup. As you might have noticed, Mithril's syntax is designed to look like the other language of the web: CSS. In practical terms, what this meant to me was to replace the usage of Emmett CSS-to-HTML expansion macro shortcuts in my text editor w/ a macro shortcut that spits out `m("")` instead. Coupled with simple IDE features like automatic bracket matching, I think you can get a typing experience that is very close to what is familiar to users of productivity tools like Jade/Haml/etc users (and with no preprocessor step required). The actual reasons for templates to be pure js are slightly more technical: it gives better error reporting, proper scope/closure/variable shadowing rules, turing completeness (for the purposes of refactoring/abstraction, etc), it's friendlier to transpiled language users, it's lintable, it's compressable, it's statically analizable, etc. Also, in my experience, complex apps tend to get heavier on logic than actual markup (this was actually the first thing my previous boss noticed when I gave him a simple code example when I was showing him the framework)

by jf22 12y ago

insin 12y ago

I tweaked React's JSX transformer to output Mithril-compatible code, so you don't have to deal with this sort of syntax: https://github.com/insin/msx https://github.com/insin/msx Having done DOM building with nested function calls/arrays/objects for years prior to it, I can't go back to the necessary syntax-wrangling after having used JSX.

fellytone84 12y ago

In my experience Javascript modes are usually as good or better than html/web modes so I don't think the problem is a lack of tooling. As for the function, I'm curious to know what you get out of wrapping html in the m function.

lhorie 12y ago

Hi, Mithril author here. > With IDE support being so good why would I ever subject myself to using non-html view code anymore As others have mentioned, preference for angled brackets can be solved with tooling. insin's MSX exists precisely to address this very concern, and it's dead simple to setup. As you might have noticed, Mithril's syntax is designed to look like the other language of the web: CSS. In practical terms, what this meant to me was to replace the usage of Emmett CSS-to-HTML expansion macro shortcuts in my text editor w/ a macro shortcut that spits out `m("")` instead. Coupled with simple IDE features like automatic bracket matching, I think you can get a typing experience that is very close to what is familiar to users of productivity tools like Jade/Haml/etc users (and with no preprocessor step required). The actual reasons for templates to be pure js are slightly more technical: it gives better error reporting, proper scope/closure/variable shadowing rules, turing completeness (for the purposes of refactoring/abstraction, etc), it's friendlier to transpiled language users, it's lintable, it's compressable, it's statically analizable, etc. Also, in my experience, complex apps tend to get heavier on logic than actual markup (this was actually the first thing my previous boss noticed when I gave him a simple code example when I was showing him the framework)