The Weekend That Changed the Internet

There are moments in technology when an improvement to a product becomes something much bigger. A faster processor. A better database. A new programming language. A clever algorithm.And then there are moments when someone takes an existing idea and changes what people believe a computer application can be.

The story of the early Google Maps is one of those moments.

Today, opening Google Maps and dragging a map across the screen feels almost too ordinary to notice. We pinch to zoom, search for a business, watch our location move in real time, switch between satellite imagery and street-level views, calculate routes and receive traffic updates, all without thinking about the enormous amount of software and infrastructure underneath.

But in 2004, the web did not generally behave this way.Web pages were largely documents. You clicked a link, the browser contacted a server, the server generated a response, and the browser replaced the page.

Google Maps helped change that model.

And somewhere in that transition was a remarkable engineering story involving a small team, an experimental approach to JavaScript, and a weekend in which Bret Taylor decided that the existing implementation had to be rewritten.The result would help popularize a new model for building web applications—one in which the browser was no longer merely a viewer for documents, but an active computing environment.

The Web Before the App

To understand why Google Maps was such a big deal, it helps to forget what the modern web looks like.

Today, websites behave much more like software applications.Google Docs behaves like a word processor.Figma behaves like a design application.Gmail behaves like an email client. Google Maps behaves like a geographic information system.But this was not the dominant model of the web in the early 2000s.Most websites were still fundamentally page-oriented.If you submitted a form, the browser sent a request to the server.The server generated a new response.The browser loaded the response.The current page was replaced.

This model worked perfectly well for documents and relatively simple websites. But it became increasingly awkward when developers wanted to create interfaces that behaved like desktop software.

Imagine trying to build a map application using that model.You drag the map.The browser sends a request.The server generates a new page.The browser downloads it.The screen refreshes.You drag again.Repeat.

It works, yes, but it does not feel like an application and Google Maps was about to challenge that experience.

The Birth of Google Maps

The origins of Google Maps actually predate Google.

In early 2003, Danish brothers Lars Eilstrup Rasmussen and Jens Eilstrup Rasmussen founded a company called Where 2 Technologies in Sydney, Australia, together with Stephen Ma and Noel Gordon.The team was working on mapping software with the goal of creating something substantially more interactive than the mapping products of the time.Their early work was not initially a conventional web application. They developed a desktop mapping program that demonstrated an important idea: a map could be manipulated directly rather than treated as a static image.

Google acquired Where 2 Technologies in October 2004, bringing the team into Google.Google also acquired Keyhole, a geospatial visualization company, in October 2004. Keyhole's technology would later become an important part of Google's broader mapping and Earth efforts.

The result was an unusually ambitious project.Google was no longer simply trying to put a map on a webpage.It was trying to make the web browser itself behave like a mapping application.On February 8, 2005, Google officially launched Google Maps.But the most interesting part of the story was what happened underneath the interface.

The Problem With Traditional Web Applications

The original generation of web applications had a fundamental limitation, which is that The server controlled too much of the experience.

A traditional interaction looked something like this:

User action
     ↓
Browser sends HTTP request
     ↓
Server processes request
     ↓
Server generates response
     ↓
Browser receives response
     ↓
Page refreshes

That architecture meant the server often had to participate in every meaningful interaction. For a map, that could become extremely inefficient. Suppose you wanted to move from one part of a city to another.

A traditional implementation might require the browser to request a completely new representation of the map. The result? A visible reload. A delay. A new page. Then another request when the user wanted to move again.

Google's team wanted something fundamentally different.They wanted the browser to remain alive while the data underneath it changed.

The Insight: Treat the Browser Like an Application

The breakthrough was not simply "use JavaScript", because JavaScript already existed. The underlying browser technologies already existed too. What changed was the way developers began combining them. The idea was relatively simple:

Don't reload the entire page when only a small part of the information has changed.

Instead, let JavaScript communicate with the server in the background. The server could return only the data that was necessary. The browser could then update the relevant part of the interface.

Conceptually:

Traditional Web

User
 ↓
Request
 ↓
Server
 ↓
Entire page
 ↓
Browser reload

versus:

Interactive Web

User
 ↓
JavaScript
 ↓
Background request
 ↓
Server
 ↓
Small data response
 ↓
JavaScript updates the page

The distinction is enormous. The browser no longer had to throw away the entire interface just because one piece of information changed. This was the basic philosophy behind what became known as AJAX — Asynchronous JavaScript and XML.

The name itself came later. Jesse James Garrett coined the term "AJAX" in 2005 to describe a collection of techniques that were already being used to create more dynamic web applications. Google Maps became one of the most visible demonstrations of what those techniques could accomplish.

Enter Bret Taylor

One of the people who became deeply involved in this transformation was Bret Taylor. Taylor was working at Google on Google Local, a product that connected local business information with Google Search. The team began experimenting with a much more ambitious mapping experience.

Taylor later explained that the team had started with a map licensed from MapQuest, but quickly became interested in what would happen if the map itself became the center of the experience. And there was an important philosophical shift:

Instead of digitizing the paper map experience, what if they created something that could only exist on a computer?

That distinction matters. A paper map cannot respond when you drag it, cannot calculate a route instantly and cannot dynamically retrieve information from a database.

However, a browser can, so Taylor and the team began pushing the browser toward behaving more like a desktop application. And then they ran into the limits of their own implementation.

The Weekend Rewrite

This is where the famous weekend story begins.

Taylor has described becoming increasingly frustrated with the complexity and performance of the Maps codebase. The elegant prototype had grown increasingly complicated as the team added functionality, browser support and new capabilities. In one account, Taylor describes spending a weekend rewriting the application.

The important detail, however, is that this was not the invention of AJAX by one person over 48 hours.

Taylor has explicitly described Google Maps as a team effort, and has explained that the application was rewritten multiple times as the team discovered new web development techniques. What makes the story remarkable is the engineering decision behind that rewrite. The team began transferring data asynchronously rather than treating every interaction as a traditional page navigation.

And they pushed JavaScript much harder than typical websites of the period.

At one point, the data being sent from the server was effectively JavaScript that the browser could process directly. The format we now know as JSON had not yet been standardized or even given its familiar name. Taylor has recalled that the team used JavaScript-based data transfer because it was efficient for the application, long before JSON became the ubiquitous data interchange format it is today.

This was an important architectural shift since the browser was now becoming a runtime and the web page an application.

From Pages to Applications

Consider what happened when you dragged a map.

In a traditional website, dragging could mean:

Drag
 ↓
Request
 ↓
Reload
 ↓
New page

Google Maps moved toward something closer to:

Drag
 ↓
JavaScript calculates what is needed
 ↓
Background request
 ↓
Retrieve map data
 ↓
Update the relevant portion of the interface

The difference was not merely performance. It changed the interaction model. The user no longer had to think about the web page. They could simply interact with the map. Drag it. Move it. Zoom it. Search it. Explore it. The technology disappeared behind the interface.

That is one of the defining characteristics of great software engineering:

complexity is absorbed by the system so that simplicity can emerge for the user.

Google itself later described the change as moving from "clicking on arrows and waiting" to simply dragging a map and watching it render smoothly and quickly.

Why This Was Revolutionary

It is easy to underestimate Google Maps because the interaction is now completely normal.

But imagine encountering it for the first time in 2005. You open a webpage. There is a map. You put your mouse over it. You drag. And the map moves. Not after a page reload. Not after clicking an arrow. It simply moves.

Today, this interaction is so deeply embedded in our expectations that we barely notice it.

But it represented a new model of web software. The browser could maintain state , JavaScript could control the interface, data could be retrieved asynchronously and only the necessary pieces could change. The server and browser could work together continuously.

The web was beginning to behave less like a collection of documents and more like an operating environment for applications. That was the real significance of Google Maps.

Google Maps Was Not Just a Map

Another important part of the story is that Google Maps did not remain a simple mapping application.

The product evolved rapidly. Google integrated satellite imagery through technology from Keyhole. It expanded mapping data, introduced directions and eventually introduced mobile navigation.

It opened the Google Maps API to developers in 2005, allowing other websites to embed maps and build applications around Google's mapping infrastructure. This was arguably just as important as the interface itself. Google was not merely building a product. It was building a platform.

Developers could combine geographic data with their own datasets.

Real-estate sites could display properties. News organizations could visualize events. Businesses could show locations. Developers could create entirely new applications without having to build a global mapping system themselves.

The map became infrastructure.

The Web 2.0 Effect

This is where the story becomes bigger than Google Maps.

During the mid-2000s, a new generation of websites began appearing that felt fundamentally different from traditional websites. Gmail, Google Suggest, Google Maps and later Facebook and other highly interactive services.

These products were part of a broader transition often described as Web 2.0.

The web was becoming:

• more interactive,
• more asynchronous,
• more stateful,
• more application-like,
• more dependent on JavaScript,
• and increasingly driven by APIs.

Google Maps became one of the most recognizable examples of this transition.

Contemporary technology coverage explicitly identified Google Maps and Google Suggest as examples of web applications that gave users the feeling of using desktop software rather than traditional webpages. And the implications went beyond mapping. The expectation had changed. Users began to expect websites to respond immediately. Clicking should not necessarily mean waiting. Searching should not necessarily mean reloading. Dragging should not necessarily mean submitting a form.

The browser could do more. Much more.

The Architecture We Take for Granted

There is an important lesson here for today's developers.

Modern web applications have taken this concept dramatically further.

Instead of XML, we commonly use JSON. Instead of manually manipulating the DOM, we have frameworks such as React, Vue and Angular. Instead of simple XMLHttpRequest calls, we have fetch(), WebSockets, Server-Sent Events, WebRTC and sophisticated client-side state management.

Instead of a single server returning HTML, we have distributed architectures involving:

• APIs
• CDNs
• edge computing
• serverless functions
• microservices
• databases
• caches
• WebAssembly
• service workers
• machine-learning inference

Yet the underlying principle remains surprisingly familiar:

Do not make the user wait for the entire system to rebuild when only one part needs to change.

That principle can be traced through much of modern application architecture.

And Then Came the Mobile World

Google Maps' story did not stop with the browser.

As smartphones became mainstream, mapping became even more useful. GPS turned the map from something you looked at into something that could understand where you were.

In 2007, Google Maps for Mobile introduced an early version of "My Location," using GPS and other signals to determine a user's approximate position.

In 2009, Google Maps pioneered turn-by-turn mobile navigation. The product was no longer simply answering:

"Where is this place?"

It was answering:

"Where am I?"

Then:

"Where am I going?"

And eventually:

"How should I get there?"

That evolution transformed Maps from a digital map into a real-time interface to the physical world.

From Maps to a Living Model of the World

The modern Google Maps is almost unrecognizable compared with its 2005 predecessor.

It now combines enormous amounts of geographic and business information, satellite imagery, Street View, traffic data, public contributions, navigation data and machine learning.

Google said in 2024 that more than 2 billion people use Google Maps each month, while AI and other systems help generate more than 100 million map updates every day.

Google has also said Maps covers more than 220 countries and territories and provides information about roughly 200 million places.

This is an important distinction.

The original ambition was essentially:

Put the world on a map.

The modern ambition is closer to:

Build a continuously updated digital representation of the real world.

That is a vastly more difficult engineering problem, and it is increasingly an AI problem.

Machine learning is now used to understand imagery, identify roads and buildings, estimate traffic, improve routing, detect fraudulent content and keep geographic information current. Google has described AI as playing a role in Maps for more than a decade.

What Actually Changed That Weekend?

So, did Bret Taylor single-handedly "change the internet" in one weekend?

That makes for a great headline. History is more nuanced. Google Maps was built by a team. The underlying technologies behind AJAX existed before the term was coined. Google Maps itself evolved through many iterations, and the modern web was shaped by countless engineers, researchers and companies.

But the weekend rewrite still represents something important. It represents the moment when an engineer looked at an existing architecture and asked:

What if we stop accepting the limitations of the way things are currently built?

That question is often where major technological shifts begin. Taylor and the Google Maps team did not invent interactive computing. They did something arguably more consequential for the web:

they demonstrated what the browser could become.

The Legacy

The influence of Google Maps can be seen in the architecture of the modern web.

Interactive dashboards, online editors, social media feeds, cloud-based productivity software, real-time collaboration, single-page applications and rich browser-based applications.

Many of these experiences depend on the same fundamental expectation:

the interface should remain alive while data changes underneath it.

In 2005, that expectation was novel. Today, it is standard and perhaps that is the most important measure of technological impact. The greatest innovations eventually become invisible.

Nobody marvels at dragging a map anymore. Nobody thinks twice about a search suggestion appearing while they type. Nobody considers it extraordinary when a webpage updates without reloading. We simply expect it and maybe that expectation is the legacy.

What Happened to Bret Taylor?

The Google Maps story was only the beginning of Taylor's career.

Taylor later co-founded FriendFeed, which was acquired by Facebook, where he became Chief Technology Officer. He subsequently co-founded Quip, a collaborative productivity company that was acquired by Salesforce. At Salesforce, he eventually served as co-CEO alongside Marc Benioff.

He later became chairman of Twitter's board during the period surrounding Elon Musk's acquisition of the company.

Taylor also became a major figure in the AI industry and is currently Chairman of the Board of OpenAI.

But perhaps the most interesting part of his career is not the list of titles but the recurring pattern. Build something. Question the existing assumptions. Make the interface simpler. Push the technology underneath it harder ,and then turn the resulting capability into a platform.

The Bigger Lesson for Engineers

There is a tendency in software engineering to think innovation means inventing something completely new.

Often it does not. Sometimes innovation comes from taking existing technologies and combining them in a way that changes the user's expectations.

AJAX was not entirely new.Neither was JavaScript , HTTP , browsers and certainly not maps .

But putting them together in a way that made a web page behave like an interactive desktop application was transformative.

And that is the lesson I take from the Google Maps story.

Technology does not always change when we invent a new primitive.

Sometimes it changes when someone realizes that the primitives we already have can be used differently. One weekend did not literally rewrite the internet. But one weekend helped demonstrate what the internet could become. And once users experienced that kind of web application, there was no going back.

Sources & Further Reading

• Google — Google Maps' biggest moments over the past 15 years
• Google — How 15 years of mapping the world makes Search better
• Google — Charting the next 15 years of Google Maps
• Google — Google Maps is turning 15!
• Google — New in Maps: Inspiration curated with Gemini, enhanced navigation and more
• Bret Taylor — interviews and discussions on the development of Google Maps and AJAX
• InternetNews — contemporary reporting on AJAX and Google Maps in 2005
• Google Maps API Blog — historical documentation from the original Maps API team

Sources: Wikipedia · Loopex Digital (Google Maps statistics)

Authored by Daniel Chacha Mwita