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

61–70 of 117 posts

Re: Virtual DOM in Elm

#61

Post by danabramov »

dustingetz wrote: post #52
danabramov wrote: post #32

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…

Yeah, the Om beginner tutorial demos this in lighttable with clojurescript, it's pretty epic. edit: https://github.com/swannodette/om/wiki/Basic-Tutorial

Where can I take a look? In my case, this is pure JS, no Light Table or browser plugins needed. No messing with V8.

Re: Virtual DOM in Elm

#62

Post by danabramov »

lbotos wrote: post #56
danabramov wrote: post #32

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…

What editor are you using in that gif? Or is that just 10.10 that makes it look "cleaner"?

10.10, Sublime with Spacegray Light by Gadzhi Kharkharov

Re: Virtual DOM in Elm

#63

Post by glibgil »

brandonbloom wrote: post #51
glibgil wrote: post #33

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/...

Because the underlying DOM is essentially untyped. This is a low-level adaptor library. One could easily build a more strictly typed wrapper on top.

Let me rephrase the question: why haven't they already?

Re: Virtual DOM in Elm

#64

Post by danabramov »

saurabhnanda wrote: post #60

As a startup who's built all of its UI on AngularJS, does introducing React/Om into the stack make sense? We have a B2B product where the users deal with a lot of CRUD forms and dashboards. React looks interesting, but only if it gives significant advantages (time-to-market, maintainability, etc) vis-a-vis AngularJS in managing a large code-base. Any first hand reviews?

We used Angular at Stampsy and it was a pain to learn and debug. React is awesome because it encourages very modular components, has very small API surface (you can go far with knowing 5 API methods, compare this to Angular insanity) and great out-of-the-box performance (which is possible to boost 5x if you use performance hooks like `shouldComponentUpdate`). React gets you very close to browser limits in terms of perf, while staying very maintainable. Moreover, it doesn't impose any kind of structure on your projects, and you can begin using it one component at a time (even inside Angular).

(I'm not affiliated, just a very happy user.)

Re: Virtual DOM in Elm

#65

Post by danabramov »

saurabhnanda wrote: post #60

As a startup who's built all of its UI on AngularJS, does introducing React/Om into the stack make sense? We have a B2B product where the users deal with a lot of CRUD forms and dashboards. React looks interesting, but only if it gives significant advantages (time-to-market, maintainability, etc) vis-a-vis AngularJS in managing a large code-base. Any first hand reviews?

We used Angular at Stampsy and it was a pain to learn and debug. React is awesome because it encourages very modular components, has very small API surface (you can go far with knowing 5 API methods, compare this to Angular insanity) and great out-of-the-box performance (which is possible to boost 5x if you use performance hooks like `shouldComponentUpdate`). React gets you very close to browser limits in terms of perf, while staying very maintainable. Moreover, it doesn't impose any kind of structure on your projects, and you can begin using it one component at a time (even inside Angular).

(I'm not affiliated, just a very happy user.)

Re: Virtual DOM in Elm

#66

Post by Raynos »

loz220 wrote: post #42

Having done some benchmarks with TodoMVC before, I knew something was off about these results. They play to the strengths of the virtual dom approach by manipulating the benchmark via dom instead of what ever interface was implemented within each TodoMVC implementation. So I forked the benchmark and changed both the Backbone and Mercury implementations to work through their respective apis. Here it is: https://github…

In all javascript apps the part that is slow is the DOM, not the javascript interface.

This benchmark was taken from the webkit source code then forked into http://vuejs.org/perf/ then forked to include mercury then forked again to include elm.

Neither elm nor mercury came up with this benchmark and just added themself to it.

What this benchmarks shows is that async rendering is really fast. Mercury, vue & elm all use async rendering where DOM effects are batched and only applied once.

A better, close to real user experience benchmark would be one using mousemove since that's an event that can happen multiple times per frame.

Re: Virtual DOM in Elm

#67

Post by peterhunt »

syntern wrote: post #59
syntern wrote: post #9

Earlier quoted context omitted.

Our performance benchmarks suggest that application performance is most certainly better off with: (a) DOM reuse (b) calculating expensive things only once (c) reducing GC pressure == not discarding/recreating things (d) coordinating actions that may trigger reflow. It is independent of what framework you are using. My limited understanding of React is that it fails in (a), (b) and (c), and only limited measures can…

While each use case is different, I'd like to clarify a few things in my OP. DOM reuse is not the same thing moving a DOM subtree to a different place. DOM reuse is e.g. getting an already-rendered table row, binding a new value to it, and modifying only the DOM properties in the complex DOM structure that actually did change. E.g. you modify only an Element.text deep in the first column, and a few other values in th…

You get all of this for free with React.

DOM node reuse is perhaps the central theme of React so it's odd that you bring this up as a criticism (see https://www.youtube.com/watch?v=1OeXsL5mr4g)

Calculating the virtual DOM does come with some processing and GC overhead, yes. But any system that tracks changes for you (data binding) comes with overhead and React makes the right set of tradeoffs for real apps (since it is a function of how large your render output is, not your underlying data model). React has about a 70% edge in CPU time on Angular in the "long list" class of benchmarks (which drops to a mere 40% with the Object.observe() performance unicorn). And steady state memory usage is almost always better with a virtual DOM approach since again it only tracks what you actually render which is usually smaller than your data model (https://www.youtube.com/watch?v=h3KksH8gfcQ).

DOM coordination boils down to non-interleaving of reads and writes to the DOM. React manages the writes for you which happen in one go. Components have a well-defined lifecycle which is also batched and are only allowed to read from the DOM during specific points in the lifecycle, which are coordinated system-wide. So out of the box if you follow the guidelines you will thrash the DOM much less (see http://blog.atom.io/2014/07/02/moving-atom-to-react.html)

Re: Virtual DOM in Elm

#68

Post by dustingetz »

jlongster wrote: post #58
dustingetz wrote: post #54

Earlier quoted context omitted.

What are you using Mori for that react.addons.update doesn't do?

react.addons.update is a poor man's implementation of something like mori. I'm not going to go into details right now (also still early in research), but mori is way more efficient and provides a better API for working with this kind of stuff (`sort` return a new obj, etc).

Can we improve react.addons.update then? Mori is not syntax compatible with javascript datastructures, and needs to be marshalled to interop with javascript components. If you include marshalling overhead, mori is in the same ballpark as react.addons.update.

http://jsperf.com/sprout-vs-mori/3

Re: Virtual DOM in Elm

#69

Post by dustingetz »

saurabhnanda wrote: post #60

As a startup who's built all of its UI on AngularJS, does introducing React/Om into the stack make sense? We have a B2B product where the users deal with a lot of CRUD forms and dashboards. React looks interesting, but only if it gives significant advantages (time-to-market, maintainability, etc) vis-a-vis AngularJS in managing a large code-base. Any first hand reviews?

YES - I've built two enterprise app frontends (CRUD forms and dashboards) in react since react came out. Now that I know what I'm doing and have my tools built out, I am contracting and hitting ridiculously tight schedules that I would never have been able to hit without the level of abstraction react enables. It helps that a react codebase is massively smaller than a comparable OOP-style codebase (I've used Backbone, Knockoutjs, and ExtJS in comparable apps)

Re: Virtual DOM in Elm

#70

Post by jlongster »

dustingetz wrote: post #68
jlongster wrote: post #58

Earlier quoted context omitted.

react.addons.update is a poor man's implementation of something like mori. I'm not going to go into details right now (also still early in research), but mori is way more efficient and provides a better API for working with this kind of stuff (`sort` return a new obj, etc).

Can we improve react.addons.update then? Mori is not syntax compatible with javascript datastructures, and needs to be marshalled to interop with javascript components. If you include marshalling overhead, mori is in the same ballpark as react.addons.update. http://jsperf.com/sprout-vs-mori/3

That's the thing I love about React though; you don't have to marshal if you embrace mori wholesale. I can render components based on these data structures and never have to "reify" them into real JS data structures.

That said, I'm probably being overly optimistic and I'm just starting to research it. I don't quite like how addons.update feels like a bandaid, but maybe it is good enough. Haven't done enough research yet. I definitely don't like writing updates the way addons.update forces you to, but sweet.js macros could solve that (and I was going to write macros for mori anyway).

Post reply on HN