4 ms·
Having used Svelte on a large project, I found that it did scale reasonably well but that the usual problems did require effort and trade-offs. The two big ones
by gushogg-blake 3y ago
Having used Svelte on a large project, I found that it did scale reasonably well but that the usual problems did require effort and trade-offs. The two big ones for me were:
- Managing file size and complexity in the component-per-file paradigm. Having all logic for a complex component in one file makes it big, e.g. 1,000 lines, but splitting into multiple files introduces a component boundary and consequent state passing/event handling boilerplate.
- With tight coupling between a complex UI and complex domain objects/data structures, it becomes difficult to reason about data flow. There are multiple ways of binding the data to the UI -- props, stores, standard JS variables, and reactive statements -- but all come with trade-offs and none let you develop domain objects that are completely framework-agnostic without introducing repetitive boilerplate.
For certain types of app I actually really like the DX of writing a UI-agnostic app and then layering Svelte on top of it with event handlers. It's repetitive -- you have to manually listen to events from the domain objects and update local variables with assignments -- but it's easy to reason about and seems to scale well. A good middle-ground might be making the app aware of the Svelte store contract, which is also very simple, but I haven't tried this and the store syntax comes with its own idiosyncrasies (you can't do $obj.store, for example, because only the $obj bit is interpreted as a reference to a store).
- woah 3y agoMaybe somebody will write a pre processor to let you break a component into several files lol
- jeremyjh 3y agoI really like the look of the composition API in Vue 3 though I have not used it yet, it gives me hope for addressing some of the issues you mention. I wonder does Svelte have anything comparable?
- gushogg-blake 3y agoFrom a quick look at the "What is Composition API?" question in the FAQ[1], I would say: - Reactivity API - yes, with $: labels - Lifecycle hooks - yes, similar to the ones mentioned - Dependency injection - not sure what it is exactly as I'm not familiar with Vue, but I don't think Svelte has a concept like this [1]: https://vuejs.org/guide/extras/composition-api-faq.html#what-is-composition-api https://vuejs.org/guide/extras/composition-api-faq.html#what...
- preommr 3y ago> - Dependency injection - not sure what it is exactly as I'm not familiar with Vue, but I don't think Svelte has a concept like this It's poorly named (holdover from earlier version of vue when svelte didnt exist and react didn't have contexts), but it's basically React/Svelte context API for passing data to children further down the tree instead of passing them through props or through a separate state management solution (e.g. vuex/redux). There's some nuance, but roughly: - getContext = provide - setContext = inject
- richeyryan 3y agoPerhaps this falls into the repetitive boilerplate category you referred to, but if you want framework-agnostic domain objects that still work well with Svelte, create your own using the observer pattern. Create an object with a subscribe method and whatever other methods make sense for updating its state. Svelte will treat it like one of its stores, and it will work with the $ syntax. It can be used with React via its `useSyncExternalStore` hook. It can be used with SolidJS via its `from` utility. If you don't want to handle the set-up boilerplate, you could use another library like Effector or RxJS, but of course, that means another dependency. There is a gradual move to make something like this a part of the platform[1], but who knows when or if it will land. [1] https://github.com/domfarolino/observable https://github.com/domfarolino/observable