Our company built an in-house front-end framework heavily inspired by React and Vue. The components built using the framework work with or without jQuery. No manual DOM manipulations, one-way data binding, sane state management, templating, etc. Many of us prefer to use jQuery because of how compact and expressive the syntax is.
It really surprises me how many people think that jQuery === old school manual DOM manipulations. It definitely doesn't have to be that way.
React also let's you mark areas/divs within its domain as "don't touch this". So in those areas you can use things like that old map widget you love so much, without resorting to iframes
Angular is a huge fail in this regard. Zero support for mixing with "non angular" pages.
React's entry point is the `ReactDOM.render` function, which takes some React elements, and a root node. that root node can be _any_ DOM node (Actually no idea if you can mount React into a inline SVG, but at least any _HTML_ node you certainly can). You can also have multiple `ReactDOM.render` calls, no problem at all.
That initial React element can very well take values and callbacks from your Angular or whatever application.
It can get messy if you nest `ReactDOM.render` within roots that are managed by React, but so would nesting any other UI framework, but the use cases for that are... Exuberantly exotic, to say the least.
Usually, people have a single “mount point” very close to the <body> element, and a single script file whose primary purpose is to call ReactDOM.render to “mount” a React component representing their application at that point.
However, that doesn’t prevent you from having DOM outside that mount point, and it doesn’t prevent you from having code which does other things that don’t have anything to do with the React-managed part of the page. This is a great way to migrate a legacy application to React: you choose one small section of your page to replace with React, and then have the remainder of your page interact with it by 1.) choosing when to call ReactDOM.render again to ask it to update, and 2.) passing in callbacks so the React ”mini-app” can notify the rest of your application when something happens.
You can go the other way, too, although it’s a little less safe. If you have a React component which renders, say, a <div> with no children, you can get a handle to the DOM element itself and interact with it just like you would in a non-React application. The only constraint here is that you have to make sure to clean up e.g. event handlers and release references to those elements if something causes the “owner” React component to unmount. This is how people make wrapper libraries which let you use non-React-based libraries using React components. (I’ve done this in a side project where I had a huge number homogenous DOM elements to work with, and found that managing them myself was much more performant than trying to run them through React’s model.)
I'm sure experienced people know how to do that properly, but it's really difficult starting out.
Too much abstraction, too much magic. It's possible to do just about anything but the docs are sparse enough that you'll be crawling through github PR's and source to figure out how to achieve it sometimes
Having worked in complex interactive React/Angular apps as well as ones using JQuery, nobody would ever offer me enough to use JQuery again for this use case. They would have to double my pay for all the pain
If I want a fancy drop-down with accessibility support and theming etc, there's probably 50 different libraries with components I can pull in and use with little fuss. A few lines of code to import and register event listeners.
I was a huge user of jQuery for years, and it also has quite nice UI libraries. But the power of React is the standardized scaffold and lifecycle. I can pull in UI components from almost any library and use them intuitively. Mix and match them on the same page.
Trying to do that in jQuery will quickly drag you to hell.
Can you elaborate on this please ? I've used lots of libraries with jquery and haven't encountered problems.
In React you can "scope" a components CSS so none of the styling leaks out
If you want some specific code to criticise, there's dozens of dropdown menu widgets available: here's one I found in Google https://github.com/react-component/menu since I've never actually had reason to use a js/html drop down menu widget.
https://github.com/wisercoder/uibuilder/blob/master/SimpleDe...
For example, in vanilla JS, you might have something like:
const btn = document.createElement('button');
btn.className = 'btn red';
btn.onclick = function(event) {
if (this.classList.contains('red')) {
this.classList.remove('red');
this.classList.add('blue');
} else {
this.classList.remove('blue');
this.classList.add('red');
}
};
class Button extends React.Component {
state = { color: 'red' }
handleChange = () => {
const color = this.state.color === 'red' ? 'blue' : 'red';
this.setState({ color });
}
render() {
return (<div>
<button
className=`btn ${this.state.color}`
onClick={this.handleChange}>
</button>
</div>);
}
}
For "regular CRUD developers", the vast majority of us, I have zero concern about how big or crazy component code is until it's so huge it impacts page size. I'll use the easiest most feature complete library out there.
React does encapsulation like jQuery never could. I don't care if I have this vanta black box on my page as long as it's easy to mess with and gets the job done
The complexity is shifted to the library that hopefully has thousands of users so is mostly bug free. It simplifies my code at the expense of moving complexity to the shared project. Much preffered since my code will see orders of magnitude less usage than the library itself
jQuery is a DOM manipulation utility library. React is a view rendering library, favoring composition and isolated components.
I agree with JQuery for the most simple sites, but React+transpiler will give you much better compatibility