If you spend enough time in web development, you start to notice something:
The stack is always changing… but the job is kind of the same.
New frameworks show up. Old ones fade out. Best practices are tweaked to accommodate the stack. And somehow, you’re expected to keep up with all of it while still shipping things that work.
Recently, I put together a project — thisold.dev — as a way to reflect on that evolution. It’s a snapshot of the different technologies I’ve worked with over time, and more importantly, what they represent:
Not just tools… but phases of how we build for the web.
The Early Stack: Simpler, But Not Easier
Early in my career, the stack was more straightforward:
- server-rendered pages
- basic JavaScript
- a database behind the scenes
You could understand the whole system without needing a diagram.
But “simpler” didn’t mean “better.”
There was a lot of:
- tightly coupled logic
- repetitive code
- manual workflows
- blocking client-server communication
It worked, but it didn’t scale well — either for the application or the developer.
The "webmaster"
These were the days of the webmasters. Those of us who could write perl scripts for the cgi-bin, craft database queries in MySQL, and configure Apache configs using mod_rewrite and subdomains. We didn't just create HTML pages, we were "full-stack" before that was even a thing.
AJAX to the rescue
When the Web Stopped Refreshing
Up until this point, every interaction with a server followed the same pattern:
You click something → the browser sends a request → the entire page reloads.
It was simple, but it was also limiting. Even small updates required a full round trip and a complete redraw of the page. It made applications feel slow and disconnected.
Then AJAX came along — Asynchronous JavaScript and XML.
You may also know this as the XMLHttpRequest API
Despite the name, it wasn’t really about XML. XML was just the most well known standard for sending data back and forth. Both XML and HTML evolved from SGML (Standard Generalized Markup Language).
The important part was ASYNCHRONOUS.
With AJAX, the browser could:
- send requests in the background
- receive data without blocking the user
- update parts of the page dynamically
All without a full page reload.
This was a huge shift.
Instead of treating the web like a series of documents, we started treating it like an application. Interfaces became more interactive. Data could update in real time. The user experience became smoother and more responsive.
It also laid the groundwork for everything that came after:
- single-page applications
- frontend frameworks
- API-driven architectures
AJAX changed expectations.
Users no longer tolerated full page reloads for simple interactions. And developers suddenly had a new level of control over how and when data moved between the client and server.
It was one of those moments where the web quietly became something else entirely.
The Rise of the Frontend Developer
Then things started to expand.
Frontend and backend became more distinct:
- Browsers introduced more ways to enhance web pages (and more ways to screw them up)
- CSS
- drag & drop API
- APIs became first-class citizens
- Not just the data going back and forth between client-server, but browser also Browser APIs
- JavaScript moved from being the cherry on top of desert to being the main course
- New JS frameworks started popping up everywhere
This is where my love of the frontend really started to take shape. I wasn't just writing scripts for cron jobs on the server, I was writing code for the browser that impacted user experiences.
It wasn’t just about getting something on the screen anymore — it was about designing systems and interactions that made sense.
Specialization… and Then Back Again
As the ecosystem matured, roles became more specialized:
- frontend engineers
- backend engineers
- DevOps / SRE
- database specialists
This made sense because it's hard for one person to know ALL of that and still remain a sane person. It's good to know the concepts and the ideas behind it all, but the old addage, "jack of all trades, master of none" feels relevant here.
You still be a generalist, but have a main focus on one piece of the puzzle.
Specialization is valuable, but knowing how your specialization fits with everything else is the next level. This is where you see people going to Senior and Staff level software engineers.
The most interesting problems live at the boundaries.
- How does your API design affect your UI?
- How does your database schema impact performance and developer experience?
- How do you balance clean architecture with real-world constraints?
Being able to move across the stack makes those conversations easier — and the solutions better.
The Tools Keep Changing
One of the biggest lessons from building thisold.dev was just how many tools (over 70) I’ve worked with over time.
That includes:
- languages
- frameworks
- libraries
- build systems
- protocols
- databases
- code editors
- AI agents
Some of them stuck around. Some of them didn’t.
And that’s kind of the point.
If you tie your identity too closely to a specific tool, you’re going to have a rough time in this industry. Tools change, disappear, or are replaced by better tools. (think grunt, gulp, webpack, and vite)
What Actually Stays the Same
Underneath all the changes, a few things have stayed consistent:
- Good Systems Start with Good Thinking
- The Frontend Still Matters (A Lot)
- The “Glue” Skills Are Underrated
- Adaptability Is the Real Skill
It doesn't matter what stack you're using, if the API and data models are crap, the whole system is doomed to fail.
Performance is key across the whole stack. One high-latency call to a microservice can cause the entire User Interface to timeout.
The Frontend is where your users live, don't neglect it. Perception is everything. That's why good analytics show you where users drop off. EVen the smallest bad experiences are costing you money.
Adapt or Die?
The tech industry can be a fickle beast sometimes. Job postings look for specific technologies in your skillset and if you are missing just one, the person (or AI) reviewing your application will reject you.
This misses the big picture, that good software engineers are able to:
- pick up a new framework without panic
- understand unfamiliar codebases
- learn just enough of something to be effective
That comes from experience — not just with success, but with:
- outdated tools
- abandoned projects
- things that didn’t quite work out
(And yes, I have plenty of those.)
The Love of Building
Even after all the changes in the ecosystem, one thing hasn’t really shifted for me:
I still love building things.
Not just finished products — but experimenting, building prototypes and messing around with half-formed ideas.
Like a lot of devs, I have a collection of unused domain names and a graveyard of dead repositories. But these aren't useless things, they were learning experiences. Maybe they became obsolete. Maybe work or life just got in the way. Ultimately they fed that need to figure out something new, make it work and play around with it.
Final Thoughts
The evolution of web tech stacks can feel overwhelming if you look at it as a list of things you need to learn.
But if you zoom out, it’s really a story about:
- improving how we build
- refining how we think about systems
- and constantly adapting to new constraints
Projects like thisold.dev are a reminder of that journey.
Not as a highlight reel — but as proof of something more useful:
The ability to learn, adapt, and keep going.
Because in this field, that’s what actually lasts.