Browsing the web sometimes feels more sluggish than it was 15 years ago and the cost of web development has grown significantly. Is this progress actually an improvement?
In the past, online libraries allowed us to read an entire book just by opening a simple HTML file — a 300KB download with simple CSS for fonts and usability and almost no Javascript. The server was doing the paging, the client could perfectly cache the HTMLs and display them almost instantly the next time they were opened. Now, in some online libraries you get around 2MB of resources (up to 1MB of which is JS) downloaded to read a single page of a book.
According to HTTP Archive Almanac, in 2022 the median desktop page loads 1,026KB of images, 509KB of JavaScript, 72KB of CSS, and 31KB of HTML.
Fifteen years ago I was reading books on Project Gutenberg and all my browser needed to do was download one single HTML with the book contents.
Today, if I visit an online-library like this one, I see almost 5MB of resources and client-side pagination.
Looking at this, it's unsurprising that browsers often display “out of memory” warnings, even on computers equipped with plenty of RAM.
The escalation in complexity impacts not just the user experience, but also significantly inflates development costs. Previously, a product like an online library could be efficiently managed by a single full-stack developer proficient in PHP, databases, CSS, and HTML. In contrast, today’s standards typically require at least a team comprising both front-end and back-end developers.
Developers make web applications more complex for the same (or worse) UX
Developers and companies frequently embrace new technologies and frameworks to align with industry trends or to demonstrate their technical capabilities. This trend often leads to the implementation of Single Page Applications (SPAs) and intricate UX elements in situations where simpler solutions, like server-side paging in online libraries, would be adequate.
A prevailing belief within certain segments of the tech industry is that users anticipate dynamic, app-like experiences on all web platforms. This assumption drives the adoption of more complex architectures, even when a traditional multi-page setup might be more fitting. In the zeal to adopt “modern” methodologies, aspects like usability and accessibility can be inadvertently neglected.
This oversight is particularly critical for electronic libraries, where an easy-to-navigate, server-paged interface might be more beneficial than the complex interactivity of SPAs. Take, for example, bookmarking functionality — a simple feature in server-paged systems that requires additional development efforts in SPAs.
For instance, in web applications such as online libraries, incorporating complex animations may not only be unnecessary, but can also create a misalignment between the application's intended purpose and its actual implementation. Examples like heavy parallax scrolling effects and complex transition animations in menus can be particularly cumbersome on mobile devices.
Testing these animations is not a straightforward engineering task, either. Proper testing often requires significant manual effort, as automating these tests can be exceptionally challenging. This can result in animations that are not optimally performance-tested, leading to slow or disruptive user experiences, especially on mobile. For instance, animated chatbot interfaces, while visually appealing, can significantly slow down interactions on less capable devices. Similarly, elaborate loading animations meant to provide a visual distraction during loading times can paradoxically extend these times, further impacting the user experience.
Moreover, many organizations adopt a standardized set of frameworks or technologies, aiming for consistency and efficiency in their development processes. This approach often results in a blanket application of SPAs across various projects, without considering if this is the most user-centric solution for each specific case.
“Playing games” with tech made development more complex and expensive
The landscape of web development has seen a significant shift from straightforward HTML/CSS/PHP configurations to more complex structures. Contemporary web applications often use advanced frameworks like React and Redux for front-end development, coupled with Backend for Frontend (BFF) patterns and microservices architecture on the server side. While this approach may be justified for certain applications, it can be excessive for others, such as online libraries.
This escalation in technical complexity requires a team with diverse, specialized skills — inevitably increasing the cost of web development. Tasks that could previously be handled by a single full-stack developer now frequently demand a collaborative effort from professionals with expertise in front-end, back-end, DevOps, and cloud infrastructure.
These increased development costs are inevitably passed on to the users, impacting the overall affordability and accessibility of web applications. Furthermore, the focus on advanced features and aesthetics, such as animations and complex graphics, not only draws more on the user's device battery but can also lead to slower performance, particularly on lower-end devices. As a consequence, the emphasis on technical complexity and visual appeal can result in less investment in developing truly useful functionalities for the users, potentially diminishing the user experience and the practical value of the application.
Why this matters
In my view, spending resources on tasks that could be accomplished cheaper is clear “waste.” Opting for the simplest yet effective tech stack not only benefits users by providing a faster, more user-friendly experience, but also favors companies. Simpler technology translates to easier, cost-effective support and maintenance. When companies allocate more resources to addressing real user problems, user satisfaction invariably increases.
Additionally, I think that from the ethical perspective it's preferable to invest time in meaningful work rather than indulging in technology for its own sake.
More technology means more risk
Incorporating more technology layers into the stack introduces additional risks such as testing challenges, compromised security, and a higher learning curve.
As complexity increases, so does the difficulty of testing. Server-side rendered templates, which were straightforward to test, have been replaced by complex frameworks like React, requiring intricate testing methodologies. The more complex a system is, the more challenging it becomes to test it effectively.
Every new technology integrated into the stack also presents a potential security risk. For instance, GraphQL can open up extensive attack vectors. Issues like the infamous left-pad incident or the event-stream module’s vulnerabilities underscore the security risks of dependency management. More technology necessitates more rigorous security testing.
The learning requirements have evolved as well. We’ve gone from basic PHP, databases, HTML, CSS, and JavaScript to a more diverse and complex set of skills including TypeScript, JavaScript, React, Redux, GraphQL, NodeJS, and more, just for front-end and BFF development. These technologies require continuous updates and understanding, adding to the complexity of the learning process.
After mastering Javascript and CSS, a developer could spend time on learning something else, as all the ES3 code would still work just fine in any modern browser, 23 years after the specification was published.
This increased complexity not only strains development resources but also impacts the agility and efficiency of teams, ultimately affecting the efficiency of teams and the end product delivered to users.
Support costs are higher
Consider the case of once-popular frameworks like ExtJS and YUI, which have both since faded into obsolescence (1, 2). The decline of these technologies left many clients facing the daunting task of migrating to new platforms. This situation prompts a critical question: what are the financial and logistical implications of such migrations?
Looking forward, one can't help but wonder about the future of current mainstream frameworks like React. What happens when it, too, falls out of favor? Are companies and developers ready to bear the costs and challenges of transitioning to the next “shiny” framework that takes its place?
Do the benefits warrant this extra complexity?
I’ve covered a lot of the negative impacts of increased complexity in web development — and I believe these are big concerns — but it’s not all bad news.
A notable advancement is the improved consistency in JavaScript execution across browsers. With the widespread adoption of ES6, developers can now be more confident that their JavaScript code will run uniformly across all modern browsers, a significant improvement from the variability experienced 15 years ago.
In terms of CSS, the universal support for CSS Grid in modern browsers has simplified interface layout design, streamlining the development process.
The tooling ecosystem has also seen encouraging progress. GitHub Pages stands out as a prime example: it offers exceptionally straightforward hosting for static pages, directly from a GitHub repository, with no server-side complexities. This simplicity is ideal for hosting blogs and landing pages, as evidenced by my personal page hosted there.
The serverless paradigm, embodied by services like AWS Lambda, Azure Functions, and Google Cloud Functions, further simplifies backend development by eliminating the need for server management.
Despite the challenges, these advancements suggest a bright future for web development. My hope is for a more rational and pragmatic approach in the selection and application of technologies across the industry, focusing on building applications that are both efficient and user-centric.
