alt Hacker NewsI think it's just the lifecycle of craftsman tooling in general.
When everyone has experience with a tool, everyone can enumerate its downsides in unison, but we can't do that with new/alternative tools.
Whether we confuse that for the new tool having no drawbacks, or we're just tired of dealing with the trade-offs of the old tool, or we're just curious about different solutions, we get a drive to try out new things.
React always had gotchas, but the question is how tolerable are those gotchas compared to the gotchas of what you were doing before. And how tolerable are Solid's gotchas going to be once you discover them. Sometimes it's a better set of gotchas and sometimes it isn't.
Replies
Very balanced response, but in my case it's less about gotchas and more about APIs. I just think other frameworks have more intuitive APIs than react. Maybe this falls in the same category as a gotcha, but I feel it's a little different.
One of the best responses I have read on this topic. Thank you
It's also easy to confuse problems that arise from failing to adequately manage the gotchas with problems inherent in the tool itself. There's a subtle distinction there that's easy to miss, especially for those with a blame-the-system sort of attitude (which I don't entirely fault).
One company I worked for had a very slow frontend. It was common there to blame the slowness on React. "React is just kind of slow."
Another company I worked for had a much larger React-based frontend, and it was fast-loading and snappy by comparison.
The difference is that the second company had much more well-established good practices in its design system, the codebase, the enforced lint checks, and the general knowledge of its engineers. They avoided performance traps that caused multiple renders of things. (The first company's frontend would render a given screen 12+ times for some state changes.)