Comment by koakuma-chan
1 day ago
I am very disappointed with Astro.
Who is this framework for?
It's been years, and they still don't support unit testing Astro Actions. They still don't support inter-island communication.
"Astro v6 is around the corner" - and the only changes are 1. refactored CLI (why? it's perfectly fine) 2. bumped zod to v4
It's great if you want to build a blog or something, but it's definitely far from great for building apps.
Don't know what they are thinking.
I don't think it's really targeted at building apps, as far as I can tell its whole pitch has always been that that most websites are not apps and therefore most websites do not need a full JS framework like Next.js.
They even say it in this blog:
"Our mission to design a web framework specifically for building websites — what we call content-driven websites, to better distinguish from data-driven, stateful web applications — resonated"
> Who is this framework for?... It's great if you want to build a blog or something, but it's definitely far from great for building apps.
Not an Astro expert, but the massive headline at the top of the homepage may provide a clue as to their intended audience:
> The web framework for content-driven websites
On inter-island communication, I actually think less is more – I find a lot of the recent big features like this they have added unnecessarily constrain you to doing things a certain way, while the reason I liked Astro in the first place was the simplicity.
You can easily add any global store library to your project to communicate between islands from the very simple (nanostores) to more complex stuff (are people still using mobx, redux, etc?)
I actually would prefer if Astro kept the core more simple, I never understood the point of Astro components for example; always thought their game plan would be to build their own client-side framework like what remix v3 is doing, but currently their components are too limited to make them worth using over just doing everything in react, svelte, or whatever floats your boat.
Astro component is your page's entry point. It's similar to React server component. The typical flow is to fetch data in it, and pass the data to client component written in React or whatever. You can also have pages that are Astro only, without any front-end framework.
Yeah, I know, but since by default the front-end islands are server-rendered with no hydration the lines are blurred between what you would use an .astro component for, and just using for example react.
Personally I only ever use .astro components if I'm 100% sure I will never need any client side interactivity, otherwise it's just easier to ignore them.
2 replies →
There are tons of options for sharing state between islands.
The docs show how to use nanostores but you can use other libs like vue refs, etc.
https://docs.astro.build/en/recipes/sharing-state-islands/
Can't you just use standard DOM events for that on the client? This would work even pushing events from React to Vue to Vanilla.
That's what I did, but DX is not great. I would prefer some kind of channel API.
If all you are writing a blog and you're not using Substack or Squarespace or any of the other million blog hosting options you're crazy IMO.
If you aren’t realizing the importance of POSSE imho that’s crazy ;-)
You become beholden to these platforms and they're inherently not portable. There is risk here, and given the track record of Internet companies I think it's fair to say the risk is not worth it for many people.
Your costs could explode, or worse, the business could go under and you lose all your shit.
Substack only really makes sense if you want to monetize your content.
Why ? Spinning up a blog these days with one of these frameworks is almost quicker than signing up to one of the blog hosting platforms.
And you get to keep your data in markdown easily portable