I suppose this could be seen as validation that the new approach it takes to rendering and organizing UI is a good one, if competing frameworks are trying to mimic or integrate with it.
I suppose this could be seen as validation that the new approach it takes to rendering and organizing UI is a good one, if competing frameworks are trying to mimic or integrate with it.
React's component orientations look at little easier to pick up and get going with, and it'll be a lot more familiar feeling to our UI team who have been passing data down a tree of components for some time now.
However, I have yet to build anything substantial in it, but so far I'm hopeful (I shall disregard Flux for now, we may not require its complexity just yet). The data binding all looks to be one way, and each component looks testable in its own right.
So hopefully I'm not just jumping on yet another bandwagon.
> Ractive uses similar techniques to Glimmer - it parses the template into a structure such that it's very easy to identify which DOM nodes need to be updated when data changes. This is different to how React (for example) handles DOM updates, which involves re-rendering everything and then running a diff.
> The two approaches both have the same goal - minimising DOM updates - but go about it in very different ways. Each has advantages and disadvantages, and I believe we're going to develop a much clearer understanding of what they are in 2015.
I haven't, but I'll have a look now. Cheers. :)
1. Meteor isn't a client-side framework, it's a full-stack platform;
2. This post was written by a member of the community, not someone on the core team, so I don't think you can say "desperate to jump on the React bandwagon"
If this isn't what you meant, ignore my post, just wanted to mention those two things :)
As previous responses have shown, I didn't think through this comment too well. Just trying to articulate a feeling I had about a lot of recent posts regarding React, but it looks like it doesn't really pertain to this article.