In this blog, I would like to share my opinion on how we, as front-end developers, often make projects unnecessarily complex. We often think we’re doing the right thing, but are we? Where we used to say we could build a website in just a few days, now we provide timelines at the infamous Scrum meetings that stretch from months to even a year. Where has all that time gone? I will describe a few pain points I’ve encountered as front-end developer at the companies I’ve worked with over the last 15 years
This article is the first in a series where I’ll talk about the challenges and frustrations I’ve experienced in my career.
Maybe you were there, or maybe you came into the field later. Back in the day, websites were built with simple CSS and HTML, and occasionally, JavaScript was used when absolutely necessary. The job of a frontend developer was to make the designs functional across all browsers. These browsers were nowhere near as good as the ones we use today. Remember the days of Internet Explorer? Google Chrome didn’t even exist yet.
JavaScript was used minimally, mainly for adding simple dynamic features like hover animations or alerts. We avoided it as much as possible because writing good JavaScript code was difficult. Each browser reacted differently, there were no tools like console.log or developer tools, so if your JavaScript didn’t work, you had no idea why. Then jQuery arrived. We all know jQuery—it solved a huge problem by allowing us to write JavaScript that worked across all browsers. We quickly embraced it, creating cool scripts and plugins. In addition to DOM manipulation, easy to use XHR tools were introduced, enabling dynamic web pages to become highly popular.
Thanks to jQuery's simple API, websites quickly gained parallax scrolling, elegant tooltips, and stylish modals. As webmasters, we became programmers because there was now so much to program. While this was the most exciting time in my career, it’s also when I believe everything started going wrong. This was the dawn of the “frontend developer” role, which was cool at the time, but it also led to websites becoming unnecessarily complex. After all, we always had to keep ourselves busy as frontend developers, right?
The arrival of jQuery coincided with the creation of our jobs. We had tons to do and wrote countless plugins and extensions. We shared these freely, and every JavaScript problem on Stack Overflow had a jQuery solution with hundreds of upvotes. Everyone spoke the language of jQuery—great times!
However, we all had different ways of writing jQuery plugins, which created a need for structure. jQuery was only for DOM manipulation and cross-browser support, but it didn’t offer structure. Enter frameworks. I think we all know how that story went. From Backbone to AngularJS, and now we have a plethora of frameworks. Each with the same goal, but all slightly different. Some offer a lot of structure (like Angular), while others leave you completely free (like Vue). Every framework has its own vision and a community of developers who passionately believe their framework is the best.
The world of frontend development has changed once again. We no longer look for webmasters or CSS/HTML experts; we now look for “Angular developers,” “React developers,” or “Vue developers.” It no longer matters if you can read and write CSS, HTML, and JavaScript; what matters is mastering a specific framework.
If you look at job postings today, it seems like knowing a framework is more important than your technical skills or understanding the fundamentals of frontend development. Companies work with Angular, React, or Vue, so every project is written in one of those frameworks, without much critical thought about whether it’s actually necessary.
Want to display a checkbox on a website? Write a component in one of the popular frameworks—it’ll take you about two days and 100 lines of code. Why use standard HTML when you can reinvent the wheel, right? Want to show a modal when a user clicks a button? Introduce shared state and write a state management tool! This all sounds overcomplicated when I write it out like this, but that’s just how we operate nowadays.
As a freelance frontend professional, I've had the opportunity to work with many companies on building design systems, performing migrations, and handling other tasks. What I’ve noticed across the board, regardless of company size, is that everyone does the same thing. I’ve worked with all the major frameworks in various large corporations, and every one of them had its own implementation of a checkbox component, an input field component, modals, buttons, etc. What do these components actually do? Not much. They trigger some events on interaction and include a bit of styling.
Each of these components was built by one or more developers who spent countless hours creating something that could have been done with standard HTML. But let’s be honest, simply styling a checkbox isn’t much fun, right? Building a custom component that introduces an abstraction layer around a checkbox and is tailor-made for your specific use case is way more interesting! Yet another sprint filled with work: discussing with fellow developers what to call the component, deciding which repository to put it in, figuring out the properties and events needed, and, of course, writing unit tests. Because surely, we need to test whether a checkbox can be checked, right?
If we wanted to make real progress and truly help the visitors of our websites or web applications, we would look at libraries like Material Design, Bootstrap, or Vuetify for the components we need, tweak the design a bit, and move on to the tasks that actually make an impact.
By turning everything into a component, we often add even more complexity. For example, how should form elements communicate with each other on a webpage? Ask this question in a room full of developers, and the typical response will be that you need state management. State management is complicated, as it creates a contract between components where all can read and write data. Everything responds to everything else, yet the components remain loosely coupled, adding even more layers of abstraction.
Before you know it, you're deep into an ecosystem, writing code dictated by the framework rather than solving real problems. This is why frameworks have become a goal in themselves, not a solution.
Yes TypeScript needs its own section in this article. This may sound strange, but does TypeScript really lead to fewer bugs when building a website? From my experience with various development teams, I've observed that TypeScript often adds unnecessary complexity to a codebase. As I've mentioned before, most frontend professionals are more like scripters than engineers. Learning TypeScript can be challenging, especially without a solid foundation in programming. And by a solid foundation, I don’t just mean being able to create a “Hello World” application; I’m referring to having a comprehensive understanding (often from formal education) of design patterns, abstractions, databases, data structures, and algorithms.
While TypeScript offers many advantages, it can be unnecessary and overly complex for most websites (I'm not talking about frontend applications as Typescript and thus engineers are needed for such projects). Why invest so much time and effort into adding yet another layer of complexity? We already have plenty of layers due to frameworks, the associated workflows, and the mindset of working with components. When creating an interface, do we really need to add another layer of complexity? In everything we do, we must be aware that technology is not the goal. The goal is to build a beautiful solution, and if technology can assist in that, then we should utilise it.
With the rise of frameworks, we now work in a particular way. We create components, break reusable code into separate pieces like composables, utilities, or whatever the framework calls them. This code is then published via a pipeline to the appropriate environments where it is deployed. All these components are bundled into one or more .js files, while styling is extracted and placed into separate .css files by various tools (and yes, our code is made old-school when served in the browser). Our webpage code is made up of HTML elements, and we import these .js and .css files to make everything look right and function dynamically. Then suddenly, someone from another department complains: the .js and .css files are too large. They're a whole 50KB. Wow, we need to optimise!
What I've seen happen at most companies when a warning pops up that a webpage is too large—because certain tools flag issues around speed and optimisation—is that a series of meetings is immediately scheduled. "We need to optimise! Get rid of all third-party scripts, everything needs to be gzipped, the pipeline must be faster, everything has to be better!" After the first meeting, a team is tasked with reviewing all third-party scripts, but it turns out we can't just remove everything. We need Bootstrap, we need Lodash, and what about Day.js? We definitely need that. Optimisation turns out to be more complex than we thought. However, component X can probably be improved, which might reduce the bundle size by a quarter! Eagerly, four developers start working on it, and after three weeks, it's done. Component X is optimised, and we've saved a quarter of the bundle size. Problem solved!
Then comes the realisation that we haven't really solved anything at all. It turns out that our own HTML, .js, and .css files (with some help from third-party scripts) aren't the real culprits. The real issue lies with the images from content management, the cookie banners, and all the scripts from Google (analytics, ads, etc.). As frontend developers, we can do very little about that. Out of all the megabytes being loaded, we're responsible for only a few kilobytes.
In my opinion, we're focusing on all the wrong things. We're looking at what can be optimised within our own little bubble, instead of stepping back and examining what the real issue is. We've introduced so much bullshit (like pipelines, abstractions, polyfills, etc.) that all we can focus on now is this mountain of nonsense. We lost connection with what visitors/users want. We do what we want.
We tend to focus too much on fulfilling meaningless tasks, forgetting where we can truly make an impact. I believe we should;
We should be pleased that, starting in July 2025, the regulations regarding accessible websites in Europe will become stricter. This provides most companies with more time to genuinely address accessibility. As front-end developers, we should be focusing on this area; whereas our previous emphasis was on cross-browser development followed by cross-device compatibility, our attention should now shift to cross-accessibility. Unfortunately, this is still happening too infrequently and without structure. While well-known pain points are being resolved, development teams must adopt a well-structured approach so that everyone in the team can contribute, rather than placing the responsibility on just one person. In my opinion, accessibility is currently the most important topic we should focus on.
t’s almost hard to believe, but many websites are still not properly usable on all types of devices. Corporate companies often manage well, but there are still many issues with smaller enterprises. It often starts with designers, who still prefer to design for desktop. This is understandable since they work on desktops themselves and can visualise it best that way. Also stakeholder think desktop, so when showcasing the new designs the desktop variant is shown. It’s our responsibility to challenge designers to consider how their designs will look on other devices as well.
Let’s stop overthinking things. It may be a hard pill to swallow, but front-end software is essentially disposable. What you create today will likely be outdated and irrelevant in a few years. So, let’s not pretend that our software will last for 20 years. Write clean and readable code following the standards agreed upon with your development team. Challenge the lead developer, but don’t go overboard. Use tech when needed, not because you want to use it.
As frontend developers, our work is varied—we build both visible and invisible components for websites and applications. We enjoy staying busy, but we often overcomplicate things unnecessarily. If we were more pragmatic, we could accomplish much more with fewer people. By cutting down on pointless tasks, we can refocus on what truly matters: making our applications accessible to everyone and improving the user experience for all. Stop the bullshit.
Author:
Jasper Seinhorst
Do you retroactively apply web accessibility (WCAG) to your apps, or is it already on your backlog for this sprint? Then you need to read this article. We – all frontend developers – are approaching WCAG completely wrong. It’s part of our job, but we treat it as an afterthought. Stop the bullshit about being EAA-compliant and make accessibility a real part of your work.
Since my childhood, I have been passionate about cars and everything related to them. Even at a young age, I knew every model. I spent hours flipping through car magazines searching for new facts and always dreamed of owning an exotic car. Initially, I used to dream of owning a Ferrari, but as I grew older and wiser,…
As a frontend developer, my days are primarily filled with crafting JavaScript-based components using frameworks like Vue, React, or Angular. These frameworks excel at empowering me to create reusable frontend elements, whether it's buttons, modals, links, or accordions. However, as I reflect on my reliance on these…
