poxi.substack.com
My thoughts on Svelte 5 as a full-time Svelte Developer for 3+ ...
Excerpt
## 1. Super lean stores All my stores are super lean. I keep seeing examples of custom stores like counter: ``` function createCount() { const { subscribe, set, update } = writable(0); return { subscribe, increment: () => update((n) => n + 1), decrement: () => update((n) => n - 1), reset: () => set(0) }; ``` … ## 2: Runes feel complex This is sort of a nothing-take, as it is just a general feeling. The original Svelte syntax, with its stores, reactivity and how I could use it to build stuff took me less than a day to understand. It has been 2 days of Svelte runes now and I still don’t really get it. ## 3: Props Originally I hated Typescript for one silly reason. I hated that in React I had to essentially write the prop name twice, one for the variable name and another for the type. In Svelte 3 I only had to type the prop name once, but in Svelte 5 i might have to type it twice again. Somewhere I saw a suggestion like this: `let myProp = $props<boolean>(true);` which is better, but still I don’t like how complex it *looks* … Harder to read due to verbosity. This might seem like a tiny change, but to me this breaks the game… Everything feels 10x more difficult to read in .svelte files just because of this small little change with $state() Mixing of reactive and non-reactive variables in .svelte files. I believe that mixing these will cause a lot of confusion in .svelte files. Never in my 3+ years of svelte programming have I ever had the desire or need to have a non-reactive variable within a .svelte file (in the top level)
Related Pain Points
Runes reactivity complexity in edge cases
6Svelte's runes-based reactivity system works well for basic use cases but becomes problematic in complex scenarios with multiple reactive dependencies. Developers need to use getters and setters to pass reactive variables into functions, creating unintuitive patterns when combining features like signals with effects and derived state.
Prop declaration verbosity in Svelte 5
4Svelte 5's new prop syntax requires typing prop names multiple times (similar to TypeScript in React), breaking the elegance of Svelte 3 where prop names only had to be typed once. The syntax $props<boolean>(true) is verbose and feels unnecessarily complex.