3 ms·
I've never used Backbone, so I can't speak to its ergonomics, but I've used React (a bit back in 2015, and now again this year I've been updating my knowledge a
by kelnos 1y ago
I've never used Backbone, so I can't speak to its ergonomics, but I've used React (a bit back in 2015, and now again this year I've been updating my knowledge and re-learning it), and absolutely agree with the author's frustrations with its "magic".
I'm working on both a backend (in Rust) and a frontend (Typescript, React). The backend makes sense; the code I write does what I expect it to, and there's no magic. The frontend... oh boy. I constantly run into infinite-loop re-renders, input elements that won't update or randomly lose state, etc. I ask Claude Code to help me fix it, and it ends up doing a bunch of the stuff mentioned in the article: adding useCallback, useMemo, tweaking dependency lists, restructuring things in useEffect, adding state variables, etc.
Fortunately I can read the changes and understand what Claude is doing and why, but all of these things feel like huge holes in the abstraction. They're arcane workarounds for problems that React itself creates. And despite learning via Claude's fixes, I still keep making similar mistakes, a phenomenon I've never encountered with any other framework or library I've ever used before.
Having said that, I'll keep using React: it has a huge community around it, answers to problems aren't hard to find, and Claude Code seems to be good at working with it when I screw up and can't be arsed to poke at it until it works. This unfortunately feels a lot like the old saying, "nobody gets fired for buying IBM", but... it is what it is.