Comment by __jonas | Hacker News Reader

Comment by __jonas | Hacker News Reader

Parent Full thread

I 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.

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).

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

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.

Yeah I suppose it's a tradeoff. I have had an excellent experience when not hydrating components at all, and I like their approach significantly more than other SSGs overall. My worry is just the massive scope of supporting integrations with all those frameworks AND its own .astro language / syntax AND server side rendering in addition to static generation.

To be fair, vite does a lot of the heavy lifting when it comes to supporting extra frameworks. If you look at the code required for astro to integrate with a new technology you'll see it's relatively straightforward.

For example, here's all the code in the svelte integration: https://github.com/withastro/astro/tree/main/packages/integr...

Wow. Good callout.

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.

No, not in particular, I just like Svelte's compilation-based approach, but Alpine definitely looks nice.

When the client side interactivity is very contained and small in scope I also quite like just using plain JavaScript without a framework.

Sorry we haven't fixed this issue sooner. In this case it's a complicated CSS issue, but nevertheless I've got a fix I'm working on here:

https://github.com/withastro/astro/pull/15227

Wow! That's a pretty impressive turnaround time from my comment to a PR, thanks for your work. I'll be happy to include this in my projects.

I have a preview release ready, if you scroll down you'll see the instructions. If you're able to try it out and leave a comment on whether it fixes your issue it'd be a big help.

I used it just with web components and pure html/js. Honestly don't even have a need for any framework with it, it's a great ssg like that already.

Interesting. Do you just build web components instead of React/etc, and add the client:load and Astro gives you the static (fast) initial page load, and lazy loading of web components?

Reply on news.ycombinator.com