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]

@MRocholl
Thank you for the important question! Here's a detailed explanation of why we started this project and how it addresses specific considerations differently:

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

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 svelte-maplibre and visgl/react-maplibre, introduce their own abstractions:
  • In svelte-maplibre: <MarkerLayer>, manageHoverState, hoverCursor, etc.
  • In visgl/react-maplibre: interactiveLayerIds, and others.
• In contrast, this library makes MapLibre’s native concepts declarative and reactive, including:
  • <FeatureState> (Map.setFeatureState)
  • <QuerySourceFeatures> (Map.querySourceFeatures)
  • <QueryRenderedFeatures> (Map.queryRenderedFeatures)
• We believe this approach ensures:
  • Simplicity and flexibility
  • Easier knowledge transfer between MapLibre GL JS and this library.
  • A future-proof design

2. Attention to Fundamental Behaviors

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

3. Re-designed with Svelte 5 in Mind from the Beginning

While svelte-maplibre is also working to adapt to Svelte 5, this 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 build a cleaner, more maintainable implementation. This also enables automatic documentation generation. These will contribute to the library's long-term sustainability.