Agreed. When writing my code editor I started off with a lot of UI-related state and logic in the UI (Svelte) components, things like keeping track of what tabs are open and editor state within the tabs.

Quickly realised there was gonna be a lot of grappling with Svelte as the complexity grew: figuring out what component structure to use for passing data around efficiently and ergonomically, passing events between components, using Svelte stores for global state and figuring out how to update and subscribe to them from non-Svelte code, etc.

Now the Svelte code is a thin wrapper and the app can run headless. I feel like it would genuinely be fairly easy to plug a totally different UI onto it.

Each Svelte component basically stores copies of the state it's interested in, subscribes to events from the objects it's interested in, and calls methods on those objects in response to events. This comes with a bit of extra boilerplate vs. more tightly integrating the UI logic with Svelte but the almost complete lack of cognitive overhead in this part of the code is well worth it.