Waaaooww what a position

I’d want to disagree bc I know Nix and that feels declarative to me where as html just feels like actual drawing, like there’s no conditional or iteration therefore how are you transforming information? HTML is a markup bc you need to render a UI and you don’t know anything about the screen or keyboard&mouse so cope

This is a LinkedIn screenshot, sry if I cropped it too tight

A bunch of weeks ago the CTO of my company calls me up to ask about my prejudice against the useState hook, I’m guessing I’ve just been giving my team too much shit in code reviews about them using useState hooks and they went to complain to him and he asked me to explain what the value of the useReducer hook was.

His background is Java, Microsoft Java, C++, and not much else.

So I was able to explain to him the value of the useReducer hook is a lot like the common class object. In useReducer you’re expected to write discreet state mutations and the state could potentially have more than 1 primitive field that gets mutated, and that’s just what object classes are! In an object class you’re writing methods for mutating the underlying state, the reason I think most people don’t feel like these two things are the same is because of the functional appearance of the reducer function and how in object classes you have the this as a variable just like any other, so you’re not returning a new state.

So just like in react where they’re installing REDUX (like three generations of their families would be massacred if they didn’t) just to write a switch case statement that puts the action in variables in the state. Bad programmers are just bad.

Only typescript is great. Raw JavaScript is like rawdogging someone (iykyk), you get STDs

I’m so heartbroken by the idea of unit tests. My first job was at a home automation startup and our primary product was a device that we would send ota firmware updates to. The device was based on an esp32, and because it received software updates from the app it had to be 100% robust and had full test coverage and the mono repo that would compile the firmware was gorgeous.

I’m a web developer and I’ve been wanting to replicate that exact experience ever since but I just can’t get any team on board. It’s gone to the point where if the llm writes a unit test I’ll just commit it so I don’t care.

React works by maintaining a virtual representation of the DOM. When you dispatch state changes into the virtual DOM react can determine which components depend on the change and which side useEffects run.

My gripe is that YouTube tutorials teach that the useState is the equivalent of a variable. This encourages average developers to problem solve solutions that end up using React’s Virtual DOM for business logic. The YouTube tutorials have react devs planting 100s of useStates - some of which don’t directly induce a visible-on-screen rerender - and then ⅒ as many useEffects to bind these states together. This means that for the Virtual DOM to come to the conclusion as to what html elements need to be changed and how it has already mutated 20-50-100s of times and the CTO tells me the react app is slow and they’re mad.

If 2 states have the opportunity to mutate each other back and forth then the truth is that you have 2 perspectives of the same state. And React gives you solutions for that - proper solutions - the useReducer hook is for defining these complex state mutations and the Context API for communicating that state to any component.

And this has me quintuple pissed off because these same tutorial grade react devs install REDUX as compulsively as a pack-a-day smoker (that’s #3). They use Redux to file variables in JavaScript memory (that’s #4) like it’s a global variable and rarely if ever use it for the complex state mutations they need instead I’ve seen react devs write components pull state out of redux into a component just so it can mount useEffect and process the state and dispatch the result back into redux. Let’s not even bring up how the react-redux binding library literally uses the React Context API (that’s #5).