Leaflet 1.xx vs Openlayers 4.xx Part 1. Source Code
I want to share my experience with the data of JS-mapping frameworks, I hope the materials will help to make a choice in the question: which library to use exactly in your project. In order not to tire, I will break it into several logical parts. Let's start with the main and source code.
I always liked the Openlayers 2 code, it was as academic as possible and written, it was easy enough to understand its code and become a co-author or write a plugin.
The code for version 3 and later is also well written and documented, but there is one “but” - written using the Google Closure Compiler and without using ES6. This is a very interesting thing, for example, the size of the libraries themselves:
It can be seen that Side ompiler compresses the source files by 2+ times more efficiently than the Leaflet mechanism. It also provides a convenient mechanism for using namespaces during development, and not “these are yours” import '../../../../src' in ES6.
')
At this all the advantages of Google Closure end (my subjective opinion). Further some sufferings begin, they are mainly connected with the fact that in assemblies the names of all members of the class except public ones are “optimized” up to 1-2 letters. For example, you need to write a descendant of the class ol.source.Image under your data source, and you can work only with public properties and methods. Reaching out to private members of a class, as well as to abstract classes of parents, will be problematic. There is only one intelligible option - to create your own Openlayers assemblies (OL authors propose to use this particular option), and making plugins “side by side” without getting into the main library will not be very convenient. However, inside the Openlayers assembly there is almost everything you need to create gis, even third-party vector and raster data providers (Esri for example), and the probability of writing something for yourself or searching for a plug-in for most systems is quite small.
Leaflet was originally conceived of a different principle. The library itself has the necessary minimum, for everything else - plugins. The code follows this principle. In the beginning, he was really not very documented, there were no comments at all, then titles appeared in each class, now for all public methods and properties of the class there are exemplary descriptions and examples of use. The code is written using ES6 (while only a modular system is used). Accordingly, it is as convenient as possible to create your own Leaflet assemblies, and write extensions for it, the authors recommend the latter.
In the article I wanted to show a simple example of finishing one and the second framework using the example of creating a tile layer with a non-standard tile grid, the starting point of the tiles is not in the upper left corner, but in the middle of the grid (yes, this happens). For Leaflet, the plugin would look something like this:
But then I suddenly realized that for a tile source (ol.source.XYZ) in Openlayers there is a property of type ol.tilegrid.TileGrid, in which, in turn, there is an origin property — the very coordinates of the center of the grid. In short, Openlayers has it all, and wouldn't even have to code.
So, if to evaluate from the point of view of the code, other things being equal, what to choose? If you understand that both in Openlayers and in Leaflet (+ plugins) there is no ready-made functionality you need and you have to roll up your sleeves to write add-ons or even make a custom build, choose Leaflet. It is easier and easier to integrate into your project. If there is enough functionality both there and there, then in the question of choice it is necessary to be guided by other conditions.
In the next article I will discuss the developer community and extensions for these frameworks.
I always liked the Openlayers 2 code, it was as academic as possible and written, it was easy enough to understand its code and become a co-author or write a plugin.
The code for version 3 and later is also well written and documented, but there is one “but” - written using the Google Closure Compiler and without using ES6. This is a very interesting thing, for example, the size of the libraries themselves:
| Framework | Assembly | Source files |
|---|---|---|
| Leaflet 1.0.3 | 144 kb | 410 kb (90 files) |
| Openlayers 4.1.1 | 511 kb | 3.1 MB (300 files) |
It can be seen that Side ompiler compresses the source files by 2+ times more efficiently than the Leaflet mechanism. It also provides a convenient mechanism for using namespaces during development, and not “these are yours” import '../../../../src' in ES6.
')
At this all the advantages of Google Closure end (my subjective opinion). Further some sufferings begin, they are mainly connected with the fact that in assemblies the names of all members of the class except public ones are “optimized” up to 1-2 letters. For example, you need to write a descendant of the class ol.source.Image under your data source, and you can work only with public properties and methods. Reaching out to private members of a class, as well as to abstract classes of parents, will be problematic. There is only one intelligible option - to create your own Openlayers assemblies (OL authors propose to use this particular option), and making plugins “side by side” without getting into the main library will not be very convenient. However, inside the Openlayers assembly there is almost everything you need to create gis, even third-party vector and raster data providers (Esri for example), and the probability of writing something for yourself or searching for a plug-in for most systems is quite small.
Leaflet was originally conceived of a different principle. The library itself has the necessary minimum, for everything else - plugins. The code follows this principle. In the beginning, he was really not very documented, there were no comments at all, then titles appeared in each class, now for all public methods and properties of the class there are exemplary descriptions and examples of use. The code is written using ES6 (while only a modular system is used). Accordingly, it is as convenient as possible to create your own Leaflet assemblies, and write extensions for it, the authors recommend the latter.
In the article I wanted to show a simple example of finishing one and the second framework using the example of creating a tile layer with a non-standard tile grid, the starting point of the tiles is not in the upper left corner, but in the middle of the grid (yes, this happens). For Leaflet, the plugin would look something like this:
export var CenterOriginTileLayer = TileLayer.extend({ getTileUrl: function (coords) { // // URL } }); But then I suddenly realized that for a tile source (ol.source.XYZ) in Openlayers there is a property of type ol.tilegrid.TileGrid, in which, in turn, there is an origin property — the very coordinates of the center of the grid. In short, Openlayers has it all, and wouldn't even have to code.
So, if to evaluate from the point of view of the code, other things being equal, what to choose? If you understand that both in Openlayers and in Leaflet (+ plugins) there is no ready-made functionality you need and you have to roll up your sleeves to write add-ons or even make a custom build, choose Leaflet. It is easier and easier to integrate into your project. If there is enough functionality both there and there, then in the question of choice it is necessary to be guided by other conditions.
In the next article I will discuss the developer community and extensions for these frameworks.
Source: https://habr.com/ru/post/331796/
All Articles