The Front-End Development we’re used to is dying

Why I think we’ll soon be back to where we started.

Introduction

Before the advent of SPA, web applications were typically multi-page. This meant that every time a user interacted with the application, the server sent a new page in its entirety and a browser loaded it again. Each time the user navigated between pages, a complete page reload occurred, and it could slow things down and create a less-than-smooth user experience. Similar applications were often built using server-side technologies such as PHP, Ruby on Rails, ASP.NET, etc., which generated HTML code on the server side and sent it to the browser.

how a PHP web application works

Web developers were universal specialists, they were responsible for front-end and back-end parts at the same time. After the development of web technology and the demand of users, new solutions, which would allow them to work with an interactive interface without any problems or waiting were required.

This is how the first solutions for SPA using BackboneJs or AngularJs appeared. They allowed us to reduce the load on the server, whose resources were limited at that time, and to provide interactivity when working with a web page via JS because there was no need to wait for a new page with updates from the server.

That’s how the division into front-end and back-end parts appeared. The role of purely front-end developers has become more demanded and diverse. They began to specialize in creating user interfaces, working with HTML, CSS and JavaScript, as well as interacting with APIs and the server. On the other hand, back-end developers became more focused on data processing, application business logic, working with databases, and creating server APIs.

And that’s how we entered the era of React, Angular2, Vue and other web application development tools. Instead of creating simple forms and lists, now we have js-routing, state management, browser API, binding authorization tokens to requests, data mappings, etc.

We started to complicate things which were simple.

As a result of this approach, the problems were obtained:

• Difficulties in communication and coordination. Api Contracts and communication method — HTTP 1.1, Websocket, GraphQL. JSON parsing and validation.
• Divergence in understanding and knowledge. For example, you could develop a front-end application that creates many queries and consider it a normal and optimized SPA. But for the back-end, this is a very dangerous situation, because it now needs a lot of database accesses and proper aggregation of this data, which will affect its performance and maintenance.
• Duplication of work. Most CRUD operations on the back-end had similar behaviour on the front-end. We didn’t just get the list from the server, now we put it in the store(), each user action is processed via dispatch() and waits for the request to be executed, after that we update the store via reducer() depending on the result — everything the back-end does to the database, we repeat on the front-end. (page reloading and restoring SPA to the current state from the server are also worth mentioning — a separate pain for the moment)
• Difficulties in debugging and testing. You now need to consider possible integration issues and test them in the context of both sides of the application. Yes, you can create isolated e2e-tests for the front-end application, but they cannot guarantee reliability in Production. Yes, there is ZoD for validating server responses, but what percentage of its usage?
• Increased development time and cost. Any change to an API contract requires two people at the same time. You can’t directly change a template to a server like you used to. You need rallies, split into separate tasks, business-analytic specialists and so on to make the change smoothly.
• SEO. Since our app is entirely formed through JS, search engines could not get the app content and its navigation to index it properly, thus SSR and SSG solutions were required.
• Security. Any critical data entered on the page needs to be hidden before being passed to the server. Also, a lot of personal information needs to be requested from the server for the application, revealing access tokens.

So, why is the usual front-end dying?

Just go to any resource and you’ll see how many job vacancies are open:

• Python + Django
• PHP + Laravel
• NextJs + React
• Nuxt + Vue

These are all bundles for server-based web application development. Thanks to the Hydration and Resumability approaches, the server can only render the modified part of the interface, without reloading the page.

What they provide:

• The server application now does not need complex HTTP or WS contracts and support them on both sides, it can use better methods to exchange information with other services like gRPC.
• The process of making changes is faster due to the lack of intermediate approvals, for 1 person the result the user sees immediately changes.
• Tests can check the application holistically, eliminating integration tests and reducing errors.
• You exchange only HTML markup, all “request-response” logic is hidden for a user
• Why pass a lot of data in JSON to restore SPA to the right state when you can pass a ready template?
• You don’t need to worry about browser compatibility and use babel and other tools, because JS code on the page is minimal.

With the advent of No-Code solutions, template generation via AI, huge server resources, and SEO requirements — the current number of front-end developers as well as tools are not needed to develop only the front-end part.

Business owners have a valid question — “Why do I need to hire a pure front-end developer and a pure back-end developer to do a simple application?”

Full-stack developer is not a management fad, in terms of saving on staffing, now it’s a mainstay. You don’t need a pure front-end developer, you need a developer who can make a whole application, performing simple operations with the database directly or other services and displaying the result.

Yes, there will undoubtedly remain a complex or headless applications that require front-end and back-end separation but most of the applications will move away from SPA and go down the way that was already there, but now we have a solution to those problems. With the advent of HTMX, any back-end developer with basic knowledge can create a web application. You don’t even need to know JS to create a single-page app with little logic now.

You may ask, “The front-end developer was responsible, not only for JS logic but for CSS and proper selectors, HTML and its semantics, does the backend developer have to know that now ?” — No, now an AI or “HTML layout designer” can do template generation based on layouts from Figma. The logic and interactivity of the HTML-template are now defined on the server.

Conclusion

Now is a good time to think whether you really need all these sophisticated front-end development tools and whether you should remain a pure front-end developer.

I expect current front-end developers to move to Fullstack qualification with a 60%-front-end, and 40%-back-end split to stay relevant specialists. HTMX is just the beginning, the vector towards NextJs or Nuxt tools will grow, and Angular-type frameworks will die if they can’t adapt to new implementations, although the Angular ecosystem already has prototypes on AnalogJs as well

Resources

htmx - high power tools for html

Analog | Analog

Search jobs by “Front End developer” role

Search jobs by “Full stack developer” role

Next.js by Vercel - The React Framework

Nuxt: The Intuitive Vue Framework