Front-end may soon need new sub-disciplines

Backend effort on most projects is declining every day with the help of high abstraction by cloud services. We can already make complete client-side applications with dynamic and collaborated data by just using some public services (like Firebase or CloudKit). We can manage authentication without having any server to maintain. Many authentication providers and even some authentication services allow us to do that.

And obviously, things will not stop here. It’s not hard to imagine that we’ll have more database services where we can directly write/read data from our front-ends securely and efficiently. The backend work of most of the projects will be just connecting and configuring multiple cloud services to each other.

So, will every web developer be a “front-end developer”? Of course, there will always be a need for more low-level server-side specialists, at least for creating those cloud services. But maybe 90% of the coding effort for web projects will be done on the client side. And this will mean the “front-end” will have more and more new responsibilities and challenges.

We can already see those with the new web APIs every day we start to hear, like Web Assembly, Web Worker, Web GPU, etc. The work we’ll begin to handle those new layers will be not just “basic UI” things. Instead, we’ll move some new stuff to the “front-end” that we previously handled on our backends with the help of the new power we’ll have in browsers.

Take Web Assembly, for example. Web Assembly allows us to run some libraries in the browser with native performance. You cannot (and intend to) do DOM manipulations inside the Web Assembly layer. Still, you can make very CPU-intensive things like image processing, data cryptography, or even maybe Machine Learning.

Web Workers gives us to run some other JavaScript routines outside of our render cycles without blocking UI. WebGPU will give us the full power of GPU to make even more efficient graph calculations, crypto calculations, or 3D renderings. WebRTC allows it to create a peer-to-peer connection with another user of our client app and send/receive any data, including streaming video or audio. File System Access API gives full access to the local file system of the user to read/write files and directories.

These are not very familiar things that we do daily as front-end developers. In the meantime, real UI work effort is not getting less. Creating durable, reusable, flexible, easy-to-use, and accessible components is still a big challenge. Providing the best UI with the best UX needs neat work with designers and product owners.

As a result, I expect we’ll need to consider splitting those new responsibilities inside web client-side development. Let me name them “Web UI” and “Web Core.”

Web UI Developers

Maybe we can roughly list the responsibilities of Web UI developers as follows:

• Web Components
• CSS
• Routing
• Forms
• Animations
• Accessibility
• Web Fonts
• Canvas
• SVG, SVG filters

These are the items that we are very familiar with as front-end developers. They all are directly related to UI and user interaction. And we all know that if you consider being a specialist in all of those areas and being able to create a very well-implemented web application, there will be many challenges waiting for us.

This area is also where our popular web frameworks are responsible. We make components with Lit, manage complex forms with Angular, or create responsive grids with Tailwind. (The last one was a joke)

Web Core Developers

Web Core developers may be mainly responsible for the business logic and service-like backend part of the client app. These things will not directly change UI but primarily data management, business logic, and scalability (very familiar things for current backend developers, right?). If we want to list some technology names for Web Core developers, we may record:

• WebGL - WebGPU
• Worker
• Web Assembly
• Web Crypto
• IndexedDB
• File System Access API
• WebRTC

There is no React or Angular here. Nothing here for them. But for complex web applications, those APIs are like treasures. Also, asking WebGPU or WebAssembly expertise from a senior React developer will not be fair.

Example project team structure

Let’s consider a project as a photo/video management web app. We’ll make a web application to add our photos and videos to a library, and edit, categorize or share them.

We’ll not have a backend code for this. We’ll use a database and a file storage service, which can work with an authentication service. Those services will be fully-managed, external services. We’ll handle image/video editing entirely on the client site. And we’ll store all data on our storage services in an e2e encrypted way.

As you can see, there are pretty many things to do for both UI and “Core” sides in this project. For UI:

• A fancy UI to list, search and add many photos and videos to the library.
• A fully-featured and easy-to-use UI for editing images and videos
• Share albums with others, comment on photos
• Making this app “accessible” as much as possible

On the other side, there are also huge challenges on the core side:

• Writing some “Web Workers” to communicate with our cloud services in a non-blocking manner
• Writing a very efficient image manipulation library
• Writing a very efficient video editing library
• An API to crypt/decrypt images and videos before sending them to our storage service and after fetching them
• Storing some part of the data locally to make our app run offline and sync with services later

When we list our tasks like this, I think separating the types of tasks becomes very clear. “Web Core” tasks are pure IO challenges that never touch DOM or CSS. On the other hand, the APIs that the “Web Core” team will provide to the “Web UI” team will be very similar to what we currently have with the “Frontend - Backend” world. JS interfaces replace REST or GraphQL APIs.

Wrapping up

Titles and disciplines are not big walls to keep developers in their responsibilities forever. Instead, they are helpers focusing on one thing at a time. Distraction is one of the biggest diseases of our time. And I think it’s very valuable for every IT professional to focus on quality, not quantity.