
Over-engineering is under-engineering - robin_reala
https://www.baldurbjarnason.com/notes/under-engineering-websites/
======
tboyd47
There's just a generalized lack of understanding about web technology among
web developers. I don't think many web developers even pay attention to
browser features until they are popularized by some new framework.

Frontend developers are bad, but backend developers are guilty too. While
frontend developers are breaking scrolling and the back button, backend
developers are busy breaking authentication, security, and caching.

I think the only solution is to form some kind of developer's association
dedicated to training and best practices. I hesitate to say "union," because
the problem of over-under-engineering could be our fault, not necessarily our
employers' (although pressuring new grads to deliver code at the same pace as
their peers may contribute). It would be great if there were more bootcamps
that just trained frontend devs on the latest HTML, CSS, and plain Javascript
before WASM and React abstract the frontend away entirely.

~~~
wruza
>training and best practices <...> the problem of over-under-engineering

That’s what you have to have once you throw a bunch of tools, planks and
screws at first graders and let them go. In my 20s I used few local enterprise
solutions to help local micro-businesses do their accounting. The base system
was obviously dumb and too restrictive to create “apps (tm)”, but it did its
job very well. One specific thing about it was that it was infinitely hard
(read: know C++/COM _and_ be able to investigate platform issues) to create
extensions for it and/or manipulate basic blocks like you can do with web
trinity. The result is that no one went that long route of dominating the
market with shady solutions that have value from non-tech faces, but are
technically crap.

Seeing what some devs could do even in these conditions, I can tell that it
was a good state of things for the tasks that platform meant to solve.

I may seem jump on topics on this one, but to not write a poem, look: Perl’s
tmtowtdi is highly criticized, but what web allows is a “there are infinite
ways to do it” paradigm with no basic blocks or “best practices” like you name
it.

Summed up: if you’re writing apps that do edit objects, there is no room for
custom element offsets, scroll handlers, sql statements (except select for few
cases) and knowledge of http cookies, headers, urls, etc. If you can’t define
a datascheme with two clicks, draw a form layout by hand and write final logic
after 5 minutes, deploying in half a hour, without caring what
platforms/databases/browsers/ languages/frameworks/backups/ maintenance/ides
do you choose, then there is no room for business or app logic in your head.

>the latest HTML, CSS, and plain Javascript

Today it is like chasing specifics of plain 80386 assembly — the knowledge
that ages faster than you can read on it from zero to top professional
experience. If things didn’t get better in a decade, then it is a dead end.
Plank, screw and hammer problem never gets old.

~~~
mattgreenrocks
Excellent comment. The way we program for the web is ridiculous currently: the
abstraction level is way too low.

> Today it is like chasing specifics of plain 80386 assembly

I suspect the fetishization of the unholy Web trinity (HTML/CSS/JS) is
impacting the ability of devs to imagine a better workflow. Case in point:
Electron. Rather than take some of the lessons learned from the web stack,
such as immediate mode UI being a decent default, they just crammed _all_ of
it into a Chromium shell and declared it The New Way To Write Desktop Apps.

If the web is your first platform you've spent a lot of time on, then what I'm
writing will probably just sound grumpy. And part of it is! But, on the other
hand, when something new comes along, it may render all of your intimate JS
knowledge useless because it isn't JS, and you need to be able to let that
knowledge go. Even if the web as a platform sticks around, history shows that
whatever comes next might be less powerful than using raw HTML/CSS/JS, but it
doesn't really matter for getting most things done.

~~~
0xdeadbeefbabe
> whatever comes next might be less powerful

So webassembly doesn't come next?

~~~
mattgreenrocks
Whatever comes next may not afford all the little nitty-gritty things you can
do via HTML/CSS/JS. Imagine a VB for the web that hides that stuff in a better
conceptual model: you lose the ability to do some things (potentially) but get
the ability to do other things more easily.

------
mbrock
I don't know if I'm making this up, but doesn't overengineering classically
refer to the engineering practice of having wide safety margins or
"unnecessarily" high performance?

Like, making the bridge twice as strong as it should need to be, or making the
car faster than it's wise to go.

That's different from typical software overengineering, which usually doesn't
make the product measurably better, just more complicated.

~~~
tobyjsullivan
They are fundamentally the same thing.

A bridge built to be twice as strong is measurably better in the sense that it
is stronger, yet no better in the sense that it doesn’t achieve its purpose
any better. Yet, to make it stronger will involve complicating the design
(having a bridge that is twice as strong out of coincidence is just luck - not
over engineering).

Comparatively, reimplementing form fields is better in the sense that the
experience is more customizable. However, it is no better in the sense that it
doesn’t actually help the user fill out a form any easier. Again, the over
engineering adds complexity.

In both cases, the added complexity has costs which would have been best
avoided altogether.

~~~
jaclaz
Yes and no.

Speaking of bridges, you are IMHO a bit too extreme, a "double strength"
bridge is definitely bad-engineering.

Over-engineering is (as an example) using a modified asphalt to pave the
bridge (very good for adherence when raining and on cold, snowy places) in a
warm climate country where it rarely rains, and never snows.

The good old definition of (construction) engineering norms is (maybe was)
revolving around representing the reasonable cost for the society of
reasonable levels of "safety" and "convenience" (both rather difficult to
establish BTW).

When it comes to computing (and similar) the problem is often what I call the
"because I can" syndrome, on the web there is an over-complication (maybe more
accurate than over-engineering) on an increasing number of sites, which as an
example if you have poor connection or not the latest OS and browser, reduce
the number of visitors (or the quality of their experience) and this is the
"under-engineering", as the site (while possibly offering a superb experience
to someone accessing it with a given connection/Os/browser) will be
inaccessible or only partially working to a not-so-trifling number of
potential customers, so the site does not deliver fully what is supposed to,
so maybe more accurately, it is over-complication that makes the result be
under-performing.

------
TimMurnaghan
I think that what you're reaching for is wrongly engineered. Some of the big
frameworks go through huge effort for non (or small requirements). I continue
to be amazed at the nonsense about hot-loading and time-travel debugging that
people think are framework requirements - while requirements like good
bundling or actual debugger support which doesn't blow up on trivial examples
go unfixed for years. It's those framework non-requirements which fuel the
idea that the frameworks create bloat.

It's all about minimizing the effect of the non-requirements, careful choice
of a minimal set of sensible enough frameworks, and then rigorous agile
prioritization at the application end.

~~~
tboyd47
I've adapted to this team anti-pattern by becoming relentlessly skeptical and
cynical in my work. I don't let anyone tell me something is "trivial" or
"easy" in programming unless I've actually seen it (meaning, with my own eyes,
not reading about it on a blog), and protest untested ideas from coworkers
vigorously, even if that person is a developer on my team whom I respect. I
kind of hate this solution because it makes me automatically resistant to
anything new whatsoever, but I hate it less than some of the code I've been
forced to write to fill in gaps left by some flavor-of-the-month tech.

~~~
g-b-r
It's a good attitude as long as it doesn't turn you into a old coot stuck to
his vb6. It's good to always be skeptic, but don't let that stop you trying
new things.

------
nathan_long
Salient quote:

> 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.

~~~
tboyd47
The worst thing about reimplementing native controls (and what everyone
misses) is that those native controls don't go away. Instead, their behavior
becomes undefined as the system grows around the reimplementation.

------
DrFell
To me it's simple. A lot of web developers pretentiously covet complexity
because it makes them feel smart to wield it. Plus, they never really learned
that engineering is the divination of simplicity from complexity. They don't
get over-engineering, because isn't that just more of a good thing?

~~~
zbentley
That's not entirely wrong, but I think that engineers fall prey to negativity
bias [1] in this area. There are tons of really complex tools that we don't
hate on because we barely notice that we're using them. They're either things
well-engineered enough that the complexity is mostly hidden (think JQuery
equivalents), or less well-built things that we learned so early, or use so
frequently, that we rarely notice having to deal with their complexity/poor
engineering.

[1]
[https://en.wikipedia.org/wiki/Negativity_bias](https://en.wikipedia.org/wiki/Negativity_bias)

~~~
maxxxxx
jQuery is a nice example. It was a pleasure to use and useful from the start
on. Whereas with some of the modern Javascript frameworks you have to create a
huge machine before anything can get done.

~~~
DisownedWheat
Then just use JQuery? Nobody is stopping you. Those modern frameworks are
excellent if you're making anything bigger than a blog.

------
contingencies
If you've read the article, this quote sort of stings in the sense that the
article is mostly about labels within frontend development and backend
developers are then accused of breaking caching!

 _There are only two hard things in Computer Science: off by one errors, cache
invalidation and naming things._ \- Phil Karlton

... more at
[https://github.com/globalcitizen/taoup](https://github.com/globalcitizen/taoup)

~~~
hinkley
It’s better when the punchline comes at the end.

------
wiredearp
> We share custody over the bratty toddler — custom elements.

Now that Apple has declared veto against the `is` attribute, I think the
author should be prepared to give up on that claim.

    
    
      <input is="my-fancy-input" type="text"/>
    

This will not work. To assign behavior to the input via Custom Elements, your
only remaining option is to create a whole new element.

    
    
      <my-fancy-input/>
    

This might append a normal `input` element to the Shadow DOM, but still won't
make the form accessible or even just behave naturally without substantal
over-engineering. Custom Elements have become a cause the major concern
identified by the article.

> Recreating browser features will almost always be both under- and over-
> engineered.

This problem is identified in the Custom Elements specification already [1] so
the browser vendors are simply not with us here.

[1] [http://w3c.github.io/webcomponents/spec/custom/#custom-
eleme...](http://w3c.github.io/webcomponents/spec/custom/#custom-elements-
autonomous-drawbacks)

