Currently we're using Deck.gl as our primary API for mapping and visualization. Under the hood Deck.gl is a MapboxGL map with a WebGL canvas on top. It has some distinct advantages around drawing custom visualizations on top of the map. The tradeoff is that it doesn't allow us to interface with Mapbox directly*, so more typical "GIS" tasks like adding a layer to the map can take considerably more effort. There's more on that in this comment from issue #39.
(*Technically there's a pass-through to access the Mapbox instance from Deck, but because the Deck canvas sits on top of Mapbox it generally obscures anything we would be doing with the map, again like adding a new layer or labels that float on top of our polygons.)
One other thing to note in terms of performance is that Mapbox and Deck both use WebGL for their graphics engine, which means that they should equally performant when it comes to rendering map data. Deck just seems to include more support for visualizing larger datasets (especially discrete events and flows) in unconventional ways, for example this isochronic flow map.
This issue is a suggestion to essentially invert the way we're using Mapbox and Deck, so that Mapbox would be the core of how we're rendering map data and Deck could be brought in optionally on top when we have a need for more custom visualizations. (This may already be a requirement with the cartogram, but outside of that I don't believe we're doing anything that couldn't be delegated to Mapbox.) There's a blog post about different approaches for "interleaving" the two platforms in different ways, including the Mapbox-first solution that's being proposed here.
This would also unblock issues like #30 and make #32 significantly easier.
In terms of a time estimate for doing this work, Deck.gl is very central to how this version of the app was written, so my best guess is it would be about a week's worth of work for one part-time engineer to replace it with Mapbox.
ariisrael
commented
4 years ago 
Currently we're using Deck.gl as our primary API for mapping and visualization. Under the hood Deck.gl is a MapboxGL map with a WebGL canvas on top. It has some distinct advantages around drawing custom visualizations on top of the map. The tradeoff is that it doesn't allow us to interface with Mapbox directly*, so more typical "GIS" tasks like adding a layer to the map can take considerably more effort. There's more on that in this comment from issue #39.
(*Technically there's a pass-through to access the Mapbox instance from Deck, but because the Deck canvas sits on top of Mapbox it generally obscures anything we would be doing with the map, again like adding a new layer or labels that float on top of our polygons.)
One other thing to note in terms of performance is that Mapbox and Deck both use WebGL for their graphics engine, which means that they should equally performant when it comes to rendering map data. Deck just seems to include more support for visualizing larger datasets (especially discrete events and flows) in unconventional ways, for example this isochronic flow map.
This issue is a suggestion to essentially invert the way we're using Mapbox and Deck, so that Mapbox would be the core of how we're rendering map data and Deck could be brought in optionally on top when we have a need for more custom visualizations. (This may already be a requirement with the cartogram, but outside of that I don't believe we're doing anything that couldn't be delegated to Mapbox.) There's a blog post about different approaches for "interleaving" the two platforms in different ways, including the Mapbox-first solution that's being proposed here.
This would also unblock issues like #30 and make #32 significantly easier.
In terms of a time estimate for doing this work, Deck.gl is very central to how this version of the app was written, so my best guess is it would be about a week's worth of work for one part-time engineer to replace it with Mapbox.