Guides

From Photoshop-sliced websites to AI: over 30 years of web development

I started in 1995, when a page began as an image, was cut into pieces and rebuilt in HTML. The tools have changed radically; the duty to build a useful, fast, secure and understandable website has not.

The short answer

Builders, CMSs and AI have lowered the threshold for publishing, not the threshold for designing well. A custom website is not better because it is hand-coded: it becomes better when control over the code removes needless dependencies, meets real requirements and makes every choice verifiable. That—not nostalgia—is the heart of the GLP method.

Gian Luca Partengo
Web developer since 1995 · custom websites · Updated: 29 July 2026

This is not a history of tools: it is a history of responsibility

The Web has become easier to publish and far harder to govern. Every generation solved one constraint and introduced new dependencies.

First-hand experience

Since 1995, I have seen almost everything change

I have worked with static pages, table layouts, sliced images, scripts, Flash animation, PHP, databases, CMSs, ecommerce, builders, frameworks and AI tools. Each transition seemed to make the previous one obsolete.

Yet the outcome still depends on the same questions: who the website serves, what it needs to explain, how long it must last, who controls the data, how it will be maintained and how we verify that it works.

01Understand the problem first
02Then choose the architecture
03Remove what is not needed
04Measure the real outcome

Technology follows project decisions; it is not the starting point.

1995: a website began as an image and became a table

Small screens, slow connections, incompatible browsers and immature CSS meant visual control came at a high price in weight, rigidity and maintenance.

The Photoshop layout

The entire page was designed as a graphic composition. The layout was then cut manually into images; Slice and Save for Web tools later formalised that workflow.

Tables as a grid

HTML cells held logos, menus, backgrounds, buttons and transparent spacers together. It worked visually, but mixed content and presentation in fragile markup.

Every kilobyte mattered

On a modem, an unoptimised image meant an obvious wait. Palettes, compression, dimensions and request counts were not details: they decided whether the page really arrived.

Compatibility was built by hand

Netscape and Internet Explorer interpreted parts of the Web differently. Testing several browsers and resolving exceptions was integral to development.

JavaScript: the page stops being only a page

Created at Netscape in 1995 and put on the path to ECMA standardisation in 1996, JavaScript brought logic and response into the browser.

Rollovers and menus

The first visible interactions swapped images on hover, opened menus or controlled small interface behaviours.

Browser-side validation

Forms could flag errors before submission, improving perceived responsiveness. Server-side verification remained essential.

Increasingly rich applications

Simple effects evolved into complex interfaces, asynchronous updates and applications running a substantial part of their logic on the client.

New power, new debt

Every script adds capability, but also weight, failure modes, dependencies, security risk and possible barriers to crawling and accessibility.

The lesson that still applies

Use JavaScript for behaviour that genuinely requires it, not to rebuild more fragile versions of what HTML and CSS already do well.

CSS: content and presentation begin to separate

Work on CSS began in 1994 and CSS1 became a W3C Recommendation in 1996. From there, layout could gradually leave tables behind.

Structural change

The design no longer had to live inside the content

HTML could describe headings, paragraphs, lists, links and data tables; CSS could handle colours, spacing, alignment, typography and visual arrangement.

This separation enabled coherent maintenance, reusable rules, different media and, over time, flexible layouts without turning every page into a mosaic.

More meaningful markup

Structure can describe content again. That is a decisive foundation for search engines, assistive technology and AI systems.

Reusable design

One rule can govern many pages and components, reducing inconsistency and repetitive changes.

Media adaptation

The same document can be presented differently on screens, in print and on devices with different characteristics.

Fewer decorative images

Native gradients, borders, shadows, layouts and animation progressively replaced many raster assets that were once essential.

Flash: extraordinary visual freedom, content inside a fence

From the late 1990s through the 2000s, Flash enabled experiences that the open Web struggled to deliver. The price was dependence on a plugin and a proprietary format.

Area	What it enabled	What made it fragile
Art direction	Very precise control over graphics, sound, typography and sequences.	Less-native content that was harder to adapt and dependent on the runtime.
Animation and interaction	Rich experiences when HTML, CSS and JavaScript offered far less.	Performance, accessibility and usability were often secondary to the effect.
Distribution	A consistent environment across browsers that interpreted the Web differently.	Indexing and content access depended on specific techniques and support.
Longevity	A vast ecosystem of tools, professionals and interactive content.	When the plugin ended, compatibility ended with it.

PHP and databases: the website becomes a system

PHP began in 1994 and its source code was released in 1995. Pages could be generated on the server according to data, users and operations.

01
Forms that do something
A request could be validated, sent, stored and turned into a real process rather than stopping at an email link.
02
Database-driven content
News, catalogues, records and archives could be updated without manually duplicating entire HTML pages.
03
Private areas
Sessions, authentication and permissions opened the way to personal services, intranets and management applications.
04
Ecommerce
Products, baskets, orders and payments turned the website into commercial infrastructure linked to company processes.
05
Templates and components
Shared headers, footers and functions reduced duplication and inconsistency, anticipating more structured models.
06
Server-side responsibility
Dynamic behaviour brought input handling, security, updates, backups, logging and data governance.

CMSs: publishing becomes accessible to people who do not write code

WordPress, Joomla, Magento and other systems made themes, plugins, catalogues and editorial workflows available to huge numbers of organisations. It was genuine democratisation.

WordPress

Created in 2003, it made content management and extension through themes and plugins straightforward. The flexibility of its ecosystem is also the source of its technical variability.

Joomla

Since 2005 it has provided a structured open-source CMS for portals, content and permissions, backed by a community and an extensible model.

Magento

It brought rich, highly configurable open-source ecommerce to the Web; its enterprise evolution now continues as Adobe Commerce.

Themes and plugins

They speed up common functions, but each extension brings code, updates, compatibility, quality and responsibility that the website owner must govern.

The CMS is not the project

It is infrastructure. It can be the right choice when editorial autonomy and the ecosystem outweigh maintenance and complexity; it becomes a problem when used to avoid analysis, architecture and expertise.

Wix, no-code and platforms: being online becomes almost instant

Wix was founded in 2006, moved from Flash to HTML5 and later added visual development and AI. The promise is genuine: many people can publish without building the infrastructure.

The real trade

Less initial complexity, less final control

Hosting, editing, components, updates and delivery come together in one service. This can be proportionate for temporary landing pages, prototypes, very small initiatives or standard needs.

The constraint appears when a project needs specific behaviour, portability, fine-grained markup control, performance, integrations, data governance or a lifespan longer than the platform’s decisions.

Speed to launch

Ready-made templates and components reduce the time needed to publish an initial version.

Predictable early costs

The subscription looks simple to evaluate, but functions, growth, applications and migration need to be considered across the full lifecycle.

Platform boundaries

Anything outside the intended components may require compromises, extra code or may not be achievable as designed.

Limited portability

Content and domains may be recoverable, but the website as a system and design rarely moves elsewhere without being rebuilt.

For costs, ownership, SEO and practical criteria, also read Wix, DIY or a professional website?.

Mobile and responsive design: the fixed-size page disappears

In 2010, Ethan Marcotte gave a name to an approach built on fluid grids, flexible images and media queries. The website had to adapt to context rather than impose its own canvas.

01Prioritised content
02Fluid layout
03Device-appropriate interaction
04Performance on real networks

Responsive does not mean “shrink the desktop”: it means designing hierarchies and behaviours that remain useful under different conditions.

Frameworks, APIs, headless and cloud: more power, more layers to govern

The modern Web can distribute interface, content, data, authentication and functions across separate systems. That is remarkable when the problem requires it—and needless debt when it only follows a trend.

Components and design systems

Reuse and consistency improve when components have clear contracts, controlled variants and defined responsibilities.

Client or server rendering

Every choice changes loading time, indexing, resilience and complexity. There is no one correct model for every website.

APIs and services

Separating systems enables integration and scaling, but multiplies failure points, dependencies and monitoring.

Toolchains and maintenance

Builds, packages, versions and vulnerabilities can become more complex than the content they are meant to serve.

Proportionate architecture

Maturity is not measured by technology count, but by the ability to justify every layer and remove anything that does not create value.

AI: producing code is faster, verifying the product matters more

Models and agents can now propose layouts, write components, translate content, create tests and connect tools. The cost of a first draft falls; responsibility for the decision remains.

A new acceleration

AI multiplies capability and defects

With a clear goal, strong context and controls, it accelerates research, prototyping, implementation and verification. Without them, it rapidly produces plausible, inconsistent or unnecessary code.

An output that “looks like a website” does not prove correct routing, security, accessibility, SEO, privacy, performance, structured data, integrations or maintenance.

Generation

Drafts, variants and repetitive work take less time, freeing resources for analysis and control.

Context

Project rules, canonical sources and architecture determine whether AI produces something coherent or one more exception.

Verification

Linting, tests, real browsers, audits and human review turn a probabilistic proposal into a reliable release.

Responsibility

The publisher remains accountable for the outcome. AI is an operational tool, not an entity to which quality, law or business decisions can be delegated.

The paradox: better tools, often worse websites

It has never been easier to put something online. That is precisely why it is easy to confuse presence with a digital product capable of doing useful work.

Excess code

Generic themes, libraries and components load functions the page never uses and someone must still update.

Delegated performance

Automated optimisation tries to compensate for heavy architecture instead of removing the cause of the weight.

Cosmetic SEO

A plugin fills fields, but it does not create information structure, intent, experience, authority or original content.

Security by accumulation

Adding protection extensions does not remove obsolete dependencies, bad configuration or absent update processes.

Accessibility as a widget

A preferences panel can help some people, but it does not repair markup, keyboard use, focus, text alternatives and processes.

Design without an objective

Effects, animation and sections fill space even when they slow understanding and weaken conversion.

Online presence is not the outcome

The outcome is a website that gets found, understood, used, maintained and connected to company processes. Everything else is material, not value.

Why custom code still matters

Not because it is handcrafted in a romantic sense, but because it makes it possible to decide exactly what enters the product, how it works and how it is verified.

01

Performance

Assets, requests, fonts, scripts and rendering are sized for real content instead of inheriting a general-purpose theme.

02

Security

A smaller surface and selected dependencies reduce the points that need updating, monitoring and defence.

03

SEO and GEO

Semantic HTML, URLs, metadata, structured data and server-side content can follow the project’s information model.

04

Accessibility

Keyboard use, focus, accessible names, contrast and reduced motion are designed into components rather than painted on at the end.

05

Ownership and portability

Code, content and data do not depend on the visual editor or commercial plan of a single platform.

06

Evolution

New functions enter the existing architecture through shared rules instead of turning every need into an isolated plugin.

Read more about performance, security and preparing a website for AI agents.

Builder, CMS or custom website: the right choice depends on the cost of being wrong

Budget and speed matter, but they need to be compared with longevity, differentiation, integrations, risk and the value of the digital channel.

Approach	When it makes sense	Main limitation	Control
Builder / no-code	Prototype, short-lived initiative, standard need and minimal initial budget.	Platform boundaries, portability and growth.	Low–medium
CMS	Editorial autonomy, a function ecosystem and complex publishing workflows.	Maintenance, extensions, variable quality and technical surface.	Medium–high
Custom website	Brand, performance, security, SEO/GEO, integrations and longevity are strategic.	Requires analysis, expertise and a real initial investment.	Maximum

No technology rescues the wrong project

A simple solution can be perfect for a simple goal. When the website must build trust, leads or sales over time, initial savings need to be compared with limitations, rework and lost opportunity.

The GLP method today: over thirty years of evolution without the accumulated weight

I use modern tools, including AI, within a proprietary CORE and a verifiable process. Hand-written code provides control; the method decides how to use it.

01
Objectives and scope
Before writing code, I define audience, actions, content, requirements, constraints, languages, integrations and responsibilities.
02
Semantic architecture
URLs, navigation, headings, entities, internal links and structured data are designed as one system that people, search engines and AI can read.
03
Essential code
Every dependency must justify its cost. Server-side HTML, CSS and JavaScript remain proportionate to actual functions.
04
Baseline accessibility
Semantic structure, keyboard use, focus, labelled forms, reduced motion and accessibility preferences are built into the CORE.
05
Security and privacy
Inputs, headers, permissions, dependencies, tracking and third parties are reduced and configured for the real scope.
06
Technical SEO and GEO
Canonicals, hreflang where required, sitemaps, metadata, schema and indexable content are integrated into the structure rather than added at the end.
07
Testing and quality
Linting, targeted tests, routing checks, responsive QA and real browsers precede release. Live Lighthouse checks target 100, with an internal minimum of 98 in every category.
08
Governed evolution
Git, selective deployment, cache, monitoring and maintenance keep every change traceable, limited and verifiable.

Explore the available services and packages or view completed projects.

Primary sources and verified documentation

The timeline combines my professional experience with W3C, Adobe and official documentation. The dates describe technical milestones, not hard boundaries: Web eras overlapped.

W3C — History of the World Wide Web
The invention of the Web, first browser and server, foundation of W3C and major milestones in the open platform.

Open source
W3C Wiki — The history of the Web
CERN, Mosaic, Netscape, Internet Explorer, the browser wars and the Web standards movement.

Open source
Adobe — Slicing web pages
The documented workflow for dividing a design into images and reassembling it through HTML and CSS.

Open source
MDN — HTML table basics
Why tables were historically used for layout and why they create accessibility, maintenance and adaptation problems.

Open source
W3C — A brief history of CSS
From the first proposals in 1994 to the CSS1 Recommendation in December 1996.

Open source
MDN — JavaScript
Its origin at Netscape in 1995 and the beginning of ECMA standardisation in 1996.

Open source
PHP — History of PHP
Creation in 1994, source release in 1995 and evolution into dynamic database-backed applications.

Open source
Adobe — Flash Player end of life
End of support on 31 December 2020 and the transition to open standards including HTML5, WebGL and WebAssembly.

Open source
WordPress — Project history
Its birth in 2003 and the evolution of themes, plugins, static pages and the publishing platform.

Open source
Joomla — Twenty years of the project
Its origin in 2005 and the development of the open-source community and CMS ecosystem.

Open source
Wix — Company history
From its founding in 2006 through the Flash editor, HTML5, ADI, visual development and Wix Studio.

Open source
A List Apart — Responsive Web Design
Ethan Marcotte’s 2010 article defining fluid grids, flexible images and media queries as one approach.

Open source

Sources checked on 29 July 2026. Products, versions and documentation continue to evolve; the guide distinguishes documented facts from my professional experience, which began in 1995.

Frequently asked questions

Direct answers that separate technology, method and marketing when deciding how to build a website.

Is a hand-coded website always better?

No. Confused hand-written code can be worse than a good CMS. The advantage appears when custom development is guided by architecture, standards, testing and maintenance and uses control to reduce compromises.

Why were tables used for layout in the 1990s?

Browsers offered few consistent layout capabilities and CSS had only just begun. Tables could lock images and spaces into place, but mixed structure and presentation.

Was Flash entirely bad?

No. It enabled advanced experiences and trained a generation of designers and developers. Its strategic limitation was enclosing content and interaction in a proprietary runtime.

Is WordPress a bad choice?

Not universally. It can suit publishing processes and ecosystems that genuinely use its advantages. It is disproportionate when themes, plugins and maintenance are inherited merely to produce a few specific pages.

Is Wix suitable for a professional business?

It can be enough for simple, standard objectives. Consider it carefully when differentiation, portability, performance, integrations and lifecycle control matter.

Will AI replace website developers?

It reduces the time required for many operational tasks and changes the profession. It does not remove analysis, responsibility, verification, security, accessibility, content strategy or architectural governance.

Does a modern website need a JavaScript framework?

No. It needs one when interaction, state and scale justify it. For many content websites, server-side HTML and targeted JavaScript are simpler, faster and more resilient.

What does “custom website” really mean?

Architecture, components, content and integrations are designed for the actual scope. It does not mean pointlessly rewriting standards, cryptography or mature libraries.

Why do fewer dependencies improve security?

Every dependency adds code, updates and possible vulnerabilities. Reducing them does not make a site invulnerable, but narrows the surface that must be understood and maintained.

Is a CMS easier for clients to update?

Often yes for content, if the interface and roles are designed well. Editorial updates must be distinguished from technical maintenance of the core, themes, plugins, backups and compatibility.

How do you measure website quality?

Through objectives and verification: accessibility, performance, stability, security, indexing, structured data, user journeys, conversions and maintainability. No single score is enough.

Why does the GLP method start with essential code?

Anything that does not enter the project cannot slow it down, break, require updates or expand its risk surface. Functions are added when they have a verifiable use.