15 years in web development: what changed and what didn’t

I built my first paid website more than 15 years ago. Back then mockups arrived as PSD files with dozens of layers, layouts were held together with tables and floats, and any interactivity meant adding jQuery plus a couple of plugins. Today I use completely different tools, but some things haven’t changed at all.

What changed

The tools changed most visibly. PSD gave way to Figma: the design lives in the browser, clients leave comments right on the mockup, and components and styles move into code almost without loss. jQuery gave way to Vue 3 and Nuxt, where the interface is built from components and the server sends a ready page that search engines can read.

• Layout. Flexbox, Grid and Tailwind CSS removed most of the hacks we used to fight for hours.
• Backend. Node.js, TypeScript and Prisma let one person confidently run a project from the database to the interface.
• Infrastructure. Docker and proper servers replaced FTP and copying files to shared hosting by hand.
• AI tools. They speed up routine work: draft copy, boilerplate code, quick checks of an idea. But decisions, architecture and responsibility for the result are still mine.

The projects themselves changed too. Most orders used to be simple business card sites. Now they are more and more often services: dashboards, CRMs, video platforms, Telegram bots. A website is no longer just a shop window; it has become a working tool for the business.

What stayed the same

Clients don’t come for a technology. They need leads, sales, less manual work or a convenient tool for their team. So the first question I ask is the same one I asked 15 years ago: what business problem should this project solve?

Speed still matters as well. A slow page loses visitors whether it runs on jQuery or Nuxt. And clarity is as valuable as ever: within a few seconds a person should understand where they are, what is being offered and what to do next.

What I took away

Technology is worth updating, but not for the sake of fashion. I switch to a new tool when it genuinely makes the product faster, more reliable or cheaper to maintain. I have also learned that the best projects happen when the client and the developer speak the same language: the language of goals, not frameworks.

There are many more changes ahead, and I’m excited to be part of them. But the principle stays simple: make sure the website or service is genuinely useful to the people who use it.