https://en.wikipedia.org/wiki/Genetic_fallacy :P

IMO there are far greater concerns with centralized API services, which are nearly always opaque, closed-source, and incentivized towards vendor lock-in (AWS being the elephant in the room).

"Staking careers" is also a little much; React isn't that hard to learn (it's near-trivial compared to .NET or iOS development), and any developer worth their salt will have to frequently retrain into new patterns and frameworks during their career.

There can be legitimate concerns with power concentrations of open-source software based on the incentives of its stewards (Chrome comes to mind); but ultimately React carries a relatively small footprint, and can always be forked [0] if it goes in a direction that developers don't like.

[0] https://preactjs.com/

Not to mention the hideous use APIs. Thanks you, React, for this array which apparently contains a state and a setter?

It's almost like taking the verbosity of class lifecycle methods, and 'pre compiling' it into a form which is terser, yes, but that now only a sufficiently informed reader can grok - the lifecycle is still there, it just has to be modelled by the reader instead of by the code.

Sometimes this is a good tradeoff, but not always.

As someone who started off thinking hooks were too "magic" to be taken seriously, such concerns are a thing of the past.

If you just think of calls to useState as variable declarations, it makes zero sense that you'd ever want to call useState in a different order.

this -

    let userName = 'bob';
    let favouriteColour = 'purple';

    let [ userName, setUserName ] = useState('bob)';
    let [ favouriteColour , setFavouriteColour ] = useState('purple)';

Hooks felt extremely awkward to me at first, because it was forcing me to write code in ways that felt unnatural. Once I stopped fighting it, the benefits became apparent, and now the old way feels awkward.

Hooks are to React what React was to jQuery.

Example: you have a {data, error} = fetchData() and then a useEffect(..., [data]) or 3. It would be very handy if you could just throw the error before the useEffect because you already know it's going to be irrelevant.

So then you put everything after in a new component (because that can be rendered conditionally) or keep checking for errors throughout the effects code. Both are kind of meh.

I'm not sure if this could maybe even work, actually, because there are no real out of order calls, only incomplete calls? But rules of hooks say no, and I have gotten the "hooks called out of order" error for it.

    let [ data, setData ] = useState();
    
    useEffect(() => {
    
        let result = fetchData();
    
        if (result.error) {
            //do something, or abort?
            return;  
        }

        setData(result.data);
        
        
    }, []);

    useEffect(() => {
    
        if (!data) return;

        //perform secondary chained action using the fetched data

        let result = fetchMoreData(data.guid);
        
        
    }, [ data ]);

Personally, I prefer to use things that make more sense, even if I read dozens of articles and blogs explaining them.