DEV Community

Cover image for From .NET Architect to Frontend Developer — What Surprised Me, What I Miss, and What I Had to…
Digital Craft Workshop
Digital Craft Workshop

Posted on • Originally published at Medium

From .NET Architect to Frontend Developer — What Surprised Me, What I Miss, and What I Had to…

From .NET Architect to Frontend Developer — What Surprised Me, What I Miss, and What I Had to Unlearn

You may remember me from the days when I wrote about CQRS, DDD, and .NET. It’s been three years — I’ve crossed the bridge to the other side.

From .NET Architect to Frontend Developer — What Surprised Me, What I Miss, and What I Had to… cover image

Bridge between backend and frontend (chatGPT generated)

I burned out at my previous job three years ago and started looking for new opportunities. Along with a new company came the chance to fill a missing role on the front-end team. I took the opportunity and gradually transitioned from full-stack to fully front-end focused. And just like that, my entire scope changed.

Why the sudden shift?

I’ve always wanted to work on something more visible. My creativity was getting thirstier by the day, and the backend started to feel dull.

In the backend world, I satisfied my creative itch through architecture — from individual projects and services to entire application structures. Now, I express that creativity through layout design, animation choices, and collaboration with UX designers.

How do I feel about React?

React clicked with me right away. Its component-based structure is exactly my kind of fun. Finding the sweet spot between generic reusability and the Single Responsibility Principle is what drives me most.

What surprised me about front end?

📈 The Progress

Before React, my last encounter with HTML, CSS, and JavaScript (mainly jQuery) was about ten years ago — and mostly just minor tweaks. Today, I work on entire websites and complex features. The front end has come a long way. With React, TypeScript, Node.js, and Styled Components, it feels like an entirely different kind of programming.

🛠 Tooling

I expected chaos but got a surprisingly mature ecosystem. Prettier and ESLint help keep the codebase nice and tidy. Visual Studio Code is a pleasant, lightweight environment, and although Microsoft has made good progress with the performance of Visual Studio, it still feels bulky to me.

📦 Bundle size matters

In the backend, I’d happily install any NuGet package — service size wasn’t usually an issue (unless you were deploying in some expensive cloud). In front end, bundle size affects load speed, so you tend to write utilities yourself rather than pulling in a bloated library just for two functions.

What do I miss from the backend?

❌ Clean compiler errors

Maybe it’s just our internal tooling, but deciphering cryptic error messages and not being able to click straight to the offending file still feels frustrating. Visual Studio spoiled me.

🧪 Unit testing

Side note: if you like reading about the craft of crossing between backend and frontend, I share short, free lessons like that in The Claude Code Memory Starter, a tiny email series you can join in one click.

Sure, there’s Jest, but unit-testing React components doesn’t spark joy for me. It makes sense in design systems and shared libraries. But if you’ve got a QA engineer automating tests via Playwright, I honestly don’t see much benefit. On the backend, I often used TDD. On the front end, I haven’t even thought of it.

📚 Third-party libraries

Every dependency needs to have a healthy community and a small footprint. You can’t just grab the first thing that pops up in a search — you need to do at least some due diligence.

What I Had to Unlearn

🧠 OOP Principles — used rarely

I barely use object-oriented principles these days. Inheritance appears only thanks to TypeScript, mainly for models and component interfaces. Encapsulation? Only when a component is used exclusively in one file.

 And the only kind of polymorphism I can think of is when children are passed into a React component — allowing it to take on different shapes or content.

🧱 Monolithic thinking

I no longer need to think in terms of big code blocks — modules, domains, layers, orchestration.

 Frontend forced me to think in much finer granularity — small components that snap together like Lego bricks.

⚙️ Abstraction

On the backend, I used to spend hours building the perfect abstraction. On the front end, I rarely feel the need — and often don’t even see the room for it.

In closing

I’ve missed writing, and this post is my attempt to start something new.

 I’d love to write blog posts from the perspective of someone standing between the backend and front end worlds — or from a backend developer trying to build good frontend code.

Thanks for reading.

 Have any of you made a similar transition? What surprised you the most?

If this resonated, you might also enjoy The Claude Code Memory Starter — a short free email series, one bite-sized lesson at a time.

 Related Reading

Top comments (0)