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

101–110 of 117 posts

Re: Virtual DOM in Elm

#101

Post by porker »

dustingetz wrote: post #69
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…

Are there any helpers/libraries you use when building CRUD forms? I haven't seen one for React yet - or TBH a well functioning one in any language I use - and it's a pain point I would like to solve.

Re: Virtual DOM in Elm

#102

Post by wereHamster »

jlongster wrote: post #82
dustingetz wrote: post #76

Earlier quoted context omitted.

I've done some research too - check out this implementation of cursors, it enables drop-in O(1) shouldComponentUpdate (like Om) and is compatible with rAF batching (like Om). We explored Mori for a bit too and ended up deciding Mori wasn't worth it. (Our app was big enough that we experienced pretty brutal performance without shouldComponentUpdate. Now our bottleneck is methods like Array.prototype.map over large lis…

Very cool! I had researched this technique before, when I found cortex: https://github.com/mquan/cortex . Cortex does something very similar, except it doesn't actually do persistent data structures. Building cursors off of the addons.update stuff is a neat idea. (why `onChange` instead of `set` and `pendingValue` instead of just `value`?) I agree that you can take this really far. At this point I need to sit back an…

Hm, Cortex looks almost like my Avers (https://github.com/wereHamster/avers). With the major difference that Avers uses Object.observe instead of explicit setters/getters, and Avers mutates data in-place. I also use it with react, and haven't noticed any performance issues. But I have an idea how to make it work with immutable data (to allow === comparison in shouldComponentUpdate).

Re: Virtual DOM in Elm

#103

Post by boubiyeah »

What could possibly be done in the React.js version to make its performance closer to Mercury/Elm? I notice some 'shouldComponentUpdate' methods are already overwritten.

Or is this the limit of an overly mutable language like js?

Re: Virtual DOM in Elm

#104

Post by joesb »

nostrademons wrote: post #48
ghayes wrote: post #41

Earlier quoted context omitted.

If this technique is much more performant (batching diffs of the DOM), why don't browsers perform this "back-buffering" natively?

They do perform this "back-buffering" natively. When you manipulate the DOM in a modern (post-2009 or so) browser, it's just changing a pointer and flipping a dirty bit. The problem is that it's very easy to force a full recalculate of the whole page layout. Whenever you call .offsetHeight or .offsetWidth or .getComputedStyle, you're doing it. The full list of properties is about 2 dozen strong: http://gent.ilcore.co…

This got me wondering how React handles this requirement. Can you use React if you need to know offsetWidth/Height to do complex layout?

Re: Virtual DOM in Elm

#105

Post by ksherlock »

joesb wrote: post #104
nostrademons wrote: post #48

Earlier quoted context omitted.

They do perform this "back-buffering" natively. When you manipulate the DOM in a modern (post-2009 or so) browser, it's just changing a pointer and flipping a dirty bit. The problem is that it's very easy to force a full recalculate of the whole page layout. Whenever you call .offsetHeight or .offsetWidth or .getComputedStyle, you're doing it. The full list of properties is about 2 dozen strong: http://gent.ilcore.co…

This got me wondering how React handles this requirement. Can you use React if you need to know offsetWidth/Height to do complex layout?

Once the component is mounted (there's a componentDidMount callback) you have access to the real DOM node and can access them (or perhaps store them as a property if necessary). The DOM node is also available from event callbacks and such.

Re: Virtual DOM in Elm

#106

Post by KurtMueller »

dustingetz wrote: post #100
jmtulloss wrote: post #97

Earlier quoted context omitted.

This is really great work. Why do all of this instead of just using Om? I'm currently waffling between Om and straight react.js for a project of mine.

Project requires designers committing on your codebase -> use react with jsx Able to use cljs and don't care about designer friendly -> what are you waiting for!!!

I know you've probably answered this question a million times... but could you briefly explain your enthusiasm for clojurescript and/or om? I've been using the react js library and have been wondering what makes clojurescript a step above javascript and om a step above react.

Thank you!

Re: Virtual DOM in Elm

#107

Post by [deleted] »

boubiyeah wrote: post #103

What could possibly be done in the React.js version to make its performance closer to Mercury/Elm? I notice some 'shouldComponentUpdate' methods are already overwritten. Or is this the limit of an overly mutable language like js?

[deleted]

Re: Virtual DOM in Elm

#108

Post by dustingetz »

KurtMueller wrote: post #106
dustingetz wrote: post #100

Earlier quoted context omitted.

Project requires designers committing on your codebase -> use react with jsx Able to use cljs and don't care about designer friendly -> what are you waiting for!!!

I know you've probably answered this question a million times... but could you briefly explain your enthusiasm for clojurescript and/or om? I've been using the react js library and have been wondering what makes clojurescript a step above javascript and om a step above react. Thank you!

cljs/om gives you functional programming as a default, with javascript/react you have to work for it

Re: Virtual DOM in Elm

#109

Post by boubiyeah »

boubiyeah wrote: post #103

What could possibly be done in the React.js version to make its performance closer to Mercury/Elm? I notice some 'shouldComponentUpdate' methods are already overwritten. Or is this the limit of an overly mutable language like js?

After investigation, it turns out react has the potential to be faster than Om if it fixed its batched updates. Another huge performance issue is Function.prototype.bind which is called extensively.

The Om example does some kind of Event delegation using channels which is much faster.

Re: Virtual DOM in Elm

#110

Post by dustingetz »

porker wrote: post #101
dustingetz wrote: post #69

Earlier quoted context omitted.

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…

Are there any helpers/libraries you use when building CRUD forms? I haven't seen one for React yet - or TBH a well functioning one in any language I use - and it's a pain point I would like to solve.

https://github.com/wingspan/wingspan-forms https://github.com/dustingetz/react-cursor http://www.dustingetz.com/2014/02/18/react-dynamic-forms.htm...
Post reply on HN