Leaflet: A Map Library Written in a Kyiv Apartment

The Developer Who Did Not Want To Be Famous

In two thousand eleven, a software developer named Vladimir Agafonkin was living in Kyiv, working as a freelance front-end engineer. He was twenty-three years old. He had a side project, the kind of side project that a software developer might work on at night for a few hours, between client work and the rest of life. The side project was a JavaScript library for displaying interactive maps in a web browser. He called it Leaflet.

The project did not start because he had a grand vision. It started because the existing options for putting a map on a web page were unsatisfying. Google Maps required signing up for an API key and accepting a long list of terms. The open-source alternative at the time, called OpenLayers, was capable but heavy. It loaded slowly. It had a steep learning curve. It tried to do everything and felt complicated for the simple case of just showing a map on a web page. Agafonkin wanted something small, fast, and easy.

[calm]

The first public release of Leaflet went up on a Russian-language web programming forum in May of two thousand eleven. The library was about seven thousand lines of JavaScript, which by the standards of the time was unusually small. It had the basic features anyone would need. It could display map tiles from any source. It could zoom and pan smoothly. It could display markers and lines and polygons on top of the map. It could attach popups to features. It could be styled with normal web stylesheets. That was it. There was no three-dimensional view, no vector tiles, no clever optimizations, no enterprise features.

The community response was immediate and unexpected. Within weeks, dozens of websites had switched from OpenLayers or Google Maps to Leaflet. Within months, the project had contributors from around the world. Within a year, Leaflet was the default choice for almost any project that needed to put an interactive map on a web page. Vladimir Agafonkin, who had been quietly making a small library in his apartment, had accidentally created one of the most-used JavaScript libraries in the world.

Why Small Won

The reason Leaflet succeeded, when more capable alternatives already existed, is worth thinking about carefully. The answer is not that Leaflet did anything OpenLayers did not. The answer is that Leaflet refused to do most things OpenLayers did, and that refusal was the key feature.

OpenLayers, at the time, supported every conceivable kind of mapping operation. It had projections, coordinate transformations, vector editing, geographic queries, layer management for hundreds of simultaneous data sources, integration with various standards bodies' specifications. It was a genuine professional tool, used by government agencies and research institutions. The cost of its capability was that the library was large, slow to load, and complicated to learn. A casual developer who just wanted to put a map on a page faced a steep learning curve before they could do anything useful.

[serious]

Leaflet's bet was that most people did not need most of what OpenLayers offered. Most people wanted to show a map, place a few markers on it, and let users pan around. The simple case was the dominant case. By optimizing for the simple case and ignoring the complex ones, Leaflet became dramatically faster, smaller, and easier to learn. The first useful map could be displayed with about four lines of code. The library loaded in a fraction of a second on a slow connection. The application built around the library could focus on the journalism instead of on the mapping.

This is a pattern that recurs throughout software history. The capable, complete tool is often beaten by a smaller, simpler tool that handles the eighty percent case well. The capable tool keeps existing, often as the choice for the twenty percent that needs it. But the simpler tool becomes the default, and the simpler tool's developer ends up shaping the field. Vladimir Agafonkin shaped a generation of web mapping by saying no to features.

How It Actually Works

The basic concept of Leaflet is the same as most web mapping libraries. The earth is divided into a grid of tiles. The browser fetches the tiles it needs to cover the area being shown. The library assembles them into a continuous visual surface. When the user pans or zooms, the library fetches new tiles and discards old ones, smoothly enough that the user does not notice the underlying mechanism.

The tiles themselves are usually raster images. Each tile is a small picture, two-hundred-fifty-six pixels by two-hundred-fifty-six pixels, representing a specific region at a specific zoom level. The earth is divided into one big tile at zoom level zero, four tiles at zoom level one, sixteen at zoom level two, and so on, with each level doubling the resolution. By the time you reach the highest practical zoom levels, you are looking at tiles that represent regions smaller than a city block. The tile server prepares all of these in advance, or generates them on demand, and serves them as static images.

Leaflet is the part that runs in the user's browser. It calculates which tiles are needed for the current view. It requests those tiles from a server. It arranges them on the page. It listens for user input, like mouse drags or pinch gestures, and updates the view accordingly. It manages a small cache of recently used tiles so that panning back over an area you have already seen does not require re-fetching. It does all of this without doing anything else.

The architecture is so simple that a competent developer can read the entire Leaflet source code in an afternoon. This was deliberate. Agafonkin wrote the library to be readable. Comments are clear. Variable names are descriptive. The structure is easy to follow. The library serves as a tutorial for anyone who wants to understand how web mapping works at the lowest level. Many developers have built their first custom mapping experiences by reading Leaflet and modifying small parts of it.

What Leaflet Cannot Do

The cost of simplicity is that Leaflet cannot do some things. The library does not support vector tiles natively, which means it does not handle the kind of dynamic styling that MapLibre offers. The library does not support three-dimensional views or tilting. The library does not handle large numbers of features efficiently, because it renders everything through standard browser elements rather than through a graphics card. The library does not handle high-precision geographic operations, because it makes some approximations that are fine for ninety-nine percent of use cases but wrong for the remaining one.

These limitations matter for some applications. They do not matter for most. For a news article that needs to show readers where a specific event happened, Leaflet is overkill. For a small interactive feature that lets readers click between points on a map, Leaflet is excellent. For a hobby project that maps the streets of your neighborhood, Leaflet is perfect. The library is shaped for these cases. It is not shaped for the cases where MapLibre dominates.

[calm]

The decision tree for which mapping library to use has become, over the years, fairly stable. If you need fast, dynamic, style-driven, three-dimensional, large-feature-count maps, you use MapLibre. If you need a simple, fast-loading, easy-to-understand map with a few features on it, you use Leaflet. The two libraries are not really competitors. They occupy different niches. Both have remained relevant for many years because they have not tried to replace each other.

The Mapbox Connection

There is a chapter in Vladimir Agafonkin's career worth knowing about, because it connects to the larger story of web mapping. In two thousand thirteen, a small company called Mapbox hired him. Mapbox was building commercial mapping infrastructure, and they wanted to control the trajectory of Leaflet, which had become foundational to many web maps. Hiring its primary maintainer was a way of investing in the library while also influencing its direction.

For most of the next decade, Agafonkin worked at Mapbox while continuing to maintain Leaflet. The arrangement was unusual but successful. Leaflet remained free and open source. Mapbox got the goodwill of being seen as a supporter of the open ecosystem. Agafonkin got a salary and the ability to work on the library full time. The relationship was the kind of thing that the open-source ecosystem occasionally produces, where a company benefits from supporting a developer and a developer benefits from being supported by a company, with the open project benefiting from both.

When Mapbox closed its license in two thousand twenty, the arrangement became awkward. Agafonkin left Mapbox shortly afterward. Leaflet continues, maintained by him and a small group of co-maintainers, on a much slower release cycle than before. The library is essentially done. It does what it was designed to do. New features are rare and considered carefully. Bug fixes happen when needed. The library is in maintenance mode in the best sense, which is that it is stable enough that maintenance is what it needs.

What This Has To Do With Working Journalists

For a working journalist, Leaflet is the right answer for most mapping needs in a news article. The simple case is the dominant case for journalism. You have a story. The story happened in a specific place. You want readers to see the place on a map. You want to add a few markers, maybe a polygon, maybe a popup with details. You do not need three-dimensional terrain. You do not need dynamic vector styling. You need a fast, small, reliable map.

[serious]

The pattern is the same every time. You write the article. You decide what features to highlight on the map. You prepare a small data file with the features. You include Leaflet on the page. You write a few lines of code to load the data and display it. The map appears. The reader sees it. The story is told. The whole interaction is fast, accessible, and free.

The unusual thing about this pattern is how durable it has been. Leaflet has been the right answer for this case for over a decade. The pattern has not been disrupted. Newer libraries have appeared. None of them have replaced Leaflet for the simple case, because Leaflet was already the right size for the simple case. Doing the simple case better is not really possible. Doing the simple case differently does not help.

The Quiet Persistence

The thing worth noticing, when you think about Leaflet, is how unusual the situation is. A small library, written by one developer in a Kyiv apartment over a decade ago, is still the default choice for a specific kind of journalism mapping in twenty-twenty-six. The web has changed enormously. Browsers have evolved. Mapping technology has evolved. The library has not really needed to change. It was right when it was written, for the case it was written to solve. The case has not changed. The library has not needed to either.

This is what good infrastructure looks like at small scale. The piece of software solves a specific problem. The problem stays solved. The software keeps working. The developer who wrote it goes on to other things, but the software remains. Decades from now, someone will write a news article that needs a small map, and they will reach for Leaflet, and the library will still be there, still working, still loading fast, still doing exactly what it was designed to do.

The story of Vladimir Agafonkin is the story of a developer who built one good thing and then did not feel the need to build another good thing on top of it. He has worked on other projects since. None of them have approached the influence of Leaflet. The reason is not that he stopped being a good developer. The reason is that good infrastructure often only needs to be built once, and once it is built well, the world does not need a second version. The developer's job is to make the first version durable enough that a second is unnecessary.

A Sketch Of The Wider Trade-off

The lesson, for a journalist deciding which tools to commit to, is that durability is often more important than capability. The most capable tool today might be replaced by something different in five years. The most durable tool today will probably still be there in ten. The most capable tool requires you to keep up with its changes. The most durable tool lets you learn it once and use it forever.

[calm]

Leaflet is a durable tool. It is not the most capable. It is not the most innovative. It is not the trendiest. It is, almost by accident, the most durable. The investment of learning Leaflet in twenty-twenty-six is an investment that will still pay off in twenty-thirty-six. The investment of learning a newer, flashier mapping library might not be. This is a real consideration when deciding what to learn, especially for a journalist who has limited time for technical investments.

The same logic applies to many of the tools that have come up in this series. The tools that have lasted are usually the ones that solved a real problem in a small, focused, durable way. The tools that have not lasted were usually the ones that tried to do everything for everyone. The lesson, repeatedly, is to bet on the small and the focused. The simple library written in an apartment becomes the standard. The complicated platform with the marketing budget becomes obsolete. The world rewards taste and patience and respects durability. Leaflet is one of the cleanest examples in modern software of all three.