Thoughts on Svelte

In VS Code I turn on seeing short directories in the tabs, which prevents file confusion. Beyond that it's been a joy to use and pretty easy to get going with. Any confusion or learning comes from not doing next.js first and having to learn about which things happen where in terms of client and server. It's eye opening though and it isn't forced learning.

I give Sveltekit a "you should certainly consider it" vote.

    Rip out {#await ...} and put it in the  logic, then use local variables when rendering.

The reason this is huge is because 90% of my coding is not Svelte. Usually I'm working on app logic, so I might go weeks or occasionally months without touching any UI code. With Vue I used to dread making UI changes, because I always wound up needing to re-learn which properties I needed to put in which return value to which callback (or somesuch, I don't remember the details). I'm sure it's very intuitive if one uses it every day, but it never was for me after a six week gap.

In contrast with Svelte I feel comfortable doing UI work after a long hiatus, even with nontrivially reactive bits, because apart from the templating it's basically just plain JS (or looks like it). It took a bit of bother initially architecting stuff, but I don't think I've checked its docs since I first switched to it.

That said, the big tradeoff is that Svelte's reactivity is quite magical. Personally this doesn't bother me, because as a JS main I find it easy to intuit what Svelte must be doing behind the scenes in order to work the way it does. But if you're an occasional JS user you might hate Svelte's magicalness for the same reason I disliked Vue - e.g. you might keep needing to re-learn when to use $: statements, etc.

    export type PromiseState =
        | { status: 'loading'; value?: undefined; error?: undefined }
        | { status: 'resolved'; value: T; error?: undefined }
        | { status: 'rejected'; value?: undefined; error: Error };
    
    export function fromPromise(promise: Promise): Readable> {
        return readable>({ status: 'loading' }, (set) => {
            void promise
                .then((value) => set({ status: 'resolved', value }))
                .catch((error) => set({ status: 'rejected', error }));
        });
    }

> In the end I found it was difficult to determine reliably when to reach for the $ label. I'd use it in one scenario and it seemed to work like I expect, then throw it at another scenario and it didn't work like I expect.

Yep. There's a bunch of different syntaxes and I can't find a documentation page that lists all of them. I use it, but I don't have confidence to always know when it's appropriate.

> Rip out {#await ...} and put it in the logic, then use local variables when rendering.

Yep. Handling promises isn't something to be done in the HTML. HTML should deal with values.

I think even given these Svelte is still the obvious choice for new apps. Particularly the cleaner syntax, less code, batteries-included handling of CSS, and stores. But the two points above would be great to improve for future versions.