5 ms·

I like Mitiril, but the way you manage your view layer doesn't work for me. I've tried several "build a Dom in code" approaches before, and they haven't proven

I like Mitiril, but the way you manage your view layer doesn't work for me. I've tried several "build a Dom in code" approaches before, and they haven't proven to be very maintainable in the long run, especially for larger and more complex solutions. Additionally, the cost of migrating an app is much much higher. So while this post is mostly FUD, your points are valid, I feel all frameworks come with a tradeoff.

davexunit 11y ago
I love Mithril's (and other's) "build a DOM in code" approach. Traditional templating systems are always limited domain-specific languages that add lots of complexity for things that should be simple, template "partials" and iteration come to mind instantly. Making the virtual DOM tree a first-class value that can be treated as a persistent data structure is a huge win. Templates are functions that return a virtual DOM node. Rendering a list is a map from Thing -> virtual DOM node. Redundant rendering is avoided with memoization. "Partials" are just functions. The system handles escaping and prevents XSS vulnerabilities by distinguishing plain strings from DOM nodes, which string-based templating systems do not do. All of the complexity and difficulty of working with templating systems goes away when we can just use the usual functional combinators we all know and love to compose views. On top of Mithril, I recommend working in a functional reactive library (Kefir, Bacon, Rx, whatever else) to make the whole application declarative and functional. Angular just doesn't compose well with other things like Mithril and other primarily functional libraries do. I should really write a blog post on this.
- Touche 11y ago
  > On top of Mithril, I recommend working in a functional reactive library (Kefir, Bacon, Rx, whatever else) to make the whole application declarative and functional. How are you using an FRP library with Mithril? I thought with vdom libraries you never touch the real DOM.
  - davexunit 11y ago
    Mithril allows you to declare callbacks for the various DOM events on the virtual DOM nodes. This is where you glue in the FRP library. A callback will set the current value for one of the roots of the signal graph.
  - findjashua 11y ago
    synthetic events' handlers can publish events to a bus, and you can create observables on the events on the bus. VDom lets you express UI as a function of the state Observables let you express state as a function of user interactions
lhorie 11y ago
Would you care to elaborate on the maintainability aspect? I've worked with various "build DOM in code" approaches too, ranging from anywhere between Ext.js to HTML string interpolation/concatenation in jQuery and I think a lot of approaches do suck (some more so than others). One major problem with older "build-DOM-in-code" approaches was ability to integrate to third party libraries, but I feel that this problem has been solved by newer frameworks (e.g. via lifecycle methods/mixins in React, `config` in Mithril, etc). Personally, I find that mapping the DOM structure onto Javascript a la Mithril, React, et al works out better than mapping scopes and closures and logic onto HTML (a la Angular), simply because it's easier to refactor code that is, well, code, rather than something that tries to emulate having programming-language-like properties in HTML by shipping its own quirky implementation of scopes, expression parsers, compiler, etc. I disagree on cost of migration. It's not exactly trivial to migrate from Angular to any framework that I know of, for example, especially once you start using things like form validation flags or filters. The only migrations that sound somewhat straightforward to me are Meteor/Ember (since both use Handlebars flavors) and - perhaps ironically - React/Mithril (assuming JSX/MSX), but for mostly anything, you're pretty much stuck with manually porting framework-specific syntax. With that being said, it's not necessarily impossible. I know of success stories of people porting non-trivial codebases from Ember to Mithril and even from jQuery spaghetti to Mithril (via its template converter too). At the end of the day, I think it comes down to tooling. With React's renderToString or mithril-node-render, it's quite feasible to automate a large portion of the work of porting templates away from these newer frameworks, should you need to do so down the road.
- code_sterling 11y ago
  I haven't been able to write this without sounding critical of mithiril, and I don't want to do that. I suspect it all comes down to use case, and the line of work I'm in, it's not a wise choice.

davexunit 11y ago

I love Mithril's (and other's) "build a DOM in code" approach. Traditional templating systems are always limited domain-specific languages that add lots of complexity for things that should be simple, template "partials" and iteration come to mind instantly. Making the virtual DOM tree a first-class value that can be treated as a persistent data structure is a huge win. Templates are functions that return a virtual DOM node. Rendering a list is a map from Thing -> virtual DOM node. Redundant rendering is avoided with memoization. "Partials" are just functions. The system handles escaping and prevents XSS vulnerabilities by distinguishing plain strings from DOM nodes, which string-based templating systems do not do. All of the complexity and difficulty of working with templating systems goes away when we can just use the usual functional combinators we all know and love to compose views. On top of Mithril, I recommend working in a functional reactive library (Kefir, Bacon, Rx, whatever else) to make the whole application declarative and functional. Angular just doesn't compose well with other things like Mithril and other primarily functional libraries do. I should really write a blog post on this.

Touche 11y ago
> On top of Mithril, I recommend working in a functional reactive library (Kefir, Bacon, Rx, whatever else) to make the whole application declarative and functional. How are you using an FRP library with Mithril? I thought with vdom libraries you never touch the real DOM.
- davexunit 11y ago
  Mithril allows you to declare callbacks for the various DOM events on the virtual DOM nodes. This is where you glue in the FRP library. A callback will set the current value for one of the roots of the signal graph.
- findjashua 11y ago
  synthetic events' handlers can publish events to a bus, and you can create observables on the events on the bus. VDom lets you express UI as a function of the state Observables let you express state as a function of user interactions

lhorie 11y ago

Would you care to elaborate on the maintainability aspect? I've worked with various "build DOM in code" approaches too, ranging from anywhere between Ext.js to HTML string interpolation/concatenation in jQuery and I think a lot of approaches do suck (some more so than others). One major problem with older "build-DOM-in-code" approaches was ability to integrate to third party libraries, but I feel that this problem has been solved by newer frameworks (e.g. via lifecycle methods/mixins in React, `config` in Mithril, etc). Personally, I find that mapping the DOM structure onto Javascript a la Mithril, React, et al works out better than mapping scopes and closures and logic onto HTML (a la Angular), simply because it's easier to refactor code that is, well, code, rather than something that tries to emulate having programming-language-like properties in HTML by shipping its own quirky implementation of scopes, expression parsers, compiler, etc. I disagree on cost of migration. It's not exactly trivial to migrate from Angular to any framework that I know of, for example, especially once you start using things like form validation flags or filters. The only migrations that sound somewhat straightforward to me are Meteor/Ember (since both use Handlebars flavors) and - perhaps ironically - React/Mithril (assuming JSX/MSX), but for mostly anything, you're pretty much stuck with manually porting framework-specific syntax. With that being said, it's not necessarily impossible. I know of success stories of people porting non-trivial codebases from Ember to Mithril and even from jQuery spaghetti to Mithril (via its template converter too). At the end of the day, I think it comes down to tooling. With React's renderToString or mithril-node-render, it's quite feasible to automate a large portion of the work of porting templates away from these newer frameworks, should you need to do so down the road.

code_sterling 11y ago
I haven't been able to write this without sounding critical of mithiril, and I don't want to do that. I suspect it all comes down to use case, and the line of work I'm in, it's not a wise choice.