alt Hacker NewsI like the idea behind Astro, I've used it for a couple websites here and there. I'm a bit worried about the complexity brought by Astro supporting all these different frameworks through its adapters, and how stable and maintainable those websites will be in the future.
For instance: I've been using Astro with Svelte to build static sites with some components that require client-side interactivity. I really like that Astro doesn't ship any JS by default and just outputs static HTML, and when I want some page to have an interactive JS component, Svelte is an option that produces a relatively small amount of client JS.
But: Using Svelte with Astro this way for static sites has been broken since August 2025. As soon as you have a conditionally rendered child component in Svelte, Astro fails to bundle the styles for it in the static output of the site, and it does that ONLY in production, which is really devious, you could build a whole site (using astro dev) without knowing and then it breaks when you deploy it.
The issue is here: https://github.com/withastro/astro/issues/14252
I don't want to be complaining about how quickly issues get addressed in an OSS project that I'm not paying for, I don't blame them for not keeping tabs on every framework integration, I just would love to build websites with the latest versions Astro and Svelte, and I unfortunately have the feeling I should have just gone with SvelteKit for a smoother experience.
Replies
I like the concept of making frameworks pluggable with different adapters. In my experience, though, it’s dangerous to hitch your wagon to anything but the top 1 or 2 most popular adapters in a given project like this.
The JavaScript web framework ecosystem has this problem everywhere lately where frameworks try to be everything to everyone and support every use case anyone might want. It’s noble in theory but without dedicated and active maintainers for each combination there’s bound to be something left behind.
My heuristic has been to only use adapters that the core project maintainers appear to favor. The maintainers for sub-project adapters that are introduced later frequently have maintainers that come and go, with long periods where things start breaking and nobody is interested in fixing them.
A fix is coming: https://github.com/withastro/astro/pull/15227
Any reason you didn't use alpine for client side interactivity? When I went down the "use a framework plugin in Astro" route, I found it too jarring and reverted to alpine which I found worked well enough.
I havent had a chance to fully use it in a project yet, but it is one of my favorite projects only tinker with it, I'm glad it will receive funding to keep it going. It is definitely a solid gem of open source since its not married to one single SPA framework.
It's not complaining when said OSS project has taken $10+million in VC funding, at that point it becomes a matter of priorities and by explicitly ignoring a major issue the owners are telling you exactly what they care about (capturing that bag, not helping users).