I write about programming at invasikode.com, and I have been writing code since high school. My day job now is mostly backend and AI plumbing, which is a strange place to arrive at for someone who spent years caring a lot about front end frameworks. This post is about those years.
The first thing I built that strangers actually used was a school election system, written in Pascal with Lazarus because that was the tool I had. It got rewritten more than once over the years, each time in whatever framework I had learned most recently. That habit, learning a tool and then looking for somewhere to put it, started early.
The honest version of the early years: Angular first, because plenty of tutorials covered it and The Net Ninja wrote a good number of them. Then React, still in the class component era. Up to that point every choice made sense, because each one followed the material that existed.
That part is fine. Following what is available is how most of us start, and it is a reasonable way to learn. The part I want to talk about starts one step after that.
The choices that had nothing to do with the work
Moving to Vue was not a technical decision. It was not better for the project I had in front of me. I had no benchmark, no comparison, no criteria list. I picked it because the people around me were on React, and I did not want to be one of them.
The thought in my head was not "this will be faster to build". It was "this will be mine".
Then Nuxt 2, for the same reason in reverse. The people near me used Next, so the choice fell to Nuxt. Again no comparison. Again the deciding factor was who I did not want to look like.
CSS went the same way. I was proud of indented SASS, the syntax with no braces. If you had asked me what it bought me, I would have had nothing to say. It looked sharper in a code block, and that was enough. Plain CSS and SCSS felt boring, even though the browser ends up with the exact same result. 😅
I am describing myself here. If you made a decision like this and it worked out, that is not a contradiction of anything below.
Why it took me years to see it
While you are still learning, you have nothing to point at. No product with real users, no system that has survived a few years of production. That is a normal stage. But it leaves a gap: you want something to show, and a stack is the cheapest thing to show.
Think of a club jacket. You may not be able to ride yet, but the jacket already says you are part of the group that can. A stack does exactly that. Mention a slightly rare tool and people assume you understand more than you said.
The places I was hanging out made this worse. Discord servers, Reddit threads, campus group chats with friends who were also learning. There was a small circle that knew better, and being in it felt good. Every time I said "ah, I don't use that one", something small happened in the conversation, and I got a little hit of being interesting. Pleasant things get repeated.
What the bill looked like
It arrived slowly enough that I did not connect it to the cause.
The first cost was depth. Every switch puts you back at the surface: learn the routing, learn how state is handled, learn the folder conventions, learn the build config that nobody wrote down. I know a little about a lot of tools and I am genuinely good at few of them. Depth comes from staying somewhere long enough to hit the problems that only show up in month eight.
The second cost was other people. If I am the only person on the project who understands the tool, everyone who touches that code pays for my choice. Something that felt like taste from my side looks like a learning tax from theirs.
The third one is the one I still wince at. I became the kind of person who made a small face at other people's choices. "Still using that?" It sounds like a joke. Said often enough, it changes how you look at people, and it makes you worse at listening. Some of the people I said that to had better reasons than mine. I never asked what they were.
What actually survived
After Vue came Svelte, then a migration to Nuxt 3, then a short attempt at TanStack and Astro that ended at the how-to guide, then finally Nuxt 4. What carried across all of that was not API knowledge. I could not write the router setup for half of those from memory today.
What carried across was the thinking. How to break a feature into pieces, where state should actually live, why a page feels slow before anyone opens the profiler.
At my current job the front end is vanilla. No directives, no compiler giving me a hand. That is where the difference becomes obvious: the parts I understand are the parts that survived. Everything else was a name I memorized for six months.
I want to be clear about one thing, because it would be dishonest to leave this post as a warning. I do not regret any of it. Vue and Nuxt are what I reach for by default now, and they earned that over years rather than over one weekend. Go is the language I pick when I want the work to feel comfortable, and Python is where all the AI plumbing lives. That is a pretty ordinary stack. I just arrived at it from an odd direction, and it still landed somewhere good.
CSS finished the same way. Bootstrap, then Tailwind, then PicoCSS out of curiosity, then back to Tailwind, then PostCSS because it was enough, then plain CSS. After going all the way around, the finish line is the thing I called boring in 2019. 🙃
Choosing differently was never the problem
I want to be clear about this part, because I think it is where people usually misread a post like this. Choosing the unusual tool is allowed. Sometimes it is right. If the rare tool is the best fit for your problem, use it. I would rather work with someone who picks the small library for a real reason than someone who picks the popular one out of reflex.
Two conditions, and that is the whole test: a technical reason you can state in one sentence, and a trade-off you can say out loud without getting defensive. "This is faster for our case, the community is smaller, and that is the risk." Say that sentence and nobody argues with your framework choice.
So the mistake was never the framework. At the time, the mistake was the reason. The same tool can be a good decision or a status decision. Only the reason changes.
What I ask myself now
When something new trends, I give it a week instead of an evening. If I still want it after a week, and I can say what it buys me, I try it on a branch. If I cannot say what it buys me, I close the tab and go back to work.
That is the whole rule. It is not strict, and I still break it. Being honest with yourself first is the cheap part. It is the npm install afterwards that gets expensive.
If you are in the middle of the phase I was in, nothing is broken. You will probably enjoy the tool you picked, and you will learn something from it even if the reason was not technical. The only thing I would ask you to keep is the sentence: can I explain why I chose this, out loud, without defending it?
If yes, go. And if the reason turns out to be mostly vanity, that is fine as well. Mine was, for longer than I would like to admit, and I still ended up with a stack I like and a job I can do.
Top comments (1)
Most teams eventually learn that differentiation is rarely in the framework choice. Choosing boring, well-supported tools frees attention for product constraints, operational quality, and user experience—the places where the project can actually become distinct.