DEV Community

Cover image for Web Development Is More Than Frontend and Backend (Here’s What Actually Matters)
Hadil Ben Abdallah
Hadil Ben Abdallah

Posted on

Web Development Is More Than Frontend and Backend (Here’s What Actually Matters)

For a long time, I thought web development was simple.

Frontend.
Backend.
Done.

HTML, CSS, JavaScript on one side.
APIs, databases, Node.js on the other.

If I could move data from the backend to the UI, I thought I was “doing web development.”

So I focused on features.
Routes.
Components.
Endpoints.

And somehow… my projects still felt unfinished.

It took me a while to realize this simple truth:

Web development isn’t just about frontend and backend.
It’s about everything in between.

web development basics, frontend vs backend, full-stack development, programming, software engineering mindset

The Mental Model Most of Us Start With

Early on, we’re taught to divide things cleanly:

  • Frontend → what users see
  • Backend → what servers do

That model helps us start.
But it also quietly limits how we grow.

Because real web apps don’t fail only because of bad code.
They fail because of:

  • Poor UX decisions
  • Unhandled edge cases
  • Performance bottlenecks
  • Accessibility gaps
  • Deployment surprises
  • Communication breakdowns in teams

None of those live only in the frontend or backend.

They live in the system.


When “It Works” Still Isn’t Enough

There was a phase where my apps technically worked.

The buttons clicked.
The API responded.
The data showed up.

But something felt off.

Pages felt slow because I wasn’t optimizing images or caching responses.
Forms felt frustrating because validation only happened after submission.
Errors were technically correct, but unclear to users.

The code wasn’t broken.
The experience was.

That’s when I realized:

Shipping features is only part of the job.
Designing behavior is the other half.


The Invisible Layers of Web Development

Most of what makes a website feel good is invisible.

Things like:

  • Meaningful loading states
  • Error messages that guide instead of blame
  • Keyboard navigation that actually works
  • Proper color contrast
  • Sensible defaults
  • Clean, readable URLs
  • Thoughtful empty states
  • Small performance optimizations (like avoiding unnecessary re-renders or large bundle sizes)

No framework gives you these automatically.

You choose them.

And those choices compound.


Backend Isn’t Just APIs Either

Even on the backend, it’s not just:

“Here’s an endpoint. Done.”

It’s:

  • How errors are handled
  • Whether logs are structured and useful
  • How configs differ across environments
  • How inputs are validated
  • How safe your defaults are

For example, this technically works:

app.get('/users', async (req, res) => {
  const users = await db.getUsers();
  res.json(users);
});
Enter fullscreen mode Exit fullscreen mode

But what happens if the database fails?

A slightly more intentional version:

app.get('/users', async (req, res) => {
  try {
    const users = await db.getUsers();
    res.json(users);
  } catch (err) {
    logger.error(err);
    res.status(500).json({ message: "Something went wrong" });
  }
});
Enter fullscreen mode Exit fullscreen mode

Same feature.
Different level of responsibility.

Node.js makes it easy to spin things up quickly.
But how you structure and protect your application determines whether it scales calmly… or painfully.

Backend is behavior, not just logic.


The Parts Nobody Puts in Tutorials

Most tutorials show the happy path.

They rarely show:

  • What happens when the API fails
  • What users see on slow networks
  • How accessible the UI actually is
  • How readable the code feels six months later
  • How easy it is for someone else to contribute

But those are the parts teams struggle with in real projects.

That’s where web development starts to feel closer to software engineering than just coding.


What “Thinking Like a Web Developer” Really Means

At some point, something shifts.

You stop asking:

“Does this work?”

And start asking:

  • Is this understandable?
  • Is this accessible?
  • Is this maintainable?
  • Is this predictable?
  • Is this kind to users?
  • Is this kind to future me?

That mindset applies everywhere:

Frontend.
Backend.
Node.js services.
Build tools.
Deployment pipelines.

It’s all connected.

That’s what full-stack development really feels like, not just knowing both sides, but thinking in systems.


Progress Happens When You Zoom Out

Ironically, growth accelerates when you stop zooming into tools and start zooming out into systems.

You don’t need to master everything at once.
You just need to notice what you used to ignore.

One small improvement at a time:

  • Clearer UI decisions
  • Safer backend logic
  • Better defaults
  • More empathy for users
  • More empathy for teammates

That’s how projects start to feel complete.


What I No Longer Believe About Web Development

❌ That frontend is “just UI”
❌ That backend is “just logic”
❌ That frameworks are the hard part
❌ That shipping fast is the same as shipping well

Web development isn’t about stacking technologies.

It’s about connecting decisions.


Final Thoughts (From One Web Developer to Another)

If your projects work but don’t feel right, you’re probably not missing skill.

You’re missing perspective.

Web development is more than frontend and backend.
It’s experience, performance, accessibility, reliability, and the quiet details nobody applauds… but everyone feels.

Care a little more than required.
Think one layer deeper than necessary.

That’s where good developers grow into great ones.

Wishing you clarity and confidence in your web development journey, friends. 💙

Top comments (38)

Collapse
 
itsugo profile image
Aryan Choudhary

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.

Collapse
 
hadil profile image
Hadil Ben Abdallah

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.

Collapse
 
alifunk profile image
Ali-Funk

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.

Collapse
 
plc-creates profile image
PLC Creates

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.

Collapse
 
hadil profile image
Hadil Ben Abdallah

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.

Collapse
 
plc-creates profile image
PLC Creates

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.

Collapse
 
aidasaid profile image
Aida Said

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 🔥

Collapse
 
hadil profile image
Hadil Ben Abdallah

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.

Collapse
 
alifunk profile image
Ali-Funk • Edited

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.

Collapse
 
hadil profile image
Hadil Ben Abdallah

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 💙

Collapse
 
alifunk profile image
Ali-Funk

You are welcome !

Collapse
 
hanadi profile image
Ben Abdallah Hanadi

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.

Collapse
 
hadil profile image
Hadil Ben Abdallah

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.

Collapse
 
thedevmonster profile image
Dev Monster

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.

Collapse
 
hadil profile image
Hadil Ben Abdallah

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.

Collapse
 
konark_13 profile image
Konark Sharma

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.

Collapse
 
hadil profile image
Hadil Ben Abdallah

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.

Collapse
 
m_saad_ahmad profile image
M Saad Ahmad

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.

Collapse
 
hadil profile image
Hadil Ben Abdallah

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 💙

Collapse
 
trinhcuong-ast profile image
Kai Alder

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.

Collapse
 
hadil profile image
Hadil Ben Abdallah

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.”

Collapse
 
sebhoek profile image
Seb Hoek

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.

Collapse
 
hadil profile image
Hadil Ben Abdallah

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.

Some comments may only be visible to logged-in visitors. Sign in to view all comments.