[thomasikzelf]

    <select id=dropdown>
        <option value=a>a</option>
        <option value=b>b</option>
    </select>
    <select id=a style="display: none">...</select>
    <select id=b style="display: none">...</select>
    <script>
        const $ = name => document.querySelector(name)
        $('#dropdown').addEventListener('change', ev => {
            $('#a').style.display = ev.target.value == "a"? "block" : "none"
            $('#b').style.display = ev.target.value == "b"? "block" : "none"
        }
    </script>

vs

    const [showing, setShowing] = useState(null)
    const handleChange = ev => setShowing(ev.target.value)
    let other
    if(showing == "a") other = <select>...</select>
    if(showing == "b") other = <select>...</select>
    return <>
        <select onChange={handleChange}>
            <option value=a>a</option>
            <option value=b>b</option>
        </select>
        {other}
    </>

some notes:

- The complexities of both of these tiny pieces of code is similiar (I would say)

- React needs to load a big bundle

- React spits out a large stacktrace with react internals if something goes wrong

- React is slower

- React code cannot be easily stepped through with the debugger

- React needs a build step

- React performance is very unpredictable (this is more of a problem with many elements and dynamic code)

Your next question might be what you do once your form grows huge. See my other answer to @iliaznk how I handle that.

[dsego]

Yes and then add few other pieces of state and interdependent components, the reactive code will extend, the manual patch job of connecting listeners and mutating DOM will start falling apart. The first example is okay for a one off but can't be reused as a component. It's also easy to get in a place where you have to update 3-4 different handlers to include a logic change. In a component based library/framework, you ideally update the state logic in one place and the UI just reflects that. For example, making the UI dynamic with a button that adds/removes multiple items that need this show/hide logic, you would need to attach new listeners, clean up listeners, clean up DOM items, and so on... my first example was only illustrative, but not to be taken literally. There a complex UI state in many apps, and reactivity with component based reuse is easier to manage and make sure all states are covered. Many times in my jquery years 10-15 years ago I had failed to update one piece of the DOM and there would be bugs that just aren't happening with component UIs.

[thomasikzelf]

I agree separating your UI into components is important. If React learned us one thing it is that keeping related stuff together is the way to go. Separating into components and keeping your functions as pure as possible gives you 95% of what makes React great! You can read my answer to @iliaznk on how I do this.

cleaning up listeners or cleaning up DOM nodes is rarely needed. Just remove the component element and the browser cleans up automatically.