5 ms·

Superviews.js, a template engine targeting incremental-dom

43 points by ivank 11y ago

lars 11y ago
This is the first I'm hearing of incremental-dom. Can anyone explain what it is? According to their readme: > It differs from the established virtual DOM approach in that no intermediate tree is created (the existing tree is mutated in-place). Direct DOM manipulation is something the DOM itself has had an API for since about 1995 (and there are plenty of nice wrappers for it). What value does this provide on top of that? Does it batch up changes for requestAnimationFrame()?
- ajanuary 11y ago
  From "Introducing Incremental DOM" [1] Incremental DOM changes the model to be a single phase: While creating the new (virtual) DOM tree walk along the existing tree and figure out changes as you go. Allocate no memory if there is no change; if there is, mutate the existing tree (only allocating memory if absolutely necessary) and apply the diff to the physical DOM. [1] https://medium.com/google-developers/introducing-incremental-dom-e98f79ce2c5f https://medium.com/google-developers/introducing-incremental...
  - woah 11y ago
    Hehe "physical DOM"
- ivank 11y ago
  With incremental-dom, you're still re-running code to "generate" an entire DOM tree on every state change, so you have the React-like convenience and correctness of not writing individual mutations. But it doesn't create an intermediate represention like React. Instead, incremental-dom patches the real DOM as soon as your code calls into the elementOpen/elementClose/etc functions. Thus, significantly reduced memory allocations and GC thrashing.
  - legutierr 11y ago
    I poked around on vdom benchmark[1], and I got the following times: incremental-dom 0.1.0 276343 React 0.13.1 586353 mithril 0.2.0 602722 virtual-dom 2.0.1 99136 Does anyone know what is going on here? The argument I've heard frequently in favor of React, for instance, is that touching the DOM at all is very slow, so React makes things more efficient by only touching the DOM after the virtual DOM diff has been calculated. Is that argument correct? Is reading the DOM actually not so problematic, as long as the modification you make to it are minimal (which seems to be the strategy here)? One conceivable advantage of this approach seems to be that you can use the native event system directly, but I can't find any mention of event handling in the documentation. I'm wondering if a kind of flux-type architecture would work here, but using jquery, say, to subscribe to events. [1] http://vdom-benchmark.github.io/vdom-benchmark/ http://vdom-benchmark.github.io/vdom-benchmark/
    - ShellfishMeme 11y ago
      Virtual DOM approaches never really were about performance. They are about being able to write idempotent render functions in declarative style so that you don't need to deal with massive amounts of DOM state management. In the end you want to write a function that just expresses what the state of the DOM should be depending on the input parameters and have something deal with applying those changes to a very stateful API. If the application state changes, all you want to do is say 'things have changed somehow, just re-render this component'. This was possible before with classic templating, but it wasn't very efficient and had problems when dealing with re-rendering interactive elements. You would lose focus on input fields for example, and had to use some post-render hooks to fix the state of the DOM up afterwards. Using virtual DOM structures fixed this problem in an elegant way and allowed rendering to the DOM to be integrated into more functional programming styles, which made more reactive architectures possible. It all boils down to humans not being good with reasoning about state changes over time and how to express those imperatively. The only solution to that is not to do it and go more functional. This is also why I am not a big fan of things like incremental-dom. It ignores the whole idea why we wanted declarative DOM handling in the first place and replaces it with a very imperative and side-effect heavy API. In that case, just use the DOM directly.
iheart2code 11y ago
I started writing HTML, CSS, and JS in 2000. As someone who hasn't really worked in it day-to-day since 2010, JavaScript appears to be getting really weird.
- duiker101 11y ago
  JavaScript has always been a bit weird...
- pavlov 11y ago
  Javascript libraries are to programming what Marxism was to economics in the 1970s: there's a lot of noise about it and a lot of innovation taking place in the field... But to make any sense of the "progress", you must have spent some serious time getting indoctrinated.
  - bobwaycott 11y ago
    It took 130 years for Marxism to just hit the point of making "noise"? Come on now.
    - pavlov 11y ago
      Javascript is around 20 years old. In Internet years, that's roughly 130. I was trying to say that JS and good old communism had a similar trajectory. Initial scepticism, outright hatred from the establishment, then an enormous success with some core flaws; after it's mellowed down and reality has settled in, people are trying to fix it in increasingly theoretical ways that may not do anything to address the fundamental issues.
- deleted 11y ago
  [deleted]

43 points by ivank 11y ago

lars 11y ago

This is the first I'm hearing of incremental-dom. Can anyone explain what it is? According to their readme: > It differs from the established virtual DOM approach in that no intermediate tree is created (the existing tree is mutated in-place). Direct DOM manipulation is something the DOM itself has had an API for since about 1995 (and there are plenty of nice wrappers for it). What value does this provide on top of that? Does it batch up changes for requestAnimationFrame()?

ajanuary 11y ago
From "Introducing Incremental DOM" [1] Incremental DOM changes the model to be a single phase: While creating the new (virtual) DOM tree walk along the existing tree and figure out changes as you go. Allocate no memory if there is no change; if there is, mutate the existing tree (only allocating memory if absolutely necessary) and apply the diff to the physical DOM. [1] https://medium.com/google-developers/introducing-incremental-dom-e98f79ce2c5f https://medium.com/google-developers/introducing-incremental...
- woah 11y ago
  Hehe "physical DOM"
ivank 11y ago
With incremental-dom, you're still re-running code to "generate" an entire DOM tree on every state change, so you have the React-like convenience and correctness of not writing individual mutations. But it doesn't create an intermediate represention like React. Instead, incremental-dom patches the real DOM as soon as your code calls into the elementOpen/elementClose/etc functions. Thus, significantly reduced memory allocations and GC thrashing.
- legutierr 11y ago
  I poked around on vdom benchmark[1], and I got the following times: incremental-dom 0.1.0 276343 React 0.13.1 586353 mithril 0.2.0 602722 virtual-dom 2.0.1 99136 Does anyone know what is going on here? The argument I've heard frequently in favor of React, for instance, is that touching the DOM at all is very slow, so React makes things more efficient by only touching the DOM after the virtual DOM diff has been calculated. Is that argument correct? Is reading the DOM actually not so problematic, as long as the modification you make to it are minimal (which seems to be the strategy here)? One conceivable advantage of this approach seems to be that you can use the native event system directly, but I can't find any mention of event handling in the documentation. I'm wondering if a kind of flux-type architecture would work here, but using jquery, say, to subscribe to events. [1] http://vdom-benchmark.github.io/vdom-benchmark/ http://vdom-benchmark.github.io/vdom-benchmark/
  - ShellfishMeme 11y ago
    Virtual DOM approaches never really were about performance. They are about being able to write idempotent render functions in declarative style so that you don't need to deal with massive amounts of DOM state management. In the end you want to write a function that just expresses what the state of the DOM should be depending on the input parameters and have something deal with applying those changes to a very stateful API. If the application state changes, all you want to do is say 'things have changed somehow, just re-render this component'. This was possible before with classic templating, but it wasn't very efficient and had problems when dealing with re-rendering interactive elements. You would lose focus on input fields for example, and had to use some post-render hooks to fix the state of the DOM up afterwards. Using virtual DOM structures fixed this problem in an elegant way and allowed rendering to the DOM to be integrated into more functional programming styles, which made more reactive architectures possible. It all boils down to humans not being good with reasoning about state changes over time and how to express those imperatively. The only solution to that is not to do it and go more functional. This is also why I am not a big fan of things like incremental-dom. It ignores the whole idea why we wanted declarative DOM handling in the first place and replaces it with a very imperative and side-effect heavy API. In that case, just use the DOM directly.

iheart2code 11y ago

I started writing HTML, CSS, and JS in 2000. As someone who hasn't really worked in it day-to-day since 2010, JavaScript appears to be getting really weird.

duiker101 11y ago
JavaScript has always been a bit weird...
pavlov 11y ago
Javascript libraries are to programming what Marxism was to economics in the 1970s: there's a lot of noise about it and a lot of innovation taking place in the field... But to make any sense of the "progress", you must have spent some serious time getting indoctrinated.
- bobwaycott 11y ago
  It took 130 years for Marxism to just hit the point of making "noise"? Come on now.
  - pavlov 11y ago
    Javascript is around 20 years old. In Internet years, that's roughly 130. I was trying to say that JS and good old communism had a similar trajectory. Initial scepticism, outright hatred from the establishment, then an enormous success with some core flaws; after it's mellowed down and reality has settled in, people are trying to fix it in increasingly theoretical ways that may not do anything to address the fundamental issues.
deleted 11y ago
[deleted]