How did we get here?
To answer this question, we need to take a quick look at the history of the front end…
Historically, the backend has had more credibility. It’s where the “serious business” by “real developers” happened. The front end was a play thing.
It was for fan sites on GeoCities and random musings on LiveJournal. It was “under construction” banners and the
blink element. It was for weird fonts and l33t speak and quirky fan sites.
Now, the web is a platform where “serious work” happens.
It runs full-on applications people can use to create presentations and spreadsheets, edit photos and videos, and have real time conversations with people halfway around the world. It’s an amazing piece of technology!
Many backend engineers moved over to the front end, and brought with them their best practices.
Because of our historical lack of credibility, our emerging platform maturity, and our desire to be taken seriously, a lot of front end developers latched onto these best practices, too.
You hear it in statements like:
I need a framework because I build apps, not websites.
Vanilla JS doesn’t scale.
CSS isn’t a real programming language.
The front end is fundamentally different from the backend
But there’s a problem with applying backend best practices to the front end: the backend is not the same as the front end.
In the backend, you have lots of control. You control the operating system that your code runs on, and when it runs. You control the storage and the RAM and bandwidth that’s available. There’s predictability.
In the front end, you have no control.
What we build is accessed by devices of varying capability, by users of varying experience and technical skills, on networks of varying strength and reliability.
We keep throwing more JS at things in attempt to force the control we get in the backend onto the front end. But that’s not how it works.
Trying to fight the nature of the medium is the source of a lot of the pain with modern web development.