For a long time, I thought web development was simple.
Frontend.
Backend.
Done.
HTML, CSS, JavaScript on one side.
APIs, databases, Node.js on th...
For further actions, you may consider blocking this person and/or reporting abuse
I'm loving this shift in perspective Hadil, focusing on the invisible layers of web development really makes you consider the whole user experience, not just individual features. It's like trying to solve a puzzle where you have to look at the entire picture, not just one piece at a time. I've definitely been guilty of getting tunnel vision on a task, but this mindset shift is exactly what I needed to grow as a developer.
It's a thoughtful way to put it; the puzzle analogy is perfect.
I’ve definitely been there too, zoomed in on one piece and feeling productive, while missing how it fits into the bigger picture. That tunnel vision feels efficient… until you step back.
I’m really glad the shift resonated with you. Growth often starts with simply noticing what we used to ignore.
Nice to see that Aryan found this article insightful as well. Makes me happy to see that you take away the message he was trying to get across. Have a good day.
I really like the systems perspective here.
One layer I’ve been thinking about recently is client-side state recovery. As SPAs absorb more business logic, the boundary between frontend and backend becomes less meaningful — but we rarely talk about rollback or deterministic recovery on the client.
We’ve adopted strong reliability discipline for backend data. I’m not sure we’ve done the same for frontend state yet.
Curious how you see that fitting into the “beyond frontend/backend” framing.
You’re right; as more business logic moves into SPAs, the frontend stops being “just presentation” and starts behaving more like a distributed system node. And we rarely treat client state with the same rigor we apply to backend data.
Rollback, deterministic recovery, reconciling after failures… those conversations feel overdue on the client side.
To me, that fits perfectly into the “beyond frontend/backend” idea. It’s less about layers and more about reliability as a system-wide responsibility. The browser is no longer a thin layer; it’s part of the architecture.
I like the “distributed system node” framing.
That’s exactly it: the browser is now part of the reliability boundary.
Feels like we’ve updated the architecture, but not the recovery primitives yet.
This really resonated with me. I love how you highlighted that “it works” isn’t the same as “it feels right.”
The shift from focusing on features to thinking in systems is such a real turning point in a developer’s growth. Especially the part about being kind to future you, that mindset changes everything.
Great perspective 🔥
Thank you so much! 😍
I think that shift sneaks up on you. At first, shipping features feels like progress. Then one day you revisit your own code (or your own UX decisions) and realize you’ve been optimizing for “done,” not for “thoughtful.”
Being kind to future you has become one of my favorite filters. If something makes tomorrow harder, it’s probably not the right choice today.
Really appreciate you taking the time to share this.
Perfect perspective on web development and your words are true. It's all about everything in between the logs, the crashes, deploying to production, handling from 0 to 1000 users.
Thank you so much, Konark! 😍 I really appreciate that.
You’re absolutely right; most of the real learning happens in those in-between moments. The logs, the unexpected crashes, the first production deploy, the jump from 10 users to 1,000… that’s where theory turns into responsibility.
That messy middle is what really shapes you as a developer.
This is a solid reflection. 🔥
I really love how you captured the shift from “it works” to “it feels right.” That’s the moment when someone stops just coding features and starts thinking like a real engineer.
The focus on invisible layers, UX, error handling, accessibility, and performance is so important and often overlooked. This kind of perspective is what separates good projects from great ones.
Beautifully written and genuinely relatable.
This truly means a lot. Thank you so much!
That shift is subtle but powerful. It’s not about writing more code; it’s about thinking more deeply about the impact of what we build. The invisible layers you mentioned are often quiet, but they shape the entire experience.
I’m really glad it felt relatable.
This felt very honest, like reading someone describe a realization I didn’t know how to put into words yet.
I smiled at the “Frontend. Backend. Done.” part because that’s exactly how most of us start. We focus on making things connect, making the API respond, making the button work… and then we wonder why the app still feels a little empty.
This is the kind of reflection more developers need to read.
Thank you so much! 😍
That “little empty” feeling is exactly what I was trying to describe. It’s hard to name at first, because technically everything works… but something deeper is missing.
I’m really glad it put words to something you were already sensing. That’s honestly the best kind of connection an article can create.
The step from 'It works' to 'It is maintainable' is the hardest jump in a career I believe.
Tutorials teach the "Happy Path". You imitate what they do on the screen and it seems so easy. Production teaches the Edge Cases.
You are right: Backend isn't just serving JSON, it's about how the system behaves when the database doesn't answer.
That is the difference between a Coder and an Engineer. Good perspective.
Please keep writing this kind of content is what we need more of @hadil on dev.to
Edit: Wonderful pictures in this article ! Please let me know how you created these wonderful pictures. It reminds me that I wanted to get back into watching more Anime type stuff. Thank you.
Thank you so much! 😍
I completely agree with you. The jump from “it runs” to “it’s maintainable under pressure” is where things get real. Tutorials make confidence look linear. Production humbles you with edge cases you didn’t even know existed.
And I love how you framed it; behavior under failure is what really defines a system.
About the pictures: I’m glad you liked them! I’m actually a big anime fan too 😅 For most of my articles, I search for anime-style images online and then tweak or refine them using Gemini to better match the tone and message of the piece. It’s become a fun, creative ritual before publishing.
Really appreciate the encouragement 💙
You are welcome !
This is a wonderful article @hadil . What you have presented is both accurate and relatable. Development encompasses everything between the frontend and the backend. Frontend and Backend are like vast galaxies, and your role as a developer is to establish a successful connection between the two. This involves caring about routing, ensuring that data from the server is displayed correctly on the frontend, and managing how data is saved in the database — essentially, every aspect of the process.
Thank you so much! 😍 That galaxy analogy is beautiful.
I love how you described it. It really does feel like we’re constantly building bridges between two vast worlds, and every small decision, routing, data flow, and persistence affects how stable that bridge is.
That “in-between” space is where most of the real craftsmanship lives.
I truly appreciate you taking the time to share this 💙
Great reminder, thanks for putting this together.
At first I thought this was going to be an article about software architectures beyond the classic three tier approach.
But then it turned out to be reflection in maintainability, a bit security, accessibility, performance, reliability, testability, and some observability.
All disciplinies which I'd count to software engineering practices and which, in the era of AI-supported coding, are more relevant than ever.
Thank you so much! 😍 I really appreciate this perspective.
I can totally see how the title might suggest a deeper dive into architectural patterns, but I’m glad the reflection on engineering practices still resonated. For me, those qualities, maintainability, reliability, accessibility, and observability, are what quietly define the architecture over time anyway.
And I agree, in the era of AI-assisted coding, knowing how to generate code is becoming easier. Knowing how to evaluate, structure, and sustain it is becoming more important than ever.
The error handling example really nails it. I'd go one step further though - that catch block returning a generic "Something went wrong" is still leaving the user stranded. In a recent project I started returning structured error responses with an error code and a user-friendly message separately from the technical details. Something like
{ code: "DB_TIMEOUT", userMessage: "We're having trouble loading users right now. Try again in a moment.", retryable: true }. The frontend can then decide how to present it - maybe show a retry button, maybe degrade gracefully.The "thoughtful empty states" point doesn't get enough love either. I've seen apps where you sign up, land on the dashboard, and it's just... blank. No guidance, no next steps. That first empty screen is basically your app's first impression and most devs treat it as an afterthought.
This is an expansion on the idea.
You’re absolutely right, a generic “Something went wrong” is better than a crash, but it’s still not helpful. I love the structured error approach you described. Separating technical details from user-facing messaging (and adding things like
retryable) turns error handling into a design decision, not just a safety net. It gives the frontend room to respond intentionally instead of just reacting.And yes to thoughtful empty states. That first blank dashboard moment is such a critical emotional checkpoint. It can either say, “You’re ready to go; here’s how,” or “Good luck figuring this out.”
Greatly said, Hadil! I wish more people realised this part of web development!
Thank you so much! that really means a lot 💙
I think many of us only realize it after building a few projects that “work” but don’t quite feel complete. It’s one of those lessons you grow into over time.
I’m just glad the message resonated; that’s all I hoped for.
It worked well, I must say! Your message is resonating well😊👌
😍😍😍
Great article! Lately I've been thinking about how fast a user can be using my app after he first time sign in. I noticed that there is too much friction before he is actually doing things with my app. I think that the first few clicks matter more than we realize.
Thank you so much! I love that you’re thinking about this.
That “time to first meaningful action” is such an underrated metric. The first few clicks really do set the emotional tone for the whole experience. If there’s too much friction early on, users subconsciously decide the app is heavy or complicated.
The fact that you’re noticing and questioning that already shows you’re thinking beyond features. That’s exactly where great UX starts.
it is front end, backend, infra and business intention
you just bulleted mostly everything that comes under frontend.
I agree with you.
Frontend, backend, infra, and business intent all shape the final outcome. My examples leaned heavily toward what’s often visible in frontend decisions, but the core idea wasn’t to reduce it to one side; it was to highlight that the real work lives in the connections between all those layers.
Business context, infrastructure constraints, product goals… they all influence how we build and why. Appreciate you calling that out.
Love this❤️
This a good reminder that being a great developer isn’t just about coding; it’s about thinking in systems and caring about the experience end-to-end.
Thank you so much! 😍
That’s exactly it. Code is just one part of the responsibility; the real growth happens when we start thinking about the whole experience, from first interaction to long-term maintainability.
I’m really glad that message resonated with you.
Agree Hadil, with every word written and thought. Even though I am not so technical and started not long ago. But somehow intuitively been on a "correct" track from the begining well almost. Took me about 7 months to realise that.
The invisible layers analogy is solid, but here's the gap: none of those "choices" scale without architecture.
Loading states? Empty states? Those ARE design patterns. The real question is: did you architect for them upfront or retrofit them post-launch?
Example: Your Node.js error handler catches DB failures reactively. A robust system isolates that with Circuit Breaker pattern—fails fast, logs structured, returns cached fallback. C#/.NET does this via Polly out-of-box.
The "everything in between" isn't UX polish. It's foundational design decisions disguised as features. You can't bolt reliability onto fragile architecture.
Thanks for this reminding. Experiences like these are very helpful