What’s Svelte’s roadmap on improving tool performance?

[MathiasWP]

Describe the problem

I got the idea of writing this issue after reading https://cpojer.net/posts/fastest-frontend-tooling. There’s no doubt that AI is a massive shift in code writing, and one of the most important ways to ensure that AI writes good code is by using the tools available; formatting, linting, type checking, building etc.

I love Svelte, i’ve used it every day at work since Svelte 3. IMO, Svelte is the perfect FE framework for AI because of how little code is necessary to achieve what you want, and there’s usually only «one way» to do things. The syntax is easy to understand, and it’s difficult to do things wrong. However, I have started to feel certain pain points when developing Svelte with AI when it comes to the feedback loop of the tools available. I’ve added optimizations like only formatting changed files in a branch, only running lint on changed files (which works in most cases), and telling it to use svelte-check only at the latest step.

However, it still feels like there’s a way to go. Tools like svelte-fast-check (really cool, but has some bugs that makes it not usable atm), Rolldown, Biome and the OX tool suite seem like great advancements. However, to me it doesn’t seem like the OX team (are able to?) prioritize Svelte when developing their tools. You can format and lint in the script-tags, but that isn’t enough to be usable IMO. Biome has experimental support, but it’s experimental. And OX seems to maybe be the most likely tool to use with Vite considering they’re from the same company.

I may be wrong here, and i most likely are, but i feel like i haven’t found any signs that performance (down to the millisecond/seconds scale) is going to be prioritized in the near future.

So therefore i’m asking the question: What’s the roadmap for making Svelte building, bundling, linting, formatting etc. as fast as the other alternatives? Large React applications can now be built, linted and formatted in seconds, but Svelte is still on the performance of pre-rust tooling upgrades.

Describe the proposed solution

I’m not sure what the best solution to this problem is, but it feels like this is something that will become more important now that the feedback loop is moving away from the VSCode interface via plugins for humans to read, and moving towards the CLI for machines to read.

I know that tools like Cursor give access to the language server in their AI-panels, but for many workflows using Cursor is not the best option anymore.

Importance

nice to have

[sukeshpabolu]

• It is laughable to see React as stable and performance framework. Don't get me wrong React doesn't even respect standards. Everyone knows the fumble they made about server components.
• I think oxfmt is better than biome.
• Svelte and Kit are moving towards being Isometric First Framework.

[MathiasWP]

• It is laughable to see React as stable and performance framework. Don't get me wrong React doesn't even respect standards. Everyone knows the fumble they made about server components.
• I think oxfmt is better than biome.
• Svelte and Kit are moving towards being Isometric First Framework.

Don't get me wrong, I'm not saying that React is the better framework. I'm purely talking about tooling here, and there's no denying that formatting, linting and building a React framework is faster than Svelte's current state of tooling. Let's keep the discussion to tooling, which is what is being addressed here.

I don't believe that there needs to be a compromise between fast tooling or having a well designed framework. You can definitely have both.

[torrfura]

This issue really resonates. Finding reliable info about Biome or oxfmt in Svelte projects feels like navigating a fog — scattered posts, outdated articles, conflicting comments. I've burned hours across multiple attempts with both tools, only to roll back to ESLint + Prettier every time.

Now with Biome 2.4 I got genuinely close. Combining it with svelte-check --incremental --tsgo dropped our lint + build from ~4min to ~1min, which felt like a breakthrough. But I'm still stuck on something as basic as dangling bracket formatting on multi-line components:

<Component attr="1" ...
>
  Some content
</Component>

That alone makes it a no-go for us right now.

And the frustrating part isn't mainly that the tooling isn't ready — for me it's that there's nowhere to go to understand where things actually stand. A pinned "state of tooling" post or tracked issue for Biome/oxfmt/oxlint compatibility would save so many people from going in circles. Even just knowing the known blockers would help.

[hanneswidrig]

I think it's worth considering that the async/remote function functionality moving out of experimental (Svelte 6 and Kit 3) is the highest priority for Svelte at the moment.

I've tried Oxc and tsgo, every month or so the past year. They're getting closer and closer, but there was always hiccups so I think it's worth having patience in this space.

Once Oxc, TypeScript, Vite, Svelte, and Kit stabilize this year, the tooling can follow.

[Rich-Harris]

Thanks for opening this discussion. The short answer is that there isn't a roadmap; there's a lot of ongoing work that we need to finish before we'll realistically have the bandwidth to prioritise this sort of thing. (Though @dummdidumm did recently make svelte-check significantly faster.)

Which isn't me saying that it's not important; it obviously is. Just setting expectations.

So I'd be interested in having a discussion about what can be done in the meantime. Constraints: we don't have control over projects like Biome and Oxc, and the compiler itself is likely always going to be written in JavaScript (at least the bulk of it).

Some thoughts to get us started:

• the first step is triage: where are the biggest, most noticeable bottlenecks? compiling? typechecking? formatting? which cause the most pain?
• once we have that: where are the opportunities to improve performance? If we crack open the profiler there's probably some low-hanging fruit in the style of Marvin Hagemeister's Speeding up the JavaScript Ecosystem blog posts. Open PRs! That will have the biggest short-term impact on the largest number of people
• more speculatively: can we build our own Rust/Go/whatever-powered replacements for certain tasks? Given that we have very comprehensive tests for e.g. parsing and validating, could an agent build these for us, at least as a proof-of-concept? (Prior art: https://svelte-check-rs.vercel.app/.) I would want us to tread extremely carefully here — it's essential that our tooling is human-understandable and -maintainable, and the performance upgrade would need to be very significant to justify any move away from JavaScript
• in the meantime: help the Biome and Oxc teams, whether by raising issues or contributing tests or opening PRs

[MathiasWP]

Thanks for the explanation of the situation, @Rich-Harris!

In my opinion, the biggest bottlenecks in large codebases are linting and building/bundling. Some of the most important rules - like no-floating-promises - are quite slow and depend on TypeScript’s type system (which is why tsgo is so exciting). Even if tools like OXC support these heavier rules, that doesn’t help much if the linter doesn’t properly understand Svelte’s markup.

I’ve tested several alternatives over time, and they often produce incorrect errors like “this variable is not used” when it’s clearly referenced in the markup; the linter just doesn’t see that usage. Is svelte2tsx fundamentally required to bridge that gap? And if so, could something like that realistically be ported to Rust?

I’m also wondering whether the fact that the Svelte compiler is written in JavaScript could become a bottleneck for high-performance linting tools. Is that something that has been investigated? I know the Svelte compiler itself is quite fast, so I don’t want to make assumptions, I’m just trying to understand where the real constraints are.

It seems like for something like OXC to achieve mass adoption, it would need first-class compatibility with existing JS lint rules and plugins. I’ve noticed that the Svelte linter is described as “an ESLint plugin for Svelte using AST,” which suggests it relies on svelte-eslint-parser to traverse the Svelte AST. Could that architecture be part of what makes it harder for tools like OXC to prioritise first-class support for Svelte?

Sorry for a kind of messy reply here, i'm just scribbling down my thoughts.

But to answer your first question: building and linting are by far the biggest bottlenecks.

Linting can be made fast with incremental linting, but this is not the full solution to "making lint fast" IMO. Also, i know that rolldown is coming, we tested it, and it decreases our build with a minute or so, but i don't know if the remaining 2-3 minutes are because of the Svelte compiler or because we have a lot code. Whatever reason, it's still far away from being in terms of seconds, which i have seen other equally sized codebases in pure Typescript can be built in.

Edit: And a follow up, you're saying that there's probably some low-hanging fruits to improve performance, and that we should open PR's to help improve the performance. Where exactly should we be looking? In the Svelte compiler? Svelte2tsx? Everywhere?

[MathiasWP]

I was running some benchmarks testing out parallisation of compiling with svelte, and i got some quite impressive results! The Svelte compiler is pretty goddamn fast.

Here's the full benchmark summary for your frontend (2292 .svelte files, 10 CPU cores):

Benchmark Results

Raw Build Times (Vite "built in" metric)

Phase	Baseline (main-thread)	Parallel (worker pool)	Delta
SSR build	2m 27s	2m 06s	-14%
Client build	3m 25s	3m 11s	-7%
Combined	~5m 52s	~5m 17s	~10% faster

Key Insights from Instrumentation

• 2292 .svelte files compiled per phase (SSR + client = 4584 total compilations)
• Vite already runs 16 transforms concurrently on the main thread
• Svelte compilation is only ~8-10 seconds of a 2-5 minute build (the rest is other transformations, bundling, chunk rendering, etc.)
• Average per-file compile time: 3-4ms (very fast)
• Worker pool: 4-9 threads, with 500-700+ tasks queued concurrently

Analysis

The ~10% speedup is modest because:

1. Svelte compilation is not the bottleneck - it's only ~3-5% of total build time. The rest is TypeScript/JS transforms, UnoCSS, Sentry, bundling, tree-shaking, etc.
2. Vite already provides concurrency - 16 concurrent transforms means the main thread is already well-utilized
3. Worker overhead is real - each worker loads svelte/compiler (817KB), plus structured clone serialization for source/options/results

[tskimmett]

Thank you for pointing me toward check --incremental --tsgo that cut my check time down by more than 50% 🚀. I also wanted to mention that the OXC team looks to be working on astro/svelte formatting right now: oxc-project/oxc#19715.

I'm pretty much at the point where if there isn't a properly fast tool available to perform some check, then I don't care about it :) (until the tool is available).