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

Virtual DOM in Elm

elm-lang.org

Post reply on HN
Print view View original

31–40 of 117 posts

Re: Virtual DOM in Elm

#31

Post by grayrest »

colinramsay wrote: post #7

My first thought when looking at the benchmarks is that I find it strange that Backbone is faster than React. Not that I imagine Backbone to be slow, particularly, just that this article is about one of React's key features - the virtual DOM - and that's something which Backbone doesn't have. I'd expect to see React up there with Om, Mercury & Elm. I've just had a look at the code and React is using a localstorage ba…

Without looking at the benchmark code:

* Development React is slower than production React. There are a bunch of extra checks all over the place along with a profiler [1].

[1] http://facebook.github.io/react/docs/perf.html

* Speed isn't the top priority of the framework, predictability is. There's a virtual event infrastructure and other browser normalization work going on. Om is using React under the hood and more or less represents the best case scenario.

* React isn't magically fast. The diff process still has to visit all the nodes in the virtual DOM, generate the edit list, and apply it, which is a substantial amount of overhead. I'm used to seeing React even or behind when benchmarked with a small number of nodes. The explanation I've seen is that these benchmarks aren't considered important since the goal isn't to be as fast as possible but rather to never be slower than 16ms.

The trick behind most of the "React is fast" articles is that React is O(N_dom) instead of O(N_model) so if you can shrink the size of the output DOM, React goes faster. The Om line demonstrates this and doing screen-sized render over a sliding window of data in a huge data set (most grid/scrolling list demos) is another common example. There are perf knobs that probably aren't being turned here but if the app renders fast enough why would you waste your time turning them?

Re: Virtual DOM in Elm

#32

Post by danabramov »

There's another advantage to virtual DOM: you can hot-swap code while developing and have React run its diff algorithm without reloading the page. If your component has no (or little) side-effects, it means you get live reload as you edit for free. This is impossible with Backbone/jQuery soup of a view.

See my proof of concept video: https://vimeo.com/100010922

And actually runnable example that you can edit without refresh: https://github.com/gaearon/react-hot-loader

I plan to write a blog post explaining how to integrate it into React project soon.

Re: Virtual DOM in Elm

#33

Post by glibgil »

Why so many strings and so few types, especially for somethings like Elm?

The same in PureScript would be

profile user = mkUI spec do div [ className "profile" ] [ img [ src user.picture ] , span [ text user.name ] ]

See, types everywhere. https://github.com/purescript-contrib/purescript-react/blob/...

Re: Virtual DOM in Elm

#34

Post by masklinn »

matchu wrote: post #30
asolove wrote: post #18

Earlier quoted context omitted.

(Edit: posted this comment before I read the article, doh.) These is certainly something wrong with the benchmark. Since Om is a layer on top of React, it is obvious that React itself cannot be necessarily slower than Om. (Perhaps idiomatic React usage is slower than idiomatic Om usage for this case, though?)

See the article's discussion of immutability in Elm. Om has the same immutability property, so configures React to take advantage of that property, skipping vanilla React's property diffing. edit: Rather, see masklinn's comment that describes what actually happens. Point being, vanilla React does extra work to account for anything a developer might do, but allows Elm and Om, which have more rigorous standards for the…

Vanilla React doesn't do property diffing by default, it re-renders the whole tree then diffs the whole virtual DOM, because it can't rely on data immutability or on components purity.

Since Om or Elm assume immutable inputs and pure components they can skip rendering components altogether when the inputs have not changed (mentioned in TFA's "Making Virtual DOM Fast").

React can do that, but it has to be opted in component by component either by using PureRenderMixin or by implementing shouldComponentUpdate.

Re: Virtual DOM in Elm

#35

Post by skybrian »

lightblade wrote: post #13

I've been thinking why there's no virtual dom implementation other than react. Glad to see there's finally some out there.

If you're using Dart, I have an experimental implementation: https://github.com/google/dart-tagtree

I'm sure others are experimenting as well, so we should see more implementations soon.

Re: Virtual DOM in Elm

#36

Post by matchu »

masklinn wrote: post #34
matchu wrote: post #30

Earlier quoted context omitted.

See the article's discussion of immutability in Elm. Om has the same immutability property, so configures React to take advantage of that property, skipping vanilla React's property diffing. edit: Rather, see masklinn's comment that describes what actually happens. Point being, vanilla React does extra work to account for anything a developer might do, but allows Elm and Om, which have more rigorous standards for the…

Vanilla React doesn't do property diffing by default, it re-renders the whole tree then diffs the whole virtual DOM, because it can't rely on data immutability or on components purity. Since Om or Elm assume immutable inputs and pure components they can skip rendering components altogether when the inputs have not changed (mentioned in TFA's "Making Virtual DOM Fast"). React can do that, but it has to be opted in com…

Gotcha—I'd assumed property diffing was the way to go because it hadn't occurred to me that folks would be writing impure components. Thanks!

Re: Virtual DOM in Elm

#37

Post by STRML »

jlongster wrote: post #14
smizell wrote: post #10

Earlier quoted context omitted.

Do you have any code samples online of this combination? I'd be interested to see how these are used together, because they seem like a great fit.

Not yet, I've been dying to dig into this for months but now just getting some time to do so. I'm rewriting my blog with lots of cool technologies like this and going to open-source it and write up about it. http://jlongster.com/

Just wanted to add my support with this - I am using React+Fluxxor+ampersand-collections, and I find myself simply rebuilding the collections on every change (and disabling their add/remove/set/reset functions) to keep them immutable and speed `shouldComponentUpdate`, but I would rather be using mori.

When you use something like mori, but you need to define data transforms, such as float precision, derived attributes, and so on, how do you make that work well in your apps without too much complexity in your components? One thing I really enjoy about ampersand-state and ampersand-collection (forks of Backbone) is that I can define very simple, standard functions per model so that my views don't have to have any idea what was passed to them. How would that be possible in Mori? Do you use something like a `__type` attribute so an external utility can suss out what the object is and transform it correctly?

Re: Virtual DOM in Elm

#38

Post by kasbah »

nickthemagicman wrote: post #29

Anybody have any good reviews on elm?

It is fun to play with and I managed to pick it up very quickly (after having already spent a significant amount of time learning Haskell).

I am a bit concerned about the lack of typeclasses and what that could mean if I try and build something bigger using it. Maybe I could use Purescript and Elm together.

Re: Virtual DOM in Elm

#40

Post by polskibus »

I've never heard about mercury before! Great to see more virtual DOM development.

I hope the new framework gets animation right, I'd love to see it as flexible as in D3, in my opinion this is something currently React currently lacks (the transitions are there but they are too simplistic to cover complex web app cases).

Post reply on HN