Recently, when searching for my next place of work, I came across an interesting observation. It shows through in different contexts, like just browsing through LinkedIn or when an interviewer reacts with surprise to your response. These days plenty of front-end professionals who do decent React or Vue (or Angular, you name it) have no experience of what web development felt like before today’s major frameworks appeared and matured. And it makes total sense — they got into coding when today’s tools were already a given.

It might sound like some old man rant — and my previous team even used to call me the crazy grandpa — but to me, truly, that’s just how things naturally are.

Still, the toolkit of today hasn't appeared out of nowhere — it’s the result of evolution driven by developers trying to solve practical problems as they arose. So to me, it makes a lot of sense to have a picture of how React and friends came into life and what preceded them.
Having that context gives our vision perspective and helps us to see whys and not just whats.

As Newton said:

If I have seen further, it is by standing on the shoulders of giants.

What he meant was that our insights aren’t entirely our own — they’re built on the ideas and discoveries of those who came before us. And being aware of that is crucial if we want to avoid repeating old mistakes.

Otherwise we risk slipping into being developer goldfish, which brings the following disadvantages:

Because often “instead of this today’s thing, why don’t we just” ends with another reinvention of a bicycle that broke years ago. 🚲 That got recycled ♻️ And completely forgotten. Ah, and that’s the trap, isn’t it?

That’s exactly how I feel about the hype around SSR. Or, file-based routing. It’s not just the same old bicycle, but also the sticks. Somehow, we managed to keep the old sticks that we’re about to jam into the wheels!

Or, remember how I mentioned an interviewer’s surprise at the very beginning of this post?
It tends to come up when I start talking about React as a response to the problems of “traditional” imperative rendering. Or when I bring up Flux and credit that pattern with at least half of React’s success.
I often get raised eyebrows when I’m asked something like “What’s the advantages of Promises?” And I’m like — compared to what? Callbacks? Generators? Synchronous calls, maybe? Didn’t we cover all that back in like 2014?

And it’s not just about opinions or personal taste.
A lot of it comes down to how different perspectives lead us to highlight different nuances — the ones we see as essential to a particular approach or technology.

That's why I decided to put together a short recap of how web development has changed over the last 20 years, from my personal perspective.

➡️ Meet The long WHY behind React Pt.1