Anyone know of a Haskell or proper Haskell subset that can do something similar (hopefully batteries included)?
Virtual DOM in Elm
11–20 of 117 posts
Re: Virtual DOM in Elm
#12You can run the tests by yourself here: http://evancz.github.io/todomvc-perf-comparison/
Re: Virtual DOM in Elm
#13I've been thinking why there's no virtual dom implementation other than react. Glad to see there's finally some out there.
Re: Virtual DOM in Elm
#14This technique may be the most revolutionary thing in web development in the last several years, IMHO. I've been using React for a while, and starting to integrate Mori for persistent data structures, and the things I can do with it is insane. The fact that it's not only far better performant, but a way better abstraction for dealing with UIs, is crazy.
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/
Re: Virtual DOM in Elm
#15My 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…
It's worth noting that Om uses React internally[1]. React, like almost every tool out there, can work very well when used appropriately, or poorly if use in appropriately.
[1] http://swannodette.github.io/2013/12/17/the-future-of-javasc...
Re: Virtual DOM in Elm
#16Earlier quoted context omitted.
I've seen some AngularJS vs React benchmarks a while back. I believe it was http://jsperf.com/angular-vs-react/5 I consistently got the result of Angular utterly and completely destroying React. Initially I blamed the virtual DOM approach, but after seeing other frameworks utilizing it and outperforming Angular by a huge margin, it seems to me that React is not written for performing well on small DOM documents. (The…
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…
> Re-creating the entire DOM on each update probably does not help
Perhaps you meant virtual DOM here? (in any case, the actual DOM is not recreated on every update)
Re: Virtual DOM in Elm
#17This technique may be the most revolutionary thing in web development in the last several years, IMHO. I've been using React for a while, and starting to integrate Mori for persistent data structures, and the things I can do with it is insane. The fact that it's not only far better performant, but a way better abstraction for dealing with UIs, is crazy.
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.
elm-lang.org has some really great demos. http://elm-lang.org/Examples.elm
I haven't dug deep enough to form an educated opinion on the language, but so far its refreshing to see such a drastically different process than popular languages today.
Re: Virtual DOM in Elm
#18My 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…
(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?)
Re: Virtual DOM in Elm
#19Earlier 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/
Cool, I'll keep an eye out. Any reason to use React+Mori over Om other than more familiarity with JavaScript??
Re: Virtual DOM in Elm
#20My 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…
I've seen some AngularJS vs React benchmarks a while back. I believe it was http://jsperf.com/angular-vs-react/5 I consistently got the result of Angular utterly and completely destroying React. Initially I blamed the virtual DOM approach, but after seeing other frameworks utilizing it and outperforming Angular by a huge margin, it seems to me that React is not written for performing well on small DOM documents. (The…
That benchmark confuses me; is it measuring the entire run of that script, i.e. is it measuring the setup (creating class, inserting into dom) on every run? If so that seems like the wrong way to go about testing performance.