What is the motivation behind featuresets? understanding tradeoffs

[tibotiber]

This question is a bit of a follow up to my feature request: #13592.

Let me start by stating I find featuresets very elegant and developer friendly. I can imagine a ton of use-cases becoming easier to implement because style creators have made them part of the style's design. Like I said in the other issue:

The new Featureset concept is pretty clean as a way to curate an API for imported styles. But of course, it comes with the tradeoff that developers can't just mess with whatever they want anymore, and so it limits the things we can build.

I wanted to open this question to try and understand the choices made around featuresets. In particular, why is it now the only way to interact with imported styles? Would it have been better to make it an additional layer for extension, instead of a replacement? Because we now have to open feature requests for thing we could do ourselves before Standard.

I am very much open here by the way, it is not a complain. I'm curious if there is a cost to supporting a full access to the layers like there was before? Maybe it makes it harder to improve core features implementation because it could cause breaking changes? I'd love to understand the choices that were made better, and I think it would allow other devs like me to accept the tradeoffs more easily.

Thank you for any attention this may get.
✌️

[tibotiber]

Maybe an idea would be to support an "eject layer" where developers can at their risk take full control of a layer?

[underoot]

Hey, @tibotiber! Thank you for your question, and we are happy to hear that you find the featuresets practical

Maybe it makes it harder to improve core features implementation because it could cause breaking changes?

Yes, it's the most important aspect that prevents us from providing such a "direct API" in the current architecture. Your feedback is still valuable and helps us understand the real-world limitations of the current solution. Thank you!

[mourner]

@tibotiber featuresets are a part of what we internally call "the evolving basemap" — a default style that constantly gets updates like visual, data and performance improvements (and even new rendering features) without a risk of breaking user's apps. Without featuresets, it would be impossible — even minor changes to the style could break something in thousands of already deployed apps, unless the internals are encapsulated and not accessible as a public API.

It's a tradeoff — either you use the latest and greatest style that constantly updates, but its customization options are carefully curated (via featuresets, config options, etc.), or you use a simpler fixed style like Streets-v12 that never changes and is fully customizable in a very granular way, but lacks a lot of great features and high fidelity Mapbox has been perfecting over the last years.

[tibotiber]

Thanks both for the thoughtful reply. That's pretty much as I had imagined, but knowing it is actually the tradeoff that drives the decision is a good thing. I'll obviously have moment when I wish I could dig in the details and implement what I want. But I respect, and admire your design decision. I'm looking forward to seeing the platform evolve with this new approach.

[tibotiber]

By the way, I think this whole change and the why and the API design would make a really interesting blog post 😉.