Skip to main content
Front-end evolution timeline illustration
#Web#Guide

From Tables to Components — How Web Development Grew Up

A short history of front-end development from table layouts to modern component architectures, and what each era taught us about building for the web.

The web we build on today is unrecognizable from the web of 2000. Understanding how we arrived here helps us make better decisions about where we go next.

The table era

Before CSS layout existed in any meaningful way, developers used HTML tables to position elements on a page. Every website was a grid of nested table elements with invisible borders. Changing column widths meant restructuring the entire document. Responsive design was not even a concept.

The table era taught us that structure and presentation must be separated. When they are tangled together, even small changes become expensive.

The CSS revolution

CSS Zen Garden launched in 2003 and proved that a single HTML document could look completely different depending on the stylesheet applied. This was transformative. Developers started separating content from design. Floats became the dominant layout mechanism, and with them came an entire generation of clearfix hacks.

This era taught us that constraints breed creativity. Working within the limitations of floats and positioning forced developers to think carefully about document flow and progressive enhancement.

The JavaScript ascent

jQuery democratized JavaScript. Backbone, Angular, and later React introduced the idea that the front-end was not a thin layer on top of a server but an application in its own right. Single-page applications became the default architecture for anything interactive.

The lesson from this era was humbling. Just because you can build everything in JavaScript does not mean you should. SPAs introduced problems that server-rendered pages never had: broken back buttons, poor SEO, massive initial load times, and accessibility regressions.

The pendulum swings back

Frameworks like Next.js, Nuxt, and Astro represent a correction. Server-side rendering is back, but with the component model intact. The best of both worlds: fast initial loads, good SEO, and rich interactivity where it is needed.

At Kotito, we landed on Astro because it defaults to zero client-side JavaScript while allowing us to add interactivity selectively. This islands architecture aligns perfectly with how marketing sites and content-driven applications actually work.

What the history teaches

Every era of web development has been a reaction to the excesses of the previous one. The table era was too rigid, so we got CSS. CSS layouts were too limited for complex UIs, so we got JavaScript frameworks. JavaScript frameworks were too heavy for content sites, so we got static-first frameworks.

The pattern suggests that the next shift will be a reaction to the complexity of current tooling. Simplicity always wins eventually.