Development with React is becoming similar to old school event driven desktop apps, thankfully.

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.

>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.

Easy to cause it by combining bootstrap components and JQueryUI.

In React you can "scope" a components CSS so none of the styling leaks out

Can you be more concrete?

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.

Here's one that uses jQuery. See how much simpler it is? The one you found does have more functionality, but try rewriting the one I found in React without using jQuery. I guarantee it will be much more complicated.

https://github.com/wisercoder/uibuilder/blob/master/SimpleDe...

It’s interesting that you find this “simpler”. One of the great advantages of React is that is declarative, it’s easy to understand how a component will render given a set of (props, state). Your example is quite the opposite, the render method violates this principle and each event handler manipulates the DOM using a ref. I’d call this spaghetti-React.

Did you miss the fact that this component is interactive? You can't do interactivity declaratively.

By declaratively I mean that in React you typically declare how an element should be render given the current (props, [state]).

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');
   }
  };

In React instead:

  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>);
    }
  }

I find it simpler to understand, because render, given its state, describes exactly how the UI should be.

This only works for simple cases. Where this breaks down is when you have to inspect the current state of the DOM before deciding what changes to make to it. Example: scroll an element into view if it is not already visible. More examples: drag & drop, interactive resize, etc.

It's not about how complex the component is. In my experience what matters is how easy it is to use. With React it's easy to build a world in a teacup, and that's mostly a good thing.

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

"I have zero concern about how big or crazy component code is until it's so huge it impacts page size." Me and my mobile browser would like to have a few words with you. Not everything that can execute JS is a supercomputer...performance still matters.

You don't care if the code is significantly simpler by using jQuery? I do care. Simpler code is likely to have fewer bugs and is easier to maintain.

I'm talking about my code specifically. With React I can pull in a massively complex UI component in few lines.

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

I care debugibilty and maintainibility. Many projects on github have very short life cycle. If it go unmaintained, how easy can I take over it?

I would argue that most websites have a lifetime similar to the components :). For the ones that don't, backwards compatibility on the web is amazing, only thing to worry about is security vulns

You're correct that simpler code is better, but here's my argument: Large jQuery applications are not simpler, have more bugs, are harder to maintain and have poorer performance than React applications.

jQuery is a DOM manipulation utility library. React is a view rendering library, favoring composition and isolated components.

What do you even need javascript for in a dropdown?

How else are you going to add back in the accessibility you've broken by building it with JavaScript?

For filtering as you type?