trixn's comments

MMT proponent Bill Mitchell calls that "groupthink". It's really hard to get heterodox economic theory published and accepted.

I also feel like this really is one of the biggest pain points when writing single page apps. There is no good standard and everybody is promoting his/her way to do it that works well in a TODO app example but kinda fails in a big production application.

I agree that you could in a lot of cases get along without these classes. But sometimes you want e.g. an anchor acting as a button in a web application. Or you want a button element with browser styles. You could argue that this is also already an anti-pattern but it does way less harm then leaking inline styles into the namespace and it is still semantic. Also this was just an example (maybe not the best one) to illustrate my point that class names should be semantic and not express solely presentational attributes. The later is what styles are there for.

Especially in a javascript driven web application you may want to select all "buttons that are disabled". But you never want to select elements that "have a rounded border of 2 px and a grey background and italic font style and....". This takes class names ad absurdum.

I don't like that concept of essentially inlining styles in the class attribute. It is just a misuse of html classes.

Class names should be used sparingly and describe the semantics of an element rather than its visual appearance. It should be something like class="button submit disabled" instead of class="f6 link dim br1 ph3 pv2 mb2 dib white bg-black".

If anything these styles should be exposed as sass mix-ins that you can use in your own styles. So you have a named set of style mix-ins that do not pollute class names.

I feel exactly the opposite is the case. Hooks can improve expressiveness a lot by helping developers to separate concerns and keeping logic that belongs together in a separate place.

While I understand the argument that hooks encourage to make dumb components stateful this is already the case with class based components. At the end of the day a developer is responsible for separating concerns of his application and he can fail to do so with class based components and hooks the same way.

As I understood it you should not opt-in to use state conditionally in your component but you can still conditionally set the state. That means you should not conditionally call `useState` but it is fine to conditionally call the `setState` returned by the `useState`. That is not different to how you would use state in a class based component where you also wouldn't attach a state `this.state = {...}` somewhere in the middle of its lifetime. The component has state from the beginning of its lifetime or it hasn't state at all. There is not such concept as "Now that you are expanded you will transform into a stateful component".

A lot of my components contain something like this line: const Comp = ({children, className}) => {}.

If you need to merge it with some statically applied class names in your component you need to access it. This is an absolutely common thing. It would be terrible if i'd need to access it by using a string. And even then I would need to assign it to a name other then "class" which makes it even more confusing then naming it "className" by convention.

React is quite consistent in naming things and if you write 100's of components (which you should easily accomplish if you use it seriously) then you will never mix up className and class. In fact almost everything in react is camel case which is also the most commonly used style for naming variables in javascript. This makes it very comfortable to create objects from variable names and spread it as props. It really did never annoy me at all (Maybe the first 10 components I wrote :D )

Also if you use a sophisticated IDE that shouldn't be an annoyance at all.