Thanks. If that is the common approach in Svelte to third party components, than I learned something.

  > You just make whatever it is you want in HTML and make it reactive 
  > ... instead of spending time mastering the API of some component,

I am not sure if that would be a win. The API of the component is actually a selling point, because the component gets used in many different ways across the application. Possibly under influence of user configuration.

If I were to achieve a reasonable amount of flexibility, I would have to redo the work of that library: create a flexible component from scratch with a good api. That is my concern at least.

So when I see the other frameworks libraries, I get the impression that possibly the target audience differ in needs, like so:

  data-heavy, enterprise systems, business software  => react
  webshop etc, "simple" consumer oriented            => svelte, solidjs etc

Correct me if wrong.

I think the best case for using Svelte or Solid over React is when performance is critical, e.g. in big and/or fast data contexts.

Good point. I don't know how much of the gap remains if one can settle for Preactjs, but Reactjs is not the fastest.

The reason you don't see Svelte versions of common libraries as much as you do for React, is that with Svelte you can just use the vanilla js/html/css version and they work great. React has a hard time using vanilla approaches because the virtual dom and hooks aren't vanilla and don't work like vanilla. React is it's own world and therefore needs to have a React version of everything.

I think I do not completely grok that, maybe I have to experiment with Svelte a bit more. As GP mentioned, in Svelte one does not reach for third party components, so you might be on to something.

Yes, and you will probably get a little better at HTML/JS/CSS if you do not have to spend time learning a third-party component's API. Third-party components can also become unbearable if you have a very clear idea of what you want to archive.