Retrospective - building a web app with Leaflet as foundation

02 Jul 2014

I’ve spent the last month or so doing a complete rewrite of the route planner for bikes in western Sweden frontend. The new version uses Leaflet heavily, and has been developed with a mobile first as methodology. Large parts of the actual route planning aspects are managed by my own Leaflet plugin Leaflet Routing Machine (abbreviated LRM below).

Some highlights of the functionality: real time updates of available rental bikes near your starting point, as well as free bike stands at your destination (fed by open data from the city of Gothenburg), drag-and-drop for destination markers (drag them from the sidebar) and an elevation graph.

Photo by Nic Taylor - licensed under Creative Commons by-nc-nd

Short summary: I wish work was always like this. First, the project had no or very few legacy requirements to consider, since we were rewriting from scratch. We got to choose all the tools ourselves: git, Sublime Text and that’s just about it (while everyone else at the company used TFS and Visual Studio - lol). We did not touch the backend parts, but the services the frontend relies on were few and quite easy to work with already. Second, both the customer and the project manager were very positive towards switching from OpenLayers 2, which the old site used, to Leaflet. Third, and probably most important, this proved to be a great opportunity to test LRM both in a real application, as well as adapting it to another backend than OSRM, which it has builtin support for. As a bonus, I live in Gothenburg and cycle as much as I can, so this will be an app that I can and will dog food.

Approach

Even though it wasn’t decided when the project started, it quickly became pretty obvious that Leaflet Routing Machine would be a corner stone of the new app: a lot of the things our app was required to do was already in LRM, and given that we had just about a month to finish the project, any shortcut was welcome. The first days were spent hacking together a rough version with LRM as the base and just swapping out OSRM as its backend and use western Sweden’s Västtrafik’s travel planner, HAFAS from HaCon - believe it or not, Västtrafik’s route planner for public transport can also do route planning for bikes.

After this test, it became natural to build the app more or less as an extension to LRM, adopting mostly the same coding standard, and relying on the same libraries - which means we tried to depend only on Leaflet, LRM and other Leaflet plugins. We didn’t follow through entirely on that concept, and we actually use jQuery in some places to make the code somewhat easier for future maintainers who might not be familiar with Leaflet, and also to keep code easy to read for some places where we deal with legacy browsers like IE 8 and 9.

I also pushed for using Browserify initially, but it was voted down since it isn’t used in the rest of the trafiken.nu site, it doesn’t fit nicely with the current Visual Studio/TFS environment, and is less likely to be known by future maintainers. A bit of a shame, but I can sort of agree with these arguments, although it also means we currently have no solution for bundling and minifying our scripts.

Photo by Ola Lindberg - licensed under Creative Commons by-nc-sa

Use the plugins, all of them

It’s hard to overstate how much the Leaflet plugin ecosystem helped us in this project - delivering a full-featured, modern map application with mobile support in a couple of hundred hours wouldn’t have been possible without them. Here’s a list of the plugins we’ve used:

• Leaflet Routing Machine - as already mentioned, the plugin the routing UI is built around
• Proj4Leaflet - used for projection support, since trafiken.nu’s maps use SWEREF99 TM projection
• Leaflet.markercluster - some of the map layers contain a lot of markers in a limited area, and this clustering plugin is really nice to work with; the customer was impressed and very happy with the result
• Leaflet.label - for putting labels on some of the markers
• Leaflet.Snap and Leaflet.GeometryUtil - to make it easier to drag markers onto some locations, especially important on mobile where it’s can be hard to place things with precision
• Leaflet.groupedlayercontrol - used since it fits features planned for the future

Why not more open?

So, we built a nice app using all this awesome open source — why isn’t the app itself open source? Good question — while writing this post, I realized I don’t know any good reason why the planner itself couldn’t be open. It could serve as a good example of how to build cool stuff with Leaflet, as well as a way to get new ideas or even bug fixes in from other people than the maintainers. I know I would be interested in contributing. Since this is a publicly funded project, paid by our taxes, I can’t see a good reason the source must remain closed.

My guess is that no one really considered the option, and possibly that it’s hard to see the benefits if you’re not already into open source.

On a more positive note, I managed to submit a few pull requests while doing the app, and LRM got tonnes of fixes and new features from this, that will hopefully benefit some other project in the future, like the other plugins did to ours.