[_benton]

I agree with everything in the post but I still like using Svelte. We've adopted our own Store class and decorators which eliminates some of the issues in the post.

    class Wrapper extends Store {
        @state() accessor dom: HTMLElement;
        constructor(el: HTMLElement) { this.dom = el; }
    }

The advantages here are that a) we don't need the .svelte.ts postfix and b) @state() makes TS support flawless with runes. And since we only use classes for state, most of the other objections in the post are mitigated. On the bindable issue, we simply just don't use that feature - one way dataflow ftw! :)

I'm not saying Svelte 5 is flawless at all, but I think we found an approach that minimizes the downsides. The upside is really good performance and a metaframework that makes the most sense out of all the current options.

[braebo]

Oh wow, so this still works even though Svelte doesn't support TypeScript features that aren't just type annotations (like decorators)? Is that because you're outside of `svelte.ts` files so the compiler never touches them?

[_benton]

Yeah it works fine with the latest sveltekit. You do need to set { esbuild: target: "es2022" } in the vite config to enable JS decorators but that isn't specific to svelte. These aren't TS decorators, they're ecmascript decorators (https://github.com/tc39/proposal-decorators) which are at stage 3 and being adopted by JS runtimes.

Under the hood the class is just creating a hidden property with $state({}) and the accessors are reading/writing to that property. Since $state() creates a deeply reactive object it acts the same as marking individual fields with $state().