I set out to figure out the answer to this question by writing about it and comparing various performance issues, ease of composition of components, debugging, etc.
I didn’t find any particularly interesting or meaningful differences.
At the template level, JSX exposes more plain old JavaScript than Vue’s templates do. I find defining and using types in JSX land more intuitive. Otherwise they’re fundamentally both excellent and very capable and neither is doing any one thing glaringly wrong.
I ended up scrapping it because the deeper I went, the less interesting it got. I think it really does come down to ergonomics and preferences
Even boring as it may sound, definitely something I would read, since I known React well but don’t feel like bothering to much with vue atm, but would like to understand the difference / nuances.
A few differences between React and Vue, purely off the top of my head. (Caveats: I am deeply involved in the React ecosystem and have never personally _used_ Vue myself, but am generally familiar with it overall.)
Vue: rendering output defined primarily with templates and attributes like `v-for`; Single-File Components structure, lets you define styles as CSS and I _think_ they get scoped automatically; all major libs for routing, state management, etc, are considered "official" Vue packages and have at least some intentional coordination; probably less ecosystem churn overall due to those "official" packages; possibly easier to get started with, since it's easier to drop in one script tag and use it as a small enhancement to an existing page; reactive data UI for updating state (`state.value = 123` auto-triggers UI updates of components that rely on that data).
React: JSX syntax for rendering logic ("It's just JS!"); no official structure for defining component files/folders/logic; React is still "just a rendering lib/framework", so all other capabilities (routing/state management) are filled in with community maintained packages (React Router, Redux, etc); _dozens_ of community packages for any conceivable use case, but plenty of churn as a result; _can_ be used with just a couple script tags, but in practice normally used with a full JS build toolchain; explicit `setState(newValue)` API for triggering re-renders, and renders many components by default - have to intentionally optimize components to avoid unnecessary re-renders.
I might actually revisit it – maybe going a little deeper will eventually point to something interesting. Thanks for the nudge, I’m never sure who will be interested in things and why.
Good point, I didn’t bother taking this route but now that I’m thinking about it, maybe it would have been useful to illustrate differences between features state management.
