Comparsion to svelte-maplibre

[MRocholl]

Hello!
Thank you for contributing another awesome library for maplibre to the svekosystem.
I see that you took inspiration from the existing svelte-maplibre library.
I'm trying to decide with which library to go as of now. I'm curious as to why you started this new project.
Is there some specific pain this library solves better (or differently)?
Thank you for you hard work.
Best

[ciscorn]

Thank you for your important question! Here's a detailed explanation of why we started this project and how we address specific considerations differently:

The primary motivation was to redesign the API with Svelte 5 in mind. While we certainly considered direct collaboration with the developers of svelte-maplibre, it seemed difficult for us, given the disruptive changes required for such a redesign.

Additionally, as active MapLibre users, we have valued staying close to MapLibre's core API and ensuring that its powerful features remain accessible without opinionated abstractions.

1. Avoid introducing unnecessary abstractions (Stay true to MapLibre's API)

• Other libraries, like visgl/react-maplibre and svelte-maplibre tend to introduce their own abstractions:
  • In visgl/react-maplibre: interactiveLayerIds, and others.
  • In svelte-maplibre: <MarkerLayer>, manageHoverState, hoverCursor, etc.
• In contrast, our library focuses on making MapLibre’s native concepts declarative and reactive, including:
  • <FeatureState> (Map.setFeatureState)
  • <QuerySourceFeatures> (Map.querySourceFeatures) and <QueryRenderedFeatures> (Map.queryRenderedFeatures)
• We believe this approach provides the following benefits:
  • Easier knowledge transfer between vanilla MapLibre GL JS and wrapping libraries
  • Simplicity and flexibility
  • Future-proof design

2. Attention to fundamental behaviors

• Current svelte-maplibre reconstructs all user layers when switching base styles, causing inefficiencies and visual flickering. This library ensures that user styles remain intact when the base style changes.
• In (bare) MapLibre GL JS, performing style-related actions while other styles are still loading leads to fatal errors. This library ensures that style application is fully complete before performing additional operations.

3. Re-designed with Svelte 5 in mind from the beginning

While svelte-maplibre is also working to adapt to Svelte 5, our library has been designed with Svelte 5 in mind from the very beginning. For example:

• Thanks to Svelte 5, we can provide comprehensive event handling without excessive event subscriptions to MapLibre's event system.
• With Svelte 5, we can directly use MapLibre's type definitions to write a cleaner, more maintainable code. This also enables automatic documentation generation. These factors will contribute to the library's long-term sustainability.