91–100 of 117 posts
Earlier quoted context omitted.
Thank you, this seems to do it for the innerText. Would it be too hard to apply it to the class attribute too? (I've tried to just copy the {} binding, but it doesn't work)
There you go: http://jsfiddle.net/Q2KXu/1/
Earlier quoted context omitted.
There you go: http://jsfiddle.net/Q2KXu/1/
Thank you both! I now have a much better understanding on how React works. I need to update the related performance benchmarks, it would be interesting to see how they compare side-by-side on our use cases.
[1]: http://facebook.github.io/react/docs/pure-render-mixin.html
Disclaimer: I'm the author of Vue.js. The benchmark is a fork of a fork of the Vue.js perf benchmark (http://vuejs.org/perf/).
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…
Email me if you want to talk about it.
Virtual DOM is fast, but it's not the only way to provide free and fast DOM updates. The author removed the Vue.js implementation from the benchmark, which does not use Virtual DOM but is as fast or even faster than Mercury and Elm. Disclaimer: I'm the author of Vue.js. The benchmark is a fork of a fork of the Vue.js perf benchmark ( http://vuejs.org/perf/ ).
Earlier quoted context omitted.
10.10, Sublime with Spacegray Light by Gadzhi Kharkharov
Off-topic, but are you using the 10.10 DP as your daily OS? If so, would you mind sharing a quick note of your experience? Any show-stopping issues? Better/worse?
Overall, it's been a really enjoyable experience - a stark contrast to the horribly buggy mess that is iOS 8.
Earlier quoted context omitted.
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…
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…
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.
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 pe…
I hear you about the API surface. Currentlu AngularJS has too many weird/new concepts.
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…
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.
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…
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.
Able to use cljs and don't care about designer friendly -> what are you waiting for!!!