DEV Community

Cover image for Frontend, Backend, and the Blurring Line In-Between
ymc9 for ZenStack

Posted on • Updated on • Originally published at betterprogramming.pub

Frontend, Backend, and the Blurring Line In-Between

If you’re close to web development, you must have heard of the distinction between front-end and back-end roles. However, as time passes, the line between them has started to blur, and the divide is closing. This story tells how the separation started and why it’s going away.

The Bronze Age

Before the web was born, programming was just programming. Developers wrote code to render UI on screens, manipulate files on disks, and communicate with other computers on local networks. If they needed to do something new, they’d learn it and do it. There was no distinction of roles, and programmers were generalists.

Even at the time when dynamic websites started to appear, developers used the old “C” language to write server code (called CGI) to spit dynamic HTML content to the web browsers directly:

#include "stdio.h"

int main(void) {
  printf( "Content-Type: text/html\n\n" );
  printf("<h1>Hello world !</h1>\n");
  return 0;
}
Enter fullscreen mode Exit fullscreen mode

Then things started to go wild.

The Iron Age

The boom of the internet caused two unexpected consequences to software developers:

#1 Loss of a definite boundary

Instead of serving a relatively fixed group of users whom you can trust, like traditional enterprise or personal software, a web application is open to the global population. You can’t anticipate how many people will use it, how much data will be stored, and how malicious people in the wild will attack it. As a result, server-side programming has become a lot more complex and stressful than before.

#2 Usability over functionality

Features are the currency for traditional software; however, for web applications, you must compete on usability. What can be done has been done, likely many times. There are more than enough players in every niche, and features offered by different brands are more or less on par. Eventually, those products with clever designs and intuitive user experiences win. UI is no more a shallow layer for exposing product features. It is the product.

These consequences resulted in two centers of mass in web development:

  • A backend (server-side program) that needs to be secure, reliable, scalable, and cost-effective

  • A frontend (browser-side program) that needs to be fast, fluid, and easy to understand

Both are very challenging and require quite a different set of skills. The split of centers of mass finally caused the separation of engineering roles, where front-end developers mostly speak HTML/CSS/Javascript and build fancy UI, and back-end folks use PHP/Java/C#/… to implement server-side business logic.

As with many other cases in human history, specialization increases efficiency, at least to some extent. Each role has less to worry about and can focus on just doing one thing well. But it also brought several apparent drawbacks:

  1. It became more costly to build an online startup. Both front-end and back-end developers are expensive; unfortunately, they’re usually not exchangeable or easily convertible.

  2. It’s hard to get back-end developers to be “customer focusing” because they’re already occupied by worrying about servers instead of payers. It causes cultural problems.

  3. Team boundary creates room for finger-pointing, bringing more cultural problems.

Fortunately, things started to change with the “Javascript Everywhere” movement.

The Modern Age

An important thing happened in 2009: Node.js was announced, and for the first time in history, web developers could write serious back-end code with Javascript, which was previously only used for the front-end. It was a big thing, not only because Node.js is an excellent tool but also because it opened the door for unifying front-end and back-end development, at least at the language level. As a result, it’s much easier (both psychologically and practically) for front-end developers to start messing with back-end code when they don’t need to switch to another language (and corresponding tools).

Many back-end developers (including a younger version of myself) despise Javascript, which is understandable. It takes some courage to trust a language that has some serious inconsistency in design.

[https://devrant.com/rants/1039914/damn-javascript](https://devrant.com/rants/1039914/damn-javascript)

Like it or not, the “Javascript Everywhere” trend is clear, serious, and irreversible. Fast forward from 2009 to today, you can build anything with HTML + CSS + Javascript: website, SaaS, desktop apps, mobile apps, games, VR/AR, blockchain, machine learning systems, cars, robots … you name it.

Any application that can be written in JavaScript, will eventually be written in JavaScript. — Jeff Atwood

The line between the front-end and back-end has started to blur.

The Future Age

Even with Node.js, becoming a generalist (aka, full-stack developer) is still difficult because language is only one of the barriers: database, security, distributed design, big data — each one of these is a deep domain that takes years of experience to perfect.

The good news is innovative people are putting efforts into further fixing the gap:

Front-end frameworks are becoming more backend-ish

Take Next.js, one of the most popular front-end frameworks, as an example: Next.js allows you to create API endpoints for executing code on the server-side. This makes it possible to do backend-ish things — like querying a database or validating users — right within the front-end framework. In some cases, you can now implement a full-fledged application entirely with one framework and one language (if we count HTML/CSS/Javascript as one).

Server-side complexities are being abstracted away

Server-side programming has its own nasty intricacies. Fortunately, new generation startups are building solutions to ease the pain. For instance, user authentication is notoriously hard to implement correctly, and Auth0 is dedicated to hiding the complexity by offering a set of plug-and-play APIs. So instead of thinking of technical details, you can now focus on high-level workflows. There’re more examples of such trends in other domains, like payment systems, CMS, e-commerce, etc.

The two forces are jointly breaking down the wall between the front-end and back-end by pushing front-end developers more towards the other side. In the future, the web development paradigm will be front-end centric: a symphony of APIs under the hood of user experiences.

Front-end pushing its boundary, licensed from shutterstock.com

And you know what? When the boundary of roles is torn down, the cultural problems will disappear.

The future of software development is bright. — Eric Simons, founder of Stackblitz

The future of front-end development is even brighter 🚀.


ZenStack is a schema-first toolkit for building CRUD services in Next.js projects. Our goal is to let you save time writing boilerplate code and focus on building what matters - the user experience.

Find us on GitHub:

ZenStack - Prisma Catalyst For Full-stack Development | ZenStack

A toolkit that supercharges Prisma ORM with a powerful access control layer, unlocking its full potential for web development.

favicon zenstack.dev

Top comments (0)