I'm not great at reading ClojureScript - but I'd really like to port some of the optimizations from Om, such as the rendering on requestAnimationFrame and usage of shouldComponentUpdate to Backbone.LayoutManager[1]. Swannodette, if you're around, do you have a minute to give a more in-depth explanation of how that works?
The Future of JavaScript MVCs
21–30 of 159 posts
Re: The Future of JavaScript MVCs
#22We've been thinking about this a lot lately for some of the projects we've been doing for Light Table and we've essentially been doing the same thing as what David's proposing here. What react ultimately opens up is a way to do immediate mode UI [1] on top of the DOM _efficiently_, which changes things pretty dramatically. It means we can start to treat the browser as just a renderer and get the infectious design dec…
If you want to do immediate mode, then why would you use the DOM at all? Canvas is supported in IE9+, and is much less complicated for such applications.
Re: The Future of JavaScript MVCs
#23How is this different from the dirty checking that Angular does in its ModelView update cycle?
Re: The Future of JavaScript MVCs
#24> Om never does any work it doesn't have to: data, views and control logic are not tied together. If data changes we never immediately trigger a re-render - we simply schedule a render of the data via requestAnimationFrame. Ember.js has done this since day one with the Run Loop. Additionally it allows to coalesce operations yourself if you need control. Angular also would not update the DOM as many times as the backb…
Yeah, I think it's rather misleading to compare om to the performance of the least optimized and most naive (on purpose, mind you) framework instead of a more robust one.
There are benchmarks comparing vanilla React to other frameworks:
http://facebook.github.io/react/blog/#todomvc-benchmarks
At least according to this data, React and Backbone are the fastest. (Om is faster than vanilla React)
One suspects that with hand-optimization the other frameworks could be a lot faster, but the point of this post is that it is fast without hand-optimizations.
Re: The Future of JavaScript MVCs
#25I know it sounds crazy, but I think your post just outlined the next 5 years of web development innovation, swannodette- This ties together a lot of ideas that are extremely important, for the first time in one place. Thanks for doing this.
I already have my own React.js+Clojurscript bridge for personal projects, because I think it's an extremely powerful web dev combination. I'm glad I can finally abandon my own library for Om!
Re: The Future of JavaScript MVCs
#26> Om never does any work it doesn't have to: data, views and control logic are not tied together. If data changes we never immediately trigger a re-render - we simply schedule a render of the data via requestAnimationFrame. Ember.js has done this since day one with the Run Loop. Additionally it allows to coalesce operations yourself if you need control. Angular also would not update the DOM as many times as the backb…
While it's nice that Ember.js provides a run loop that's not enough, just batching all your updates into one place just puts all of the work together, you'll still going to pay for the work and in the worse case you have to hand coalesce, yuck. In Om if there is no work ... there is no work, it's implicit in the system! No need for hand coalescing your state changes.
Angular.js still suffers as shown by the optimization article I linked to in my post. These kinds of typical optimizations can and should be pushed out of the user's hands.
Re: The Future of JavaScript MVCs
#27I've been expecting this after seeing a few of your teaser tweets and as expected I absolute love it! I've been waiting for something like this ever since I read up on persistent data structures and functional reactive programming almost 10 years ago. I'm wondering how this compare to the Javelin library as that seems to offer the same functionality when combined with hlisp. Would I be correct in saying that Om achie…
I haven't looked at Javelin enough to have a strong opinion about it. Om at the moment is completely focused on rendering EDN data and making that blazing fast. Personally I think representing UI components as generic data has a lot of legs. I also don't really believe in templating languages, but I also think that functional boilerplate for rendering children is a bummer. I'd like to see a client side query language…
I'll be diving into the source code soon to figure it out, but are you then using core.async only to handle incoming user events or also to coordinate the rendering of the UI?
Re: The Future of JavaScript MVCs
#28Earlier quoted context omitted.
Yeah, I think it's rather misleading to compare om to the performance of the least optimized and most naive (on purpose, mind you) framework instead of a more robust one.
There are benchmarks comparing vanilla React to other frameworks: http://facebook.github.io/react/blog/#todomvc-benchmarks At least according to this data, React and Backbone are the fastest. (Om is faster than vanilla React) One suspects that with hand-optimization the other frameworks could be a lot faster, but the point of this post is that it is fast without hand-optimizations.
Keep in mind that those benchmarks don't use the requestAnimationFrame() batching strategy (out-of-the-box it's not installed since it makes testing harder since you have to wait for the next frame) like swannodette mentions.
I'd be interested to see these numbers after doing `npm install react-raf-batching` and doing `require('react-raf-batching').install()`.
Re: The Future of JavaScript MVCs
#29> Om never does any work it doesn't have to: data, views and control logic are not tied together. If data changes we never immediately trigger a re-render - we simply schedule a render of the data via requestAnimationFrame. Ember.js has done this since day one with the Run Loop. Additionally it allows to coalesce operations yourself if you need control. Angular also would not update the DOM as many times as the backb…
How does the performance of this compare to AngularJS? Also a common performance issue in AngularJS is when there are too many watchers (such as a large table with many rows and columns) which causes the $digest to become really slow. Would Om/React avoid these kind of performance issues?
Re: The Future of JavaScript MVCs
#30We've been thinking about this a lot lately for some of the projects we've been doing for Light Table and we've essentially been doing the same thing as what David's proposing here. What react ultimately opens up is a way to do immediate mode UI [1] on top of the DOM _efficiently_, which changes things pretty dramatically. It means we can start to treat the browser as just a renderer and get the infectious design dec…
If you want to do immediate mode, then why would you use the DOM at all? Canvas is supported in IE9+, and is much less complicated for such applications.
[deleted]