The story of how frontend went from designing layout with HTML tables to directing AI agents to write the code for you.
When I started building websites in 2002, the word "frontend" barely existed. We were webmasters. We sliced Photoshop files into GIFs and reassembled them inside <table> cells. Nested tables, spacer GIFs, bgcolor attributes. The browser was a tyrant and we bowed to it.
Internet Explorer 6 was the law. If it worked in IE6, it shipped. If it looked broken in Netscape 4, you noted it in the README and moved on.
Alongside the tables there was Flash, and I met it before I met the web proper. I learned it during my education, and my last project there was interactive video, built in Flash. That was around 2002, which tells you how early it was already a serious tool. Timelines, tweens, ActionScript. It was the only place where you could be a designer, an animator and a programmer at the same time, and what you drew on the stage was exactly what the user got. No browser quirks. No IE6.
Later I built whole mini websites in Flash for Cafeteatret, as promotion for their theatre productions. Each production got its own little world, with video, sound and all kinds of user interaction. It was the kind of site that could not have existed as HTML at the time.
Then the iPhone arrived without a Flash plugin, HTML5 and CSS3 grew up, and the ecosystem faded out. What stayed with me is the feeling of owning the whole experience, from the first pixel to the last interaction. I still chase that feeling today, just with different tools.
Meanwhile, back in HTML land, a small group of designers had started writing manifestos. Zeldman. CSS Zen Garden. The Web Standards Project. The argument was simple: separate structure from presentation.
I remember converting my first site from tables to CSS floats. It took a week. It broke three times. It was mind blowing.
JavaScript had always been there, used mostly to validate forms and annoy users with popups. jQuery changed that. Suddenly the DOM was something you could talk to.
$(document).ready() became the incantation that started every project. Plugins for everything. Sliders, carousels, accordions — the skeuomorphic web in full bloom.
Facebook shipped React and quietly ended an era. The mental model flipped: instead of a page with behaviour bolted on, you had a tree of components, each owning its own state.
This was the moment frontend became genuinely complex engineering. Build pipelines, module bundlers, transpilers, type systems. The toolchain exploded. So did the job titles.
By the time I joined Capgemini and later Schultz, frontend had grown into distributed systems territory.
I spent a year as a delivery architect on a micro frontend and microservice platform used by a global company's workforce. Module federation, shared design systems, cross-team contracts, CI/CD pipelines. Less writing components, more drawing diagrams and writing ADRs.
The craft was still there — but it lived inside a much larger machine.
Something shifted again when the LLMs got good enough to write code.
At first I used them like a smarter autocomplete or a replacement for Stackoverflow. Then I started treating them like a junior developer I could pair-program with. Then — working on projects like Endbringers and Brians Origin — I realised the role had changed again.
You are no longer always the person who writes the code. You are the person who knows what to build, why, and whether what was built is correct. You hold the taste. You direct the agent. You review the output.
The tools changed every five years. The discipline underneath did not.
Understanding how a browser renders a page. Knowing when state belongs in the component or in the URL. Being able to read a layout and know how to build it without fighting the cascade. Having empathy for the person on the other side of the screen.
None of that was automated. All of it still matters.
24 years in, I am still interested in what comes next and how it can enable us to build great apps.