[solardev]

There is actually a fair bit of magic in Astro, like its proprietary use of its own frontmatter-like section, magic MDX parsing (but only in some parts of certain files), the way it handles componentization and imports, etc. Especially if you want to use it with islands for React/Vue/Svelte, or integrate web components. "Collections" are also magic, especially when used with the separate Gatsby-like documentation engine (Starlight: https://astro.build/themes/details/starlight/).

It works great for simpler sites and blogs. But for more complex setups, the magic often gets in the way of doing simple things in a way that more mature frameworks like Next figured out through trial and error and have documented, either officially or in user reports. Astro doesn't quite have the reach yet and the docs are minimal, so when you stumble into a situation, it's really hard to find help.

The lack of proper IDE debugging also makes it really really hard to step through errors on the server side.

Don't get me wrong, I'm very happy that Astro is an option, especially for simpler sites where Next etc. are overkill. But it's still a framework with a fair bit of magic, and for any moderately complex site, you'll likely eventually hit a use case where the magic gets in the way and there's no clear way to solve it.

[ko_pivot]

You are correct about compile time magic. Runtime magic is minimal (the code runs when and where you think it does). And yes, Starlight is a foot gun IMO. It takes a framework that is designed to be easily learned and makes it even easier to use, but at the expense of the learning.