Sure. For an example of DOM side effects, I would have a template that would trigger a bunch of jQuery operations on render. Things like tooltips, Bootstrap widgets, etc… Basically anything in the DOM that Blaze is not directly manipulating itself. To Blaze’s credit, it works really well with other libs and widgets manipulating it’s DOM.
Another issue is keeping track of state that is not saved to the database. Here’s a use case that helps think about the differences in handling state.
Consider this use case. You have to build a large form like the heathcare.gov website where you’re going through lots of ‘steps’ and over a hundred inputs. They would like the form to be filled out before saving it to the database, and it must have the ability to let the user go forward or back in steps, or even skip a step and go back later. Also to keep the form short they want you to dynamically add more sections as needed, for example having an add button to add in an additional set of inputs for each household member.
So this is where React starts to shine. The whole view library is setup to handle state by either holding state in it’s own component or ideally getting state from it’s props passed in by the parent (this makes it easier to test typically). Any change to a components
state will trigger a re-render and the re-render cascades down every child (unless canceled by performance methods). This doesn’t sound astonishing but even with non-reactive data the children will be guaranteed to update to their new representation [This video] explains it better than I ever could but the component starts to look like a pure function, it takes arguments (props) and returns it’s representation of the DOM based on state and props.
To be fair, Blaze can handle this problem (the form example). Now that Blaze has template instance variables that can mimic React’s concept of
this.state, it’s do-able but more verbose than React. In my experience this is where the simplicity and brevity of Blaze breaks down. Now you have 20 templates with 20 linked JS files, all having to deal with it’s template state lifecycle, and sharing state from another parent template.
Blaze is a nice templating language but the more complex the app the less appealing it is. (it wins 9/10 times for small examples)