index.md 7.1KB
title: Over-engineering is under-engineering
url: https://www.baldurbjarnason.com/notes/under-engineering-websites/
hash_url: af8a8291cd
There’s a gif going around presenting a debate about whether websites are under-engineered or over-engineered as Elmer and Bugs doing their duck-season/rabbit-season skit.
It’s really only funny if you’re a ‘big project’/’big organisation’ JS developer. It’s a joke that’s honestly largely indecipherable to those of us outside the big tech corporation trenches doing our smaller things.
Frontend development discussion. pic.twitter.com/Uz7n0Kdnll
— Jake Archibald (@jaffathecake) November 14, 2017
My best guess is that this joke hinges on the fact that most client-side code is severely under-engineered for its actual purpose but also at the same time massively over-engineered.
Both at the same time.
(The fact that two things can be true, both at the same time, is a bit of a running theme of mine.)
It’s probably obvious to the startup/big-tech-co crowd that most of their work is actually under-engineered: it doesn’t do the job it should be doing.
This is particularly noticeable when it comes to accessibility.
You need to make the form look a certain way and to do that while also keeping the widget accessible requires an enormous amount of, well, engineering.
It’s also an issue for website performance. Most websites are much too slow which means, given that dropping features is untenable from a business perspective, they are by definition under-engineered.
(Again, this is my guess as to what their perspective is. The situations I’ve usually been in tend to be under-staffed and under-resourced. There the perspective is generally more “what’s the absolute least we can do to get the job done”.)
The “humour” then is that they find accusations of over-engineering funny because they know their work is generally comprehensively under-engineered. Hence the rabbit-season/duck-season schtick.
The problem
These sites are always both under-engineered and over-engineered. Moreover, they are under-engineered because they are over-engineered. That’s the criticism.
When the less-is-more web crowd criticises popular frameworks and libraries for over-engineering, it isn’t a criticism per se of their complexity. You generally don’t become a web developer without accepting complexity as a hard requirement of the modern web. We lament that fact all the time, but it’s there and it’s unavoidable. So, again, the criticism isn’t specifically that these sites’ constructions are complex.
To pick a specific example: the problem with an over-engineered form is that the amount of code required to replace no engineering (i.e. native form controls with basic styling) is enormous and almost always only partially successful (i.e. under-engineered).
They are under-engineered because they are over-engineered—tried to replace native controls.
This is the basic argument against most forms of website over-engineering: scroll-jacking, manipulating history with pushState, completely customised form controls, etc.
Recreating browser features will almost always be both under- and over-engineered.
Why it won’t be solved
The web developers working in the (well paid) corporate or proto-corporate (i.e. startups) gulag don’t have a choice. The products they work on need features. And tracking. And analytics. And swishy transitions. And manager-pleasing fancy-pants animation. And they need to follow the corporate visual style. And they don’t know what other teams are doing half the time so they need some form of isolation or compartmentalisation.
The web developers who work for small, massively under-funded organisations or individuals don’t have a choice either. It doesn’t matter whether we’re in-house or freelance, we simply don’t have the resources to follow down Facebook’s path. Re-using the methods, libraries, and tactics common among the startup crowd isn’t an option.
Our ‘team small enough to be fed by two pizzas’ is the entire goddamn company, including the accountant.
We simply can’t do what the other crowd does and successfully build and maintain products and services. We can use their methods to ship products but after that things start to fall apart because the maintenance costs of their solutions are simply too high.
So accusing the ‘we have communications problems because the dev team is too big’ crowd of over-engineering will only be met with disdain and mockery. Clearly you are incompetent because you don’t realise that these solutions are almost always under-engineered.
Conversely, being on the other side and facing regular accusations of incompetence and ignorance breeds a fairly healthy disdain for the enterprise/startup side of the scene.
And, yeah, from my perspective enterprises and startups are pretty much only distinguishable in their adoption of server-side tech like AWS Lambda. Their front-end strategies are pretty much identical.
The only thing we can do
Maybe it’s time that the web development scene simply accepts that it has fractured into multiple communities, each with different requirements and needs.
Of course, browsers are going to pay undue attention to the enterprise side because they themselves are on the enterprise side. That’s fine as long as they don’t lock the rest of us into re-writing rendering behaviours from scratch using Houdini just to make a basic HTML-rendered web service.
And even though from an outsider’s perspective the enterprise/startup web developer job looks like a huge pain in the arse—mostly dedicated to re-building things the browser already does, just with a ‘this is our brand’ corporate spin—they do also get paid handsomely for their efforts. When they reach my age they’ll all probably own their houses mortgage-free. So, kudos. You do you.
But we don’t all have to walk down the same path in life. And we can’t all make websites the same way.
If, as it’s starting to look like from my perspective, these two communities are incapable of learning from each other, then maybe we should start consider some sort of community divorce?
We get HTML, CSS, and SVG. We love that shit and you just keep stuffing it into the JavaScript sack whenever you are left alone with it.
You get to keep WebGL, Shadow DOM, WASM, React, and Angular.
And we share custody over the bratty toddler—custom elements. They remind us a bit of their parent—jQuery—who always got the job done with a minimum of fuss.