What Are the Limitations of Using SvelteKit?

The biggest struggle for me has been third-party libraries that expect the `window` object to be available. During SSR, things can silently break, and you end up having to wrap your code with `browser` guards everywhere, which just gets messy. Also, if you're not deploying to Vercel or Netlify, the documentation on the adapter ecosystem gets pretty sparse. I had to dive into the adapter-node source code more times than I'd like. But for standard web apps, working with SvelteKit can be really fast—just be cautious if you know your project will rely heavily on client-side libraries.

There used to be a limitation in Svelte 4 and earlier where you couldn't easily split some functions from .svelte files to .ts files. Thankfully, that's changed with runes! But you still can't build components quite like you would in React, which can be disappointing. I've tried out the Ripple framework too, and while it's new, it seems to have potential if it gains popularity. Overall, SvelteKit is solid now—I just hope they won't change the API again! 😂

SvelteKit generally handles most tasks well, but I still find those edge cases with SSR to be a bit of a pain sometimes.

I've been using SvelteKit for a few projects, and one of the main issues I've faced is with Server-Side Rendering (SSR) getting funky when using certain third-party libraries that expect to run in a browser environment.

Honestly, I haven't run into many limitations. However, I've heard that websocket support can be tricky. Last I checked, there was a push to improve that, so it might be better now.