Hi Guys,
I’m building an app where users will be able to use a page builder plugin to manipulate the DOM. They’ll be able to drag and drop elements, change css etc.
React relies on it’s virtual DOM so I presume moving elements around all over the place could brake things quickly.
I’m thinking Blaze would be better for this setup rather than React and would love to get some other opinions?
Thanks
I cannot speak to your exact scenario, however there is a video where tons of data is updated, tons of DOM updates, things moving around and React absolutely smokes everything - with Ember being the worst performance wise.
Let me try to find it.
Edit: Here ya go: React.js Conf 2015 - Hype! - YouTube
React is a safe choice performance wise, rendering will not be your bottleneck.
Thanks @sergiotapia 
I’m just concerned because I’ll be using a page builder plugin, probably built in jQuery and I’ve read a few things saying you shouldn’t manipulate the DOM with React because it can lose track of the elements that you change etc.
That’s just a catch all statement, I suggest you don’t take it as 100% dogma.
I wrote an application that used jQuery plugins like Masonry and manipulated the DOM and it works perfectly. I think what they’re saying with that soundbite is don’t change the values in the DOM, right? Modify the data and render() will take care of you, and that’s sound advice.
The benefit of using React is that you can bind the DOM references directly within the component. That means you won’t be grabbing DOM elements that you shouldn’t be grabbing.
For example, if I wanted to grab all the image elements and do something with them, I might want to do something like this in plain jQuery:
$('img')
But what happens when you start adding <img> tags elsewhere that you don’t want included in this behaviour? The problem here is because the jQuery selector is inherently a global catch-all, that means you won’t be able to be as certain about what elements you are actually grabbing.
In React, I can write in my component:
<img ref={x => this._myPicture = x} src=".../img.jpg" />
And in one of my component methods, I can simply refer to the element with:
const picture = this._myPicture;
Now I can do whatever I want with picture and it is extremely clear and explicit what you are referring to, where, and how.
Of course, this might make some jQuery plugins unwieldy to implement, so it’s always going to be a trade off. But with React you can be very certain of which element you are actually manipulating.
Thanks @adrianmcli that was my understanding of React as well.
@sergiotapia that video is really helpful. Especially when he talks about Portals. Basically creating a whole new container that you can mess around with using jQuery plugins etc that won’t effect React! 
great stuff, thanks again!
But isn’t there the same effect when I use this.templateInstance.$(“img”)? In that case jQuery would only manipulate all img elements within the current template, so when I think in component logic I would do something like this:
Template.picture.viewmodel({ //some logic & state });
and the template for it:
<template name="picture"> <img src="..." /> </template>
In case of ViewModel I could also add a reference to each instance and access it from other parts of the application.
That’s a good point. I never thought to do that, but I also haven’t used Blaze nor ViewModel in quite a long time. Perhaps I am biased here, but I do think there’s a lot of value in being forced or at least strongly encouraged to be explicit and component-like in React.
Nevertheless, there are very simple composable React components on NPM that will help you implement drag and drop in literally 3 lines of code (the import statement and the two wrapping tags). Building one of these things up from scratch might be easier in Blaze simply because you don’t have to adapt to React’s way of doing things, but for OP who I assume is concerned about productivity, I would still recommend React over Blaze.
Speaking specifically to the OP’s needs, if I wanted to allow the user to “drag and drop elements, change css etc.” I would definitely do it in React. Otherwise you’d be building up a lot of components from scratch that already exist. Not to mention that the dynamic application of styles in React is a lot easier since it’s all built-in already anyway.
Thanks @adrianmcli - I’ll check out the components you mentioned on NPM, thats handy to know.
I’m more versed in React, I’m actually coming at this from a React first angle. I just wasn’t sure it could handle the heavy DOM manipulation I’m looking for and thought Blaze might be a better option. I’ll try it out in React and see how it goes anyway. Thanks again.