3 ms·
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 mak
by exceptione 1y ago
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.
- division_by_0 1y agoI 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.
- exceptione 1y agoGood point. I don't know how much of the gap remains if one can settle for Preactjs, but Reactjs is not the fastest.
- Sammi 1y agoThe 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.
- exceptione 1y agoI 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.