Svelte Kit doesn't scale well on large projects #13455

### 1) IDE Our IDEs, which we use, have stopped responding efficiently. It takes about a minute for Svelte LSP to initialize. Our laptops are overheating badly. Autocomplete works very slowly or doesn’t work at all. This affects both the autocomplete in component markup, such as props, and in script tags, where autocomplete has become very unresponsive. For some colleagues, Svelte LSP even stops working because it runs out of RAM. This issue affects VS Code, WebStorm, Nvim, and Zed. … I understand that the issue might not be entirely with Svelte LSP or Svelte itself, but could be rooted elsewhere, such as the fact that the entire JavaScript tooling ecosystem is written in JavaScript and runs on single-threaded Node.js. However, I wanted to highlight that in large projects, the IDE becomes extremely unresponsive, and it would be great if the team supporting the Svelte ecosystem was aware of this. ### 2) Build speed Building the application for production takes 10 minutes, and Svelte-check takes an additional 10 minutes. This is quite slow, and it's hard to find a workaround. Neither esbuild, swc, nor rspack currently have good support for Svelte. As projects grow and evolve, this build time is likely to increase. ### 3) Responsiveness of the development server The cold start for `npm run dev` (Vite) takes 1:30 minutes, while the hot restart takes 1 minute. This is also quite slow, especially when you need to restart the server after changing the configuration. Along with the IDE, my MacBook Pro starts to struggle. … This can lead to discrepancies between server behavior during development and production, which has repeatedly caused bugs. We managed to work around this issue similarly to how SvelteKit handles the dev mode for Vite (SvelteKit Vite dev mode code). However, I dislike such workarounds and would prefer having an API for server customization in both dev and production modes. … ### 5) Runtime perfomance I appreciate that SvelteKit allows you to write API endpoints out of the box (SvelteKit server routes). However, as experience has shown, this approach isn't always the most performant. For a load of 11k RPS, it required around 200 pods just to proxy requests to other backends and render HTML. This is a significant amount of resources for relatively simple tasks. As a result, we decided that the best approach would be to write endpoints directly on the Node.js server, bypassing SvelteKit. ### 6) UI kit Our UI kit isn't the largest, but it contains many icons (about 2,000). Svelte doesn’t currently support compiling libraries to publish as pre-built JavaScript, which means these components are recompiled every time. I’m not sure what can be done about this, but it seems like unnecessary overhead. … Since client-side load functions (`+page.js`) started serializing responses, it has become impossible to mock them effectively. Additionally, SSR in SvelteKit can lead to flaky tests. For example, a Playwright selector might click a button before hydration is complete, causing the test to fail because the event handler hasn’t been attached yet. … Don't have much to say here...there's probably a bit of overhead because those could be generic endpoints while you can write more performant specific endpoints directly in node but i think this is definitely something we should look into. ... To be honest, we can't move to svelte 5 at the moment, the code base is too big. Also, in this case, we would have to freeze development, which we can't afford. But in our microfrontends, into which we are sawing our monolith, there are no problems with Svelte 5 yet … Right now the app’s **dependency graph**, build pipeline, and integration points are carrying *more* load than they were designed for. That's why you see slow LSPs, long builds, dev‑server lag, flaky SSR tests, and even uneven runtime performance. They’re all different faces of the same issue: **the system can’t scale cleanly with its current structure**. … Fix the architecture, and you remove entire **classes** of problems at once — instead of whack‑a‑moling them forever! P.S.: Most of the pain points—IDE lag, build times, testing wrinkles, icon recompilation, and microfrontend hacks—originate in the **broader** JavaScript/TypeScript ecosystem or community plugins.