The blurring lines between front-end and back-end development
Historically, there has been a clear distinction in the perception and responsibilities between Front-end and Back-end development. But as programming evolves, the factors that distinguished the two are blurring together. With JavaScript’s sudden boom, much of the code that would have been written in a different language for the Back-end is now written in JavaScript, making it a Front-end developer’s responsibility. It’s hard to determine where the Front-end ends and the Back-end begins. But what led to this distortion? In this article, I will explore why the gap between the two is narrowing and whether this will lead to confusion or cohesion in the future of web development.
The divide as we know it
Front-end development, also known as ‘client-side programming’, deals with any aspect of development that customers or users can see and interact with.
Back-end, meanwhile, is known as ‘server-side programming’. Back-end developers oversee the functionality of the software product or website and make sure everything works as it should.
A good way to think of the differences between front-end vs back-end is to picture a restaurant. The people ordering food are the product’s user base; the food being served is the product. Front-end is the staff that handles all that happens outside of the kitchen — ordering the food, making sure customers are attended to, making sure the ambience is perfect. And the back-end is all that goes on in the kitchen.
A problem to be solved
Perhaps the biggest reason that explains the shrinking divide is the perception of front-end design as less favorable and easily dismissive. While the front-end places more emphasis on design and user experience, ultimately, businesses are looking to interact with their users, shifting the reins to problem-solving and product development. Front-end was often dismissed as just the role of merely making websites ‘pretty’, especially in the early days of computing when user experience was not an important factor and functionality was key. Now, HTML and CSS are often seen as a burden that developers are looking to replace with just the right tools and frameworks. There are just too many devices and too many browsers to sweat about, and developers would much rather abstract accessibility and web performance with tools and frameworks like Bootstrap. Bootstrap isn’t a skill though, but development in vanilla HTML, CSS and JavaScript are — a skill that developers are looking to transpile by other languages in order to make life easier.
The JavaScript reign
Nowadays, it is impossible to mention Front-end without talking about JavaScript. JavaScript has dominated the front-end arena for the past decade, and statistics show that it will continue to do so. In StackOverflow’s Developer Survey of 2021, it retained its reign in the list of the most used programming languages with 68.62% of survey users picking JavaScript.
There has been a significant shift in the role of a front-end developer, and JavaScript is at the center stage. A job that once required the developer to be responsible mainly for good design and accessibility across devices now has the responsibility of designing component-driven abstractions and fetching data from APIs. It is now not only used to add interaction to a website but to create the website itself. Rarely do developers write raw HTML and CSS anymore. Instead, HTML is generated and CSS is injected in JavaScript with the help of a framework.
Third-party JavaScript powers so many front-end features, from a site’s ad network and analytics to entire features like reviewing, commenting and Node-powered cloud storage and authentication. This has empowered JavaScript development to the extent that front-end developers can ship entire functional products. Some problems that were once exclusively in the back-end domain are now being handled by the front-end, including handling areas of functionality with the inception of component-driven design. With evolving tech requirements, the front-end has evolved in complexity to match the back-end, which has blurred the two together and created a division within the front-end domain.
Front-end’s identity crisis
On one side, there is an army of developers whose responsibilities and skill-sets heavily revolve around JavaScript and the client-side logic of a web app. On the other, an army of developers who can write HTML, CSS, and presentational JavaScript to create and design experiences that look and function beautifully across the web.
In a comment on Robin Rendle’s “Front-end development is not a problem to be solved,” Nils writes:
❝ Earlier, Front-end was mostly HTML, CSS, and some JavaScript. A good front-end developer needed to be able to translate a Photoshop layout to a pixel perfect website. Front end today is much much more. If you want to learn front-end development, people seem to start learning git, npm, angular, react, vue and all of this is called front-end development. ❞
Developers that utilize frameworks like Angular or libraries like React must have a much better understanding of programming concepts that were previously associated largely with the back-end. React server components, for example, a new feature will allow React to offload more work to the server. Currently, the server-side rendering of the library simply renders and provides a set of UI components to the browser. From then on, the application logic is executed in the browser. However, using Server Components, a portion of the logic of a React application will run on the server. With an increase in React’s popularity every year, React.js has surpassed jQuery as the most popular web framework in StackOverflow’s Developer Survey of 2021.
Is JavaScript replaceable?
Despite its widely acknowledged popularity, there could be a possibility to replace JavaScript as Back-end languages and server-side tools start coming to the front-end and make it possible to build Web UIs without JavaScript. One such tool is Phoenix, a framework for the programming language Elixir, and a feature called LiveView. Using this and a tiny sprinkle of JavaScript, developers will be able to create browser-based interfaces for real-time applications like chat rooms where all UI elements are rendered on the server first and then sent to the browser, ready to be displayed. Which raises the question: How blurry does the division between front-end and back-end have to get for it to vanish completely?
A state of equilibrium
Essentially, front-end developed over the years because it became a way for users to interact with the products in real-time in a market that had become way too competitive for grabbing a user’s attention. To achieve this advanced functionality in a manner that is clean, maintainable and standardized is possible only with advanced technologies that speed up the time spent on writing basic HTML and CSS. We are in an ever-changing tech landscape, and the future of front-end development is predicted to take on many new forms that fulfill the software requirements of the evolving tech market.
However, the blurring lines between the two isn’t necessarily a bad thing. When front-end and back-end blur together, it allows improved collaboration that prevents developing software where usability is awkwardly glued on to functionality. Instead, front-end and back-end developers can work together to integrate usability into new features from the start and improve quality and a better user experience for customers.
Despite having blended together somewhere in the middle, the divide between Front-end and Back-end is not disappearing anytime soon. That is because the Front-end frameworks that are designed are done keeping in mind Front-end requirements that will aid the user experience. Fundamentally, both still handle different elements of product development. And perhaps what really matters is not so much where the pendulum swings, but that the two reach a state of equilibrium where Front-end and Back-end both work to serve the same goal: an enhanced user experience.
