Interesting... with webpack, will often inject $, jQuery and window.jQuery via webpack.ProvidePlugin ... I'm more inclined to avoid jQuery altogether these days if possible.
The query engines in most browsers is as good as I need.... document.querySelector* does what I need. With shims for Array.from, and addEventListener, that covers the major use case. Promises are in the browser and bluebird has more as a better alternative. Axios and fetch are better options for remote requests, already promise based. The value add for jQuery (as a pretty big library) just isn't as worth it to me.
It's getting to a point that it's worth considering having two builds in babel again... one for modern browsers, another for ES2015 target. Since most self-updating browsers and even Node have most of ES2015 now, a lot of the patching is only for IE9-11 (depending on what you support).
Nice primer on the React way... It does take some getting used to... and aside from a few edges, really love React as an application platform. Some types of interactions (animation and drag-drop) are harder to fit though.
It seems like this should be used *VERY* sparingly, it will cause a reflow in the dom and rerender at the component level. It really seems a bit backward to me.
That said, it's a nifty idea, I just think it breaks the whole point of the virtual dom, and removes many of the advantages of react.
My extent to this is I will set the size and scroll position of the document level object into the redux store, so that it can be read by many components at once.