There’s a growing trend within the tech industry that criticises the state of the modern web. For the last decade or so companies around the world have been deploying abstracted web frameworks and leaning-towers of JavaScript libraries within their products to achieve their business goals, but a handful of technologists and web experts are rightly raising concerns about the severe overloading and overcomplication of what we serve to clients in order to show even the most basic of pages.

I think the critiques here are majorly rooted in the fact that to achieve 80% of what businesses require out of their product, all that’s needed is pure HTML and CSS, which is an extremely lightweight and well-supported stack, and the other 20% could be progressively enhanced with JavaScript on an as-needed basis, which if done correctly can be very performant.

What caused this shift in industry from the glory-days of old, and what problems can we expect to see as symptoms of this overarching problem?

The Cause

Unfortunately, as much as I’d love to come out with some red-hot conspiracy on the state of the internet, I’m afraid once again the real root-cause is just dollars and cents. Profit and velocity have prevailed as our leading motivation for doing anything.

Why would we waste time learning these archaic web technologies or burn our time and money hunting & hiring from a small pool of skilled developers when we could just pay peanuts to anyone who can deliver div-soup with a side of 500 dependencies and get our new feature across the line next week?

Because a significant portion of the internet is steered by the folk with the money bags, and those folk also really like to make decisions based purely around their bags of money, we now see stark popularisation in the usage of heavy web frameworks and development practices that prioritise quantity over quality.

The Effects

While on paper these decisions might make the accounting department quite satisfied, they are not without cost. There’s no such thing as a free lunch, even on the internet, but the costs of the industry attitude towards web development lean significantly towards an ethics/equity problem, which is a tough sell to a board of directors, so most founders pussy out, take the “easy” road, and deploy yet another React app.

Bandwidth Gatekeeping

The first and most glaring problem I see with the current day approach to building web products is the over reliance on a stable and fast internet connection. Often, web applications are developed by teams sitting in an office with a high-speed connection or by WFH contributors who have forked out for their ISP’s top-tier plan. Developing and using products within this bandwidth bubble leads to a real lack of insight on how a product would perform to a significant portion of the internet.

This is an often quickly-retorted problem with some quip like “well we serve our target market, and they all work in an office with ripping fast internet too, so what’s the problem?”. The thing is though; they might have that capability now, but how can you predict how or where your target market will be working from in the future? Ways of working are constantly evolving, and with evolution comes new problems. The future of internet usage is incredibly fluid and if it were my web-based business on the line, I’d want to be leaning on the fundamentals as much as possible in order to create a steady ship to ride out the wild ocean of change.

Who Built This?

Another issue that arises (in my mind this is simultaneously beautiful and terrifying) is that many products are being built on top of any library that can solve their “right now” problems, these are open source libraries that can be written by any developer. The level of business risk this puts you in is multi-faceted.

1. As an organisation, you are now dependent on the code of 1 solo developer from a third-world country or somewhere rural as fuck that doesn’t even have the network infrastructure to run your bloated app. Should anything not work, they probably can’t or won’t help you, so it’s on your team to replace it with another library, or roll it themselves.
2. When libraries can be written by any developer, this is a direct cyber-security risk vector. Who’s to say that oddly convenient library couldn’t contain malicious code? The more libraries you’re using, the more you need to regularly audit for security concerns and the more possibilities you have of being vulnerable to an attack. Examples of this happening are ubiquitous.

“Just fixing it later” generally isn’t a great move either due to how crippling tech-debt can be. Many a startup has drowned under the weight of their development teams not delivering a single visible feature to customers for months on end due to the all-hands requirement of refactoring your entire company’s architecture. There’s a level of strategy here that doesn’t add up to me.

And so castles made of sand fall in the sea eventually — Jimi Hendrix

Unskilled Teams

I’d hate to talk ill of anyones capabilities and I firmly believe that anyone with appropriate motivation can become very good at any task, but I’m just going to say it: What we are seeing as a result of this slap-happy tech industry is a flood of severely underskilled developers that are capable of being paid way too much.

The over-reliance on abstracted technology frameworks leads to teams that are capable of achieving a lot of externally-visible momentum, which makes them look really valuable to non-technical folk, but when it comes down to the nitty gritty we start to see a large gap in knowledge of the underlying mechanisms responsible for how the internet works. This means a team’s ability to get us out of hot water beyond basic implementation issues is very small. Should any deeply technical problems arise, the selection of people capable of handling it is few.

This is a big risk for a business; as a business owner, I would want to know for sure that the code-monkeys in my company’s engine room are equipped with the skills and tools to make sure we succeed in a business no matter what technical shit gets thrown at us, not just a crew of overpaid UI developers (no shade to my pixel-pushing homies, I love that as much as you do, but we need to be well-rounded!).

Businesses then have a large incentive to invest in their tech teams either to hire the ones who understand this and have done the hard yards to really learn the fundamentals, or to train up the teams they have in how the web works and how truly elegant products are built.

I don’t say any of this out of a place of elite-ism, because honestly I think I’m in the unskilled bucket as well. As someone who self taught the fundamentals of web apps as a teen (before today’s popular frameworks), didn’t do university and only came into the industry a decade later after a 6-month coding bootcamp, it’s blown my mind how far I’ve been able to progress my career on the modern tech-stacks currently used by the industry, frankly it’s a little unnerving. In more traditional disciplines, 4 years into a career would leave me just considered competent, especially by any fossils who have been doing it for donkey’s years. In this trade it’s enough to land you senior and lead positions, mental.

Spinner Galore

The list goes on and I think this post is long enough, but I can’t miss an opportunity to fire a shot at my biggest web app pet-peeve. You know when you visit a website and it begins with a loading splash screen, then you see some of the page but all the content is blank, then you see some content but theres loading spinners everywhere and only after they piss off can you finally see what you came for? Yeah fuck that. I’ll curb the negatives of our tech-situation here.

The Solve

I think it’s on the developers to champion the push towards a simpler and more fundamental approach to the web, as the non-technical folk don’t have the context to grok the problem on their own. Outside of the most insanely large scale use-cases, we can achieve a lot with a very small and basic set of tools. If you spend all your time writing apps in a heavily abstracted framework, I challenge you to explore building out an idea using the most basic tech you can and then explore how to deploy it using the most fundamental methods. That means no Vercel!

I practice this on my homelab, where if I have an idea for a handy service, I ask myself how simple it could be. My latest problem was solved by a single HTML file served by nginx, it’s perfect for the job and it’s just under 7KB to load.

In production I understand there are limitations and requirements that mean we have to avoid re-inventing the wheel, but there are ways to do it that solve a number of the issues I’ve mentioned above. I built this blog with Astro, a framework that aims to keep payloads delivered to the browser JavaScript free and as of profiling, it’s still under 80KB over the wire to load this page. This is appropriate for so many “dashboard as a service” companies, so why bloat it beyond >1MB even before your API calls kick off? If complex interactivity and reactivity is a firm requirement and you can’t afford overhead of doing it the old-school way, why not explore frameworks like Svelte that manage to bundle so much functionality within it’s core library AND keep the payloads delivered to the browser quite tame.

Return to posts