Leaflet: Past, Present, Future
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 95 | |
| Author | ||
| License | CC Attribution - NonCommercial - ShareAlike 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this | |
| Identifiers | 10.5446/15548 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language | ||
| Production Place | Nottingham |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
FOSS4G Nottingham 201348 / 95
17
25
29
31
32
34
48
50
56
58
68
69
70
82
89
91
00:00
CASE <Informatik>Multiplication signCellular automatonLine (geometry)Universe (mathematics)GeometryPrincipal idealXMLUML
00:32
Web pageStaff (military)Zoom lensInteractive televisionTesselationUniform boundedness principleExterior algebraLibrary (computing)Vector space
01:12
Google MapsOpen setComa BerenicesEstimationNumber theoryCuboidMappingFood energySign (mathematics)Cache (computing)GeometryForestWorld Wide Web ConsortiumMultiplication signWeb pageRevision controlMappingGeometryMobile WebSoftware developerSoftwareComputer animation
03:23
Software developerGoodness of fitOpen sourceEnterprise architectureMusical ensembleType theoryLecture/Conference
03:47
Field (computer science)Right angleQuicksortProduct (business)Computer animation
04:36
CodeState of matterCodeCASE <Informatik>Game theoryTesselationPresentation of a groupLine (geometry)ImplementationTexture mappingComputer animation
05:29
Open setBuildingWebsiteTesselationWeb serviceDampingLine (geometry)CoroutineRoutingFrustrationOpen sourceBitXMLUML
06:18
MappingFile formatTesselationComplex (psychology)Communications protocolWebsiteComputer animationDrawing
07:03
MappingUltraviolet photoelectron spectroscopyPolygonOpen setLine (geometry)Water vaporCodeSemiconductor memoryProjective planeRight anglePopulation densityNeuroinformatikElectronic program guideSet (mathematics)MereologyDampingBuildingSoftware developerExterior algebraPolygonFigurate numberPoint cloudSubsetComputer animation
09:52
World Wide Web ConsortiumIterationWeb 2.0Texture mappingFlow separationHand fanMultiplication signPower (physics)Field (computer science)Point (geometry)Point cloud
10:51
Metropolitan area networkOpen sourceSoftware bugPatch (Unix)World Wide Web ConsortiumProjective planePoint (geometry)CodeOpen sourceCuboidReverse engineeringCausalityPhysical lawWorld Wide Web ConsortiumSlide ruleInternet service providerTexture mappingDampingProduct (business)Right angleStapeldateiReal numberWeb browserDifferent (Kate Ryan album)Point cloudVideoconferencingLengthSoftware bugParameter (computer programming)Patch (Unix)Metropolitan area networkCore dumpXMLUML
13:34
Multiplication signMoment (mathematics)CodeProjective planeVisualization (computer graphics)Bit
14:46
MaizeVarianceMaxima and minimaConditional-access moduleSpecial unitary groupRaw image formatSoftware development kitIcosahedronExecution unitPort scannerDiscrete element methodWebsiteMultiplication signCASE <Informatik>Presentation of a groupTexture mappingMoment (mathematics)XMLComputer animation
15:13
MappingNavigationMoore's lawMaschinenbau Kiel3 (number)Metropolitan area networkSummierbarkeitMIDILink (knot theory)TowerRaw image formatSpecial unitary groupSimultaneous localization and mappingInformation managementQuantum stateDatabaseReading (process)Game theoryMappingVisualization (computer graphics)Texture mappingStrategy gameWebsiteTotal S.A.Series (mathematics)StatisticsWeb browserComputer animation
15:42
Line (geometry)Coma BerenicesData acquisitionTotal S.A.Multiplication signNumberSystem callPlug-in (computing)Software developer1 (number)Line (geometry)Gene clusterCodeProjective planeElectronic mailing listComputer animation
16:44
Metropolitan area networkCAN busEmulationComa BerenicesMultiplication signRange (statistics)Gene cluster1 (number)Uniform resource locatorImplementationBitPlug-in (computing)Vector spaceDiagramProgram flowchart
17:08
Arc (geometry)MultiplicationMappingGoogolZoom lensVector graphicsPersonal area networkMalwareGroup actionCuboidDrag (physics)Computer-generated imageryKeyboard shortcutNavigationContext awarenessMeasurementControl flowNumberCache (computing)Scale (map)RotationFraction (mathematics)Electronic program guideServer (computing)Virtual realityBinary fileGeometryHand fanInertialsystemVarianceConfiguration spaceCodeComa BerenicesProduct (business)Mobile appPoint (geometry)Chi-squared distributionCAN busCanadian Light SourceSpecial unitary groupPlastikkarteOpen sourceOpen sourceCodeConfiguration spaceComputer programmingMobile WebSoftware developerElectronic mailing listCuboidPlug-in (computing)Block (periodic table)NumberLibrary (computing)Ruby on RailsLine (geometry)Flow separationGroup actionObject (grammar)GoogolProduct (business)Projective planeControl flowPlanningWhiteboardComplex (psychology)Data miningComputing platformOpen setVideo gameExtension (kinesiology)INTEGRALFigurate numberFocus (optics)Arithmetic meanPoint (geometry)Metropolitan area networkPhysical lawInsertion lossBit rateSchmelze <Betrieb>XML
21:15
Polar coordinate systemPhysical lawMaizeStorage area networkCAN busUniform resource nameCodeWordCodeAverageProgrammer (hardware)Open sourceExpressionArithmetic meanSimilarity (geometry)Musical ensembleLattice (order)Network topologyBlogCodeRight angleWhiteboardWordOpen setComputer animation
22:50
Coma BerenicesExecution unitUsabilityPlug-in (computing)Open sourceMusical ensembleComputing platformComputer-assisted translationVector spaceSoftware developerPlug-in (computing)WritingSoftwarePlanningCore dumpSmoothingMusical ensembleRevision controlMoment (mathematics)Web pageWordComplex (psychology)WebsiteAdditionGame controllerLevel (video gaming)UsabilityTournament (medieval)BlogPoint (geometry)Computer animation
Transcript: English(auto-generated)
00:00
Okay, so hello everybody. I'm Vlad America Funkin but you can call me Vlad. I'm a principal architect at Universal Minds. And in the Phosphogy community I'm mostly known for singing a ridiculous song in the first keynote. But I also did one small little thing for the Geo community.
00:20
I created Leaflet. So if you don't know what Leaflet is, please raise your hands. Okay, so not many people, but Leaflet is actually a very simple thing. It was initially created about two and a half years ago. As a very simple, very lightweight, small OpenWares alternative.
00:46
A very simple JavaScript library for interactive maps. And it looks very simple. It's just some tiles, some vector data, some markers and popups and some interactions.
01:01
So you can zoom, pan around. It's everything you're accustomed to, so nothing very new. And the history of it is also very short. So in 2005 Google Maps API started it all in the online maps world.
01:22
In 2006 OpenWares was built already, very long time ago. And in 2009 Google Maps API version 3 was released with really great support from mobile and etc. And only in May 2011 Leaflet was released in public.
01:42
And in a very, very short time, this really simple piece of software gained such a hugely popular presence on the web. So I was struck. So in a very short amount of time something so simple got used by the biggest players in the online world.
02:09
So Flickr, Foursquare, GitHub, OpenStreetMap switched to it on the front page. All the major newspapers like New York Times, Washington Post, The Guardian.
02:22
All the most innovative geo companies like Mapbox and CartoDB use it. And a lot of government agencies. And so even Wikipedia uses it. So at this talk I could just go through Leaflet features, show you some demos.
02:42
But I think it's kind of boring. So instead I think I want to tell you a story. A story of how Leaflet was born and why it was born. And why I think it became so popular. What made it so.
03:00
So the story. I can't say that I'm a very good developer. In fact I'm very lazy. I get easily distracted. And I'm certainly not the smartest person in this room. There are people much smarter than me.
03:21
And in fact I'm better as a rock musician. Seriously I'm a rock musician. I lead a band of seven people and we play beautiful music. But what makes me a very good open source developer. And maybe not very good corporate enterprise type developer. Is that I easily get excited about something. So if I'm excited I get this urge, this rush to just code and build something cool.
03:47
And exactly this happened in April 2008. Five years ago. When I found out that I was going to work for CloudMate. CloudMate was a new startup that based its commercial products on top of OpenStreetMap.
04:09
And I didn't know anything about what we were going to do. And there was about a week left until CloudMate came to Kyiv to hire our development team.
04:23
And I started reading about this company. I was curious. And I found out about OpenStreetMap and I got really really excited. And I couldn't wait until they come in a week and tell us what to do. So I started coding right away. In case someone is bored by the presentations I just included some pictures of kittens.
04:46
You can just look at the pictures and don't listen. Yeah, so I started to code. And I built a really really simple 200 lines of code. Slipping map implementation. So it couldn't do anything.
05:02
You could just load the OpenStreetMap tiles and pan around and zoom. And nothing more. And yeah, I was really excited. And I didn't know anything about existing solutions for OpenWares. And when CloudMate came to Kyiv and I immediately showed them this.
05:23
They said, wow, that's nice. You're going to be our JavaScript API guy. Yeah. And I became their API guy. And they had services built on top of OpenStreetMap data like geocoding, tiles, routing. And they needed a simple JavaScript API for that.
05:43
So that people could put their services to good use on their websites. So they told me, well that's all very cool that you built. But we can't risk building something from scratch. We need to build a full featured API quickly.
06:00
We need it to be major. And there's this very major, very established open source solution. Everyone uses it in the GIS world. It's called OpenWares. And we will just build on top of it. Well, I was a bit frustrated. I said okay.
06:21
And only then I started looking at OpenWares and trying to understand what it is. And before I say something about OpenWares, I need you to understand that I was very naive in experience. I didn't knew anything about this really huge complex world, GIS world with like advanced hundreds of formats and protocols.
06:47
It was very new to me. I didn't knew anything about this. I was thinking that well, maps can be complex. You just have some tiles you pan around. So it can be much harder than that.
07:00
Yeah. And when I saw OpenWares, I just freaked out. I was totally smashed. I mean, I look at OpenWares and it's like one megabyte of JavaScript code. Like 100,000 lines of code. What? And I don't know. I was completely confused.
07:22
And I didn't know what to do. I couldn't figure out what it's all about. And I got really desperate. And then I had this small thought that well, we need some basic API requirements.
07:41
And they're actually not very complex. We need some tiles. No projections. Just Mercator. Some markers. Some pop-ups. Some polylines and polygons. And not much more than that. That's mostly all that users want from an API.
08:00
And I went to this IRC channel. OSMDEV, I think. I don't remember exactly. And I wrote, hey guys. I was thinking of building a really simple, really small OpenWares alternative. And what do you think of that? And in this channel there was a very important guy.
08:24
Very recognized in the GIS community. Very respected developer. And he answered to me like, fuck you. No one wants your alternative. Just use OpenWares.
08:43
And maybe it wasn't as harsh as that. But in my memory I tend to exaggerate. It was five years ago. Yeah. But when someone tells me that I can't do something. That I will fail.
09:00
And I strongly believe in what I want to do. I'm like, challenge accepted. But there was still problem. Cloud Mate wanted me to build their API on top of OpenWares. And I said to them, okay. Initially. And then I discovered OpenWares. So I decided to cheat.
09:21
I had like two weeks left until the deadline. When I needed to present our new Shiny API. And I had a set of requirements for that. And I thought, well I will build everything from scratch. Like I wanted.
09:41
I won't tell Cloud Mate. And then I'll show them and then I will admit. That it's not OpenWares. And we'll see how it goes. So I started coding rigorously. And in several weeks I got a very first basic iteration of what would be later known as Web Maps Lite.
10:04
Anyone remembers that? Oh right. That's awesome. So, yeah. This was very simple API. Very fast. Very quick. It was very really small. Compared to OpenWares like 50 times smaller or 100 times smaller.
10:21
I don't know. And when in two weeks Cloud Mate came to see what I built. They, okay let's see how it goes. They started looking how it interacts and everything. And what's happening? Why is it so fast? How did you make OpenWares so fast?
10:41
What did you do? Yeah. And later I said, well, I have to admit that's not OpenWares. Yeah. I proved my point. And Cloud Mate said, okay well let's go with our custom solution. You were right. We give up. No OpenWares.
11:02
Yeah. So two years later I was still working on the API. But I got sidetracked to different projects across Cloud Mate. And the API was mostly one man effort. And it was closed source so nobody could help me.
11:21
And there were lots of other projects I needed to do. And supporting a map API is quite difficult when there are browsers that are advancing with every day. Getting new features like new bugs as well. And new devices appearing. And it started to become difficult.
11:43
And I didn't felt very well about this. And the last straw was that when some guy that was using web mouse slides. The source was closed and obfuscated.
12:01
And he took this obfuscated code. He reverse engineered it to fix a bug. And then just sent me a patch and said, just upload the patch. I fixed the bug for you. And so at first I thought, wow, what a nice guy. And then it became very sad because I thought that if people go to a great length to help this project, to contribute to it.
12:30
Even reverse engineer the code. Then what if this code was open source? Then there's really a need for people to contribute to it.
12:41
I just need to convince my employer to make it open source. And that's what I did. I wrote a huge letter with 20 items with my arguments why it should be open source. And they thought about it. And they agreed.
13:01
So I won. And yeah. So I came up with a name for it. Leaflet. And web map slides eventually became Leaflet. So initially I wanted to just extract the core of the API without the provider related stuff.
13:25
And release it. But eventually I just rewrote everything from scratch. And released it as Leaflet. And here's a video I put up at two year anniversary, half a year ago. It's a visualization of Git's history of the project.
13:45
And you can see first half of year I worked on it alone. Just putting everything well so that everything looks great. All the code is understandable and readable. Yeah.
14:00
And here's a moment when it gets released. There's one more guy that decided to help me. And then there are other people appearing. You see Tom McBride, Jason Davis, lots of celebrities. Yeah. And it goes better and better with time.
14:20
So if we wait a bit we'll see that. There's a huge crowd of people contributing to the code. And that was amazing. Yeah. So I think let's wait a bit more until another release and another crowd of people contributing.
14:42
Okay. You see a lot of people. Let's not watch it to the end because we have very limited time. Okay. So Leaflet, the present. Now you can, if you see a really awesome map on some huge website. If it's not Google Maps it will probably be Leaflet.
15:05
It's used on, it has amazing uses among the most visited websites in the world. It's used not just for maps but for data visualizations. It has really awesome uses.
15:21
Not even for real maps. This is a map of Skyrim. Who played Skyrim? Yeah. This is a map of World of Warcraft also. Very nice. And this is not even a map. It's an official site of Total War strategy game series. And it's a screenshot browser built with Leaflet.
15:41
Here are some stats on GitHub. So yeah. Three years of development total. Not much lines of code. Like 6,000, about 7,000. It's like 50 times less than OpenWears 2. It has commits from 150 people around the world.
16:05
And that's an amazing number. So many people contributed to Leaflet. It has, it's one of the most popular JavaScript projects on GitHub. With almost 6,000 stars and more than 1,000 forks. It's very actively developed.
16:22
It has about 2,000 closed issues, about 700 closed pull requests. People sending pull requests every time, each day. There's also a huge plugin infrastructure. So official plugin list is 86 plugins.
16:40
Among them are amazing plugins. Some of the best ones do very great things like marker clustering. It's the best clustering of all implementations I saw. I think you saw it many times. The vector editing plugin Leaflet Draw is also really great.
17:01
And now I want to talk a bit about why I think Leaflet became so popular so fast. So everything comes down to simplicity. That's my main principle and what I advocate to others and what I want to inspire with. So initially when I thought what features I would like to see in my library.
17:25
I made a list of all the possible features that could appear there. And I decided no, that's too much. I can't handle that. And instead of focusing on number of features, I will focus on quality of features.
17:44
I will take the bare essentials, the most important features, and make them work perfectly across all devices, mobile platforms, everywhere. So that they are working great, so that they have great design out of the box.
18:00
So that people like it just from the very beginning. And so it depends on third-party plugins for everything else. And you can see there are lots of plugins to do all kinds of things. I was very determined to make the API as simple as possible. So every action that you can do with API is just the smallest amount of code possible.
18:25
I really thought out how to make it really small and really simple. And so that's by creating a map, adding an OpenStreetMap layer, adding a marker, binding a popup to it, and opening the popup is just several lines of code that are just very intuitive and simple.
18:45
There is also a convention of our configuration principle. It was made popular by Ruby on Rails developers. And it means that everything should work great out of the box, without any configuration, without lots of configuration objects.
19:03
You just create a map, and it's working great out of the box. And if you want to do something more, you can. But out of the box, everything works great. And one of the most important principles that made leaflet attract so many contributions,
19:21
and I think this principle is lacking in many open source projects, especially in the GIS industry, is that code shouldn't be just simple outside. I mean the API endpoints and UI interface, it should be simple inside. The code itself should be simple. I think many of you saw this picture.
19:44
Like typical Apple product, typical Google product, and your company's app product. And you can compare the success of the products. So the same thing happens with code. So imagine you wrote a really complex, really smart piece of code.
20:03
It's beautiful, it's genius, and it has all the advanced programming techniques, like metaprogramming, some patterns, design patterns, everything very extensible, configurable. And so you have this very smart code.
20:21
And then someone comes to this code, he really wants to contribute. And when he tries to do that, he sees that the code is so smart and complex that he won't contribute because he thinks that it's too complex, too smart for him. An average developer thinks that, oh, my skills are not as good to contribute,
20:43
and I'll certainly break something because everything is so complex there, and I don't understand how it all works completely, so I won't contribute. And that's a big stumbling block to open source. So we have this open source value that people can contribute to projects.
21:03
But this value is often unreachable because of the complexity, because people can't contribute to a code that's too complex and too smart. So I'm determined to make the code as simple as possible, just straightforward, simple, every average programmer can go to Leaflet source and understand it.
21:25
And that's a great, yeah. And about open source. So GitHub made it possible for open source contributions to happen, for the workflow to be as simple as possible. So now it's as simple as just clicking on a button, edit.
21:43
You click on a button, edit, and you can edit the code, and you can push the button, save, and it will send a pull request. And you can contribute by just clicking several buttons that couldn't be simpler. And now that the workflow is simplified enough, and GitHub became so successfully popular because of that,
22:04
now we need to make the code simpler too. So it's not enough to be just open, we need to be transparent. Yeah, and there's one more principle. It's the poetry of code. I write lyrics for music, and I find many similarities between writing poetry and writing code,
22:27
because writing poetry is writing, expressing deep meaning through very simple words and phrases. And it's very similar in code. If you can express something in simple wording, understandable,
22:41
but that it would have deep meaning, it is great code. Yeah, and as a consequence of this simplicity, the code is very easy to optimize, and so Leaflet is very fast. It's very smooth on all platforms. And I also made sure that this simplicity is reflected in the documentation,
23:05
so that it's really easy to understand. So, a couple of words about the future, finally. So here's the most important moment of the presentation. I'm going to present you the really awesome, amazing features that Leaflet will have in the next version.
23:23
Wait for it. I'm actually determined to remove features in Leaflet more than I want to add them. So I really try hard to make it stay focused, lightweight,
23:41
to stay down to the bare essentials. And everything worked out perfectly for these essential features. And actually, this is not a joke, in the last release I removed a vector editing feature. Not actually removed, I moved it from the core to the Leaflet Draw plugin
24:00
that does all the vector editing and drawing, and it belongs there much better, and the Leaflet core stays small and compact. And everything comes down to simplicity again. So, Leaflet plans for the future. Making things simpler, refactoring for flexibility, improving performance,
24:22
so that it works great on all devices, all the new devices too. Improving usability, so that it's smooth everywhere. And improving plugin infrastructure, so that it's easier for people to write great plugins, quality plugins. And better website, more tutorials. So you can do very advanced, great things with Leaflet,
24:40
but not everyone knows how. So tutorials are needed. And to recap, the final slide, to be really successful at open source, you need to get excited, build cool stuff, you need to believe in yourself, you need to pursue your dreams, you need to push open source, and you need to listen to my band.
25:04
The developer is a rock musician,
25:22
he puts cats on his presentations, and he's now a stand-up comic. Genius. So we've probably just got literally a couple of minutes, maybe one or two questions, perhaps while the speaker is setting up, if anybody has any questions at all. Yeah, I can answer most of the questions outside, because we don't have much time, but several maybe, yeah.
25:43
How do you think about managing dependency between plugin and Leaflet co-version? Do you plan to do something like with Grunt, where you have dependency tree? I don't plan to make it a software controlled dependencies,
26:04
I want to just require plugins that are published on the main page to specify the required version. It will be simpler and easier to manage, because in Leaflet we don't usually need a lot of complex interdependencies,
26:21
so everything is much simpler, we don't need to.