#ActuallyAutistic web dev. Does front of the front-end. Loves perf and minimalism. Prefers HTML, CSS, Web Standards over JS, UX over DX. Hates div disease.
That is great for you! Although in general I'm more worried about the output than the input.
Clean code is pretty relative: you can have code that looks pretty and understandable looking at it, but it may behave suboptimally. React has (at least) two major suboptimal solutions behind the background: virtual DOM, and memoize-reliant hooks. Both consume memory and CPU time to provide a better developer experience. This is one price you pay to achieve a clean and concise when writing React, and you can't workaround them as everything is based on those two solutions.
So you are the kind of developer who would sacrifice code readability for performance. Performance is cheap these days, and my apps never struggle in that category. Code quality, however, is something that most people can never achieve no matter how much they try.
BTW, Hooks sucks, same for Redux, or Styled Components. If you fall for them, no wonder you hate React
#ActuallyAutistic web dev. Does front of the front-end. Loves perf and minimalism. Prefers HTML, CSS, Web Standards over JS, UX over DX. Hates div disease.
No, I don't sacrifice code readability. Also, I'm wondering where you get the "hate React" part as I'm just being critical and analyzing causes for issues, avoiding to blame it on only React. As additional background I've worked on high traffic ecommerce sites, with React since 2014.
Your apps might not struggle, but looking at the web as a whole there is a lot to improve on size, first execution perf, a11y, and so on. And I've seen what seemingly simple and small looking improvements can do to a site's success. What is truly hard is to make other devs "not mess it up" over time. Code quality alone doesn't help, you need tests, and likely teaching and documentation, and a fitting culture.
React community is pretty split now on what people prefer. Others believe everyone is using hooks now, and some go all-in refactoring everything to just hooks. Some people even believe the only thing you get support for from the community is for hooks! Then, as you know of yourself, others keep on using classes and hookless function components. I just use everything balancing for best fit on a per case basis. Of course to get there I did have to write and refactor a lot to hooks to see the good points and pain points.
Styled Components is awful and wouldn't have ever made use of it, but didn't get to do that choice on what I'm working on right now. After summer vacation I'll put the best show I can to convince the team to start a change away from it.
#ActuallyAutistic web dev. Does front of the front-end. Loves perf and minimalism. Prefers HTML, CSS, Web Standards over JS, UX over DX. Hates div disease.
Likely anything that allows for automatical scoping and is zero runtime. CSS Modules possibly, or Linaria if people prefer having styled-like syntax. Personally I'd be fine even with a more traditional SCSS approach, but people don't really handle grooming CSS, and many have challenges to understand conventions like BEM. Scoping makes things a lot easier for most.
For me the major weakness with Styled Components is how much it encourages to do dynamic runtime styling with JavaScript, and because people don't always think what they're doing they add in things like react-spring which I guess feels natural to use: each time I've seen SC I've also seen some spring library added in as well. The problem is springs are for complex animations, but in the actual apps all the real use cases only needed simple two state transitions (such as accordion closed, accordion open). Total overkill to add JS to control the entire animation. Controlling the boolean state is enough.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
That is great for you! Although in general I'm more worried about the output than the input.
Clean code is pretty relative: you can have code that looks pretty and understandable looking at it, but it may behave suboptimally. React has (at least) two major suboptimal solutions behind the background: virtual DOM, and memoize-reliant hooks. Both consume memory and CPU time to provide a better developer experience. This is one price you pay to achieve a clean and concise when writing React, and you can't workaround them as everything is based on those two solutions.
And for most projects this is totally OK.
So you are the kind of developer who would sacrifice code readability for performance. Performance is cheap these days, and my apps never struggle in that category. Code quality, however, is something that most people can never achieve no matter how much they try.
BTW, Hooks sucks, same for Redux, or Styled Components. If you fall for them, no wonder you hate React
No, I don't sacrifice code readability. Also, I'm wondering where you get the "hate React" part as I'm just being critical and analyzing causes for issues, avoiding to blame it on only React. As additional background I've worked on high traffic ecommerce sites, with React since 2014.
Your apps might not struggle, but looking at the web as a whole there is a lot to improve on size, first execution perf, a11y, and so on. And I've seen what seemingly simple and small looking improvements can do to a site's success. What is truly hard is to make other devs "not mess it up" over time. Code quality alone doesn't help, you need tests, and likely teaching and documentation, and a fitting culture.
React community is pretty split now on what people prefer. Others believe everyone is using hooks now, and some go all-in refactoring everything to just hooks. Some people even believe the only thing you get support for from the community is for hooks! Then, as you know of yourself, others keep on using classes and hookless function components. I just use everything balancing for best fit on a per case basis. Of course to get there I did have to write and refactor a lot to hooks to see the good points and pain points.
Styled Components is awful and wouldn't have ever made use of it, but didn't get to do that choice on what I'm working on right now. After summer vacation I'll put the best show I can to convince the team to start a change away from it.
What would you use to quit Styled Components ?
Likely anything that allows for automatical scoping and is zero runtime. CSS Modules possibly, or Linaria if people prefer having styled-like syntax. Personally I'd be fine even with a more traditional SCSS approach, but people don't really handle grooming CSS, and many have challenges to understand conventions like BEM. Scoping makes things a lot easier for most.
For me the major weakness with Styled Components is how much it encourages to do dynamic runtime styling with JavaScript, and because people don't always think what they're doing they add in things like
react-springwhich I guess feels natural to use: each time I've seen SC I've also seen some spring library added in as well. The problem is springs are for complex animations, but in the actual apps all the real use cases only needed simple two state transitions (such as accordion closed, accordion open). Total overkill to add JS to control the entire animation. Controlling the boolean state is enough.