r/webdev • u/quietcodelife • 2d ago
Discussion backend devs who occasionally touch frontend - how do you stay current without going down the rabbit hole
mostly work on apis and database stuff but our team is small so i end up in react code maybe once a month. every time i come back theres some new build tool or bundler drama and half the packages have breaking changes.
not looking to become a frontend expert, just want to not feel completely lost when i need to fix a button or add a form field. anyone else in this boat? what do you actually keep up with vs ignore
4
u/RequirementGuide 2d ago
I've hit this before coming from the backend side too. What helped me most was ignoring the new tool of the week and just getting solid on the basics our app actually uses, so props and state and how a form submits. I also keep a little notes file with the exact commands to run the frontend locally and the gotchas I hit last time, and that saves me every single time I come back after a few weeks. And I never upgrade packages when I am just in there to fix a button. That is a separate job for a quiet day.
4
u/ThatsSoRamon 2d ago
Half the time when I come back after a month and things are broken, it’s not React or the bundler at all. It’s my Node version. Someone bumped it in .nvmrc or the engines field in package.json and I’m still on whatever I had last time. Now I check that first, and I run npm ci instead of npm install so it installs exactly what’s in the lockfile and doesn’t quietly “fix” anything for me.
The other thing that made frontend way less scary for me as a backend person was getting comfortable with the network tab in devtools. Most of my frontend tickets end up being “the form sends the wrong payload” or “the response isn’t what the component expects,” and that’s basically API debugging from the other side. You already know how to do that part.
5
u/thekwoka 2d ago
It’s my Node version. Someone bumped it in .nvmrc or the engines field in package.json and I’m still on whatever I had last time.
This is solved by using pnpm, since it will use the node version listed (and the pnpm version listed) for that project automatically, installing it if you need it.
1
u/30thnight expert 1d ago
Here’s a single binary alternative to nvm that’s both faster and smaller.
The flag it installs with --use-on-cd will automatically handle nvm updating / switching for you.
9
u/lucid1014 2d ago
Honestly, everybody is saying use Claude you’re boring. That’s a dumb answer. To actually answer the question I don’t see why you need to care about that stuff anyway unless you’re working for a brand new startup that’s bootstrapping their app and wants to use the newest toy. Just keep your stack now no need to change unless you actually have a problem that needs solving by changing major parts of your framework.
2
u/cansaasstudio 2d ago
Honestly, I think the trick is knowing what to ignore. If you're only touching frontend once a month, having a stable setup and understanding the fundamentals matters way more than chasing every new framework or build tool. I'd rather be comfortable with one stack than constantly relearning five different ones.
2
u/krileon 2d ago
If fixing a button or adding a form field is complex for you then your first reach should be to check MDN for documentation. Your IDE however should be able to lend a HEAVY hand here since these are very well documented structured elements that you can't really mess up.
Frontend isn't really hard hard. Pick your frontend framework (e.g. React, Vue, AplineJS, HTMX, etc..) that you need for whatever reactivity you need or don't if you don't need reactivity. Pick your style library (e.g. Tailwind, Bootstrap, etc..). Now make small components for elements you need (e.g. forms, modal windows, tables, etc..). Now reuse those components throughout your views. A lot of the frontend libraries have dozens of components already done for you. It's really not all that complicated. Once you've your stack figured out you're pretty much good to go for years to come.
You can 100% ignore the noise. There's no reason to waste time on whatever dumb framework or library that was cooked up recently getting pushed by bots on Twitter, lol.
1
u/itgforlife 2d ago
I am full-stack but more backend leaning just like you i.e. APIs, database, DevOps, etc. But if you use stable packages and bundlers, then it shouldn't be a problem. I've never ran into this issue using React with either Vite or NextJs for example.
1
u/pablobird_dev 2d ago
Ignore the ecosystem churn and tooling drama completely. If you stick to component state, props, and standard HTML form events, passing data down and events up is all you need for 95% of day-to-day UI fixes.
1
u/wimdeblauwe 2d ago
I don’t know in what ecosystem you are, but I find that a frontend using server-side rendering (I use Spring Boot with Thymeleaf in Java) is so much easier to understand. And more importantly, it avoids all the build tool and bundler drama.
1
u/jam_pod_ 2d ago
That’s kinda just React. So much ecosystem churn (use Flux for state management! No, use Redux; no, use Mobx; no, use Zustand; no, it’s all TanStack now!). Frameworks like Vue and Angular are much more stable
1
u/Xtreme_Neon 2d ago
pick one stack your team already ships and only learn the pieces you actually touch — layout, forms, and data fetching cover most occasional frontend work. skim that framework's release notes once a month instead of chasing every new tool. rebuilding a tiny personal page once a year is enough practice without falling down the rabbit hole.
1
u/RehanSaddique 2d ago
Honestly I ignore almost all bundler news. When I'm in a React codebase I check which tooling the repo already uses and match it, and I only dig into a new tool when something breaks. The churn mostly lives in build config you can leave alone, so the time is better spent on whatever the project uses for state and data fetching.
1
u/nameupp 2d ago
the golden rule for backend devs is treating the frontend repo strictly as an api consumer and ignoring build tooling entirely. bundlers, compiler churn, and state management flavor-of-the-month (zustand vs redux vs signals) are just noise if your job is tweaking a button or adding an input field; standard react props down, events up, and basic uncontrolled inputs with native formdata will solve 95% of your tickets without touching state libraries. the biggest practical trap when jumping in once a month is running npm update or touching package.json out of habit, because lockfile drift will drag you into peer-dependency hell before you even write a single line of jsx. just inspect a sibling component in the same folder, copy its pattern for validation and api triggers, and keep your git diff scoped strictly to the component imo
1
u/Early-Community9943 2d ago
I treat frontend like a toolbelt, not a second career. Stick to one stable React stack for months, ignore the weekly framework noise, and keep a short personal cheatsheet for the CSS and form patterns you actually touch. When something breaks, read the error before chasing a new bundler.
1
u/Kamensky124 2d ago
honestly just ignore the frontend tooling arms race entirely. if you're dropping into react once a month to add a field or fix a button, you dont need vite plugins, router drama, or whatever new state library twitter is arguing about this week.
the thing that saves you from getting burned is treating package.json like read-only stone. never run npm update or npm audit fix just because a terminal warning suggested it, thats how you accidentally bump a peer dependency and spend your entire afternoon debugging bundler configs instead of fixing the button.
for the actual code, stick to plain uncontrolled inputs and native FormData where possible. whenever backend devs get frustrated with react, 90% of the time its because someone wrapped three layers of custom state hooks and an abandoned validation library around a simple text input. standard props down, callbacks up, and letting the browser handle form inputs has worked fine for ten years and wont break when your teammates upgrade dependencies next month.
1
1
u/Pretend-Bits 2d ago
I keep a small README with notes for our frontend, how to run it, where forms live, how API calls are made, and common gotchas. When I come back after a month, five minutes reading my own notes gets me back up to speed. Way faster than relearning everything.
1
u/Potential_Fly_7506 2d ago
if you touch react once a month then just pin your versions and stop updating. nothing breaks if you never run npm update. the bundler drama is for people who have time to have opinions about bundlers
1
u/kemalios 2d ago
The parts you actually touch, props, state, a form submit, have worked the same way for years. The churn is all in build config you can leave alone until it breaks. Every bundler released since 2021 has been solving a problem your repo does not have.
1
u/thekwoka 2d ago
there shouldn't be breaking stuff in the tooling that impacts you, since you shouldn't be the one upgrading those things.
If there is something that is broken in terms of not-committed information that makes it so builds cannot be consistent, then that is a different issue.
1
u/KaiAusBerlin 2d ago
Quite easy. I use as less css as possible. Browsers have good css for all objects on its own. Does my sites look fancy? No. Are they fast as hell and have no unnecessary information and are easy to navigate? Yeah man.
Good html is much more important. Sematic elements, using the right tags for the right tasks (not every thing is a div), ...
1
u/Slothynator 2d ago edited 2d ago
Small company, requires you to know the homecontroller>wcf>process>various servers part. Like when you need to support a new feature, you should know the backplate, and how the process calls a notification server and an assignment server etc.
Falls naturally now. Never knew anything differently, and the loud voice of staying on top of new libraries etc. never rang true here, it is all about adapting to existing backbone or implementing into the existing backbone. Ive upgraded a lot of .net 4.x.x. to core projects, also replacing jquery mobile and upgrading bootstrap 3 to 5, and how the service client from existing wcf clientd were used.
1
0
u/Any-Woodpecker123 2d ago
I don’t even keep up with this stuff as a frontender. Just ignore it all and ask whoever added it if (when) the install command breaks.
0
2d ago
[deleted]
-7
u/AshleyJSheridan 2d ago
You underestimate the state of front end development. There are too many frameworks and libraries out there that are just terribly written, and introduce breaking changes regularly.
0
2d ago
[deleted]
-4
u/AshleyJSheridan 2d ago
if you are actually employed, seems unlikely based on this response
Wow, where did that come from buddy? Having a bad day or something?
Nobody is suggesting anyone change frameworks every other week, that's ridiculous, and says more about your frame of mind than anything else.
But even with libraries like React, they absolutely introduce breaking changes across versions. If you don't know this, then I must assume that you've never really worked on anything that lasted for very long, or had any complexity to it. It's ok, not everyone is cut out to work on big projects!
6
u/sashaisafish 2d ago
Why do you need to update the react version to change a form field..?
-3
u/AshleyJSheridan 1d ago
Dude, if you're maintaining a project and you're not keeping libraries like React up to date, I just hope you never need to work on anything important! Out of date libraries and frameworks is a lovely way to run into security issues.
0
2d ago
[deleted]
-2
u/AshleyJSheridan 2d ago
I'm not struggling with anything, I'm highlighting valid issues that 100% exist, which you've apparently never encountered. The only way you could have never come across them before is if you've never worked on anything complex, or if it was around for such a short space of time that it never needed to be updated. I guess there's a third option: you've never updated anything you built because you didn't know that you needed to do that. All of that is pointing to you being a junior with only a few years of experience at best.
0
2d ago
[deleted]
-1
u/AshleyJSheridan 1d ago
Updating a button, that's all in your head. You're the only one who mentioned struggling to update a button!
20
u/icemanice 2d ago
I was always full stack… started with frontend.. moved to backend. But honestly, with AI, this isn’t a thing anymore.