For the last few years, Vue has been my default, alongside HTML, CSS, and whatever else was required for the specific project. I know it well, and I like it. So why am I leaving my comfort zone, spending my evenings on React tutorials and even rebuilding my own portfolio with it?
The honest answer: the job market asked me to
I'd love to say this was purely intellectual curiosity, and it partly is, but React would not have been my first choice (Svelte would). But, let's be honest... React shows up in a majority of frontend job listings right now, and by learning it, I am increasing my chances of a better future and a more enjoyable role for myself. So I decided I'd rather learn it on my own terms — with time to actually understand it — than scramble to fake familiarity in an interview. If I'm going to compete for roles that list React as a requirement, I want to actually be good at it, not just good at conversation.
Component thinking isn't new to me, the tooling is
Component thinking isn't new to me, the tooling is. Years of working across component-based systems — Vue components, T4 CMS modules, reusable Figma components — means the mental model of "break the UI into small, composable, reusable pieces" isn't new, it's actually really easy. What's new is React's specific flavor of it: JSX instead of Vue's neatly organized templates, hooks instead of Vue's Options/Composition API, and a much bigger ecosystem to get oriented in.
So, sure, I didn't have to learn "how to think in components" from scratch, but I still had to translate a way of thinking I was comfortable with into new syntax. Syntax I didn't always agree with, if I'm honest. The main needed adjustment was reactivity: Vue tracks what changed for me; React expects me to manage that myself with dependency arrays and memo calls.
The good and the bad
React and I didn't get along very well, even before I accepted I should learn it.
The syntax differences were the first friction point. Vue's v-if/v-else reads as a real conditional; in JSX it's a ternary or an && threaded through the markup, and I had to get used to a falsy 0 rendering literally as the text "0" instead of nothing at all. v-for is a directive sitting right on the element; in JSX it's just .map(), which is fine once you remember key every time — but Vue never made me think about it in the first place. And v-model — one attribute, two-way binding, done — became a value prop and an onChange handler I had to wire up by hand, on every field, every time. None of it is hard. It's just more typing to arrive at the same result, and it never stopped feeling like a step backward in that specific way.
useEffect is another big one, and now that I understand it, I can compare it fairly instead of just complaining about it. Vue's watch and computed track their own dependencies automatically — you never declare what a computed value depends on, Vue just knows, because it watched what you accessed. That's less for me to get wrong, but it's also implicit: when a watcher fires when I didn't expect it, or doesn't fire when I did, the "why" is buried in Vue's proxy tracking rather than visible in my code. React's dependency array is the opposite tradeoff — nothing is inferred, so nothing is hidden. I can read a component and know exactly what triggers a given effect, no runtime magic required. The cost is that I'm now responsible for keeping that array honest by hand, and getting it wrong doesn't throw an error — it just quietly reruns too often, too rarely, or with a stale value trapped in a closure. Vue trades explicitness for convenience; React trades convenience for explicitness. I don't think one is objectively right, but I'll admit Vue's version asks less of me on a regular Tuesday.
That said, two things earned some credit for me.
Custom hooks are one — being able to pull a chunk of stateful logic into its own useSomething function and drop it anywhere, no special file structure or plugin system, is a genuinely nice pattern once it clicks. I have to be fair here, though: Vue's Composition API has composables that do essentially the same job, so this isn't a clean React-only win. What I'll say instead is that hooks clicked well for me — regardless of which framework's version of it you're using.
The other is React's explicitness about state changes — every update traces back to an actual setX call sitting right there in the code. Vue 3 also ships onRenderTracked/onRenderTriggered specifically to trace which reactive access caused a re-render, and Vue Devtools can surface that just as well, often more precisely than React's profiler does. The real difference is smaller than "React is easier to debug" — it's that React's version doesn't need tooling to be traceable, because reading the component is enough. Vue's version is just as traceable, but you're more likely to need devtools open to get there.
What I'm building with it
Tutorials only get you so far. I learn best by building something without a step by step guide, so I've got two projects going:
- Hiyori: A language-learning app, motivated by my own studying for the JLPT (Japanese proficiency test). Flashcards with spaced repetition, progress tracking, a UI I actually want to use daily — it forces me to make state-management and component-architecture decisions instead of following a tutorial's super generic structure. Read more about that in the Hiyori project breakdown.
- After building the initial prototype for Hiyori, I started building this new portfolio in React + Next + TypeScript, using Framer Motion for the interactions. I had used React Router for other learning projects, so now I wanted to learn Next.
Where this leaves me
I don't think switching frameworks makes anyone a better engineer by itself. What I do think matters is staying capable of picking up new tools without losing the judgment that took years to build — knowing when a component should be split up, when a design decision will cause accessibility problems down the line, when a client's request needs a clarifying question before it needs code. However, I do know the current state of the job market, and I am aware that being updated with the most popular tools will increase the chances of a better position. I still prefer Vue's ergonomics, and I don't think that's wrong of me, but I am proud that I was able to overcome my initial hurdles, I have accepted the reasons why the industry moved where it moved (and why it's hard to switch), and I think it's valuable to have actually learned this rather than faked it on my CV. I am still curious about React Native and how easy or hard it will be to make the switch, so that may be one of my next challenges when there's time.