291–300 of 409 posts
Earlier quoted context omitted.
Once again, it’s a static site builder. How, exactly, would they “stop supporting deploying to cloudflare’s competitors”? Be specific.
The same ways Vercel makes it harder to deploy Next.js sites to competitors or for self hosting.
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…
> In 2021, Astro was born out of frustration. The trend at the time was that every website should be architected as an application, and then shipped to the user’s browser to render. Was it? Hot damn, I knew it'll eventually happen, but we truly are just running around in circles. Eventually these same people will do the same loop around, creating new frameworks because the current "server client" model suddenly doesn…
Yeah, I'm not sure I understand why "islands" isn't just "bits of JavaScript on a static page". It feels like the "JavaScript as a Server Side Language" folk are just repeatedly re-inventing stuff that has been done a million times by other systems with a different back-end only with a new fancy name.
The other nice thing is that you can throw all kinds of preexisting components from React/whatever into your site, and it will ship zero JS to the client until you explicitly flag a specific JS resource as an "island".
The only special thing about "islands" is that they're an escape hatch from the default behavior of JS being strictly build-time-evaluated. I found the terminology and description a little confusing at first too, because it makes it sound more special than it is. But the concept makes sense when you understand the context of Astro's intentional default behavior.
I agree a good exit for devtools is good for devtools. I'd like to understand it better. The Astro claim is that astro developers will all continue full-time on it. So why acquire it instead of supporting it? The reason given in complementarity (content and infrastructure), but doesn't that mean that Cloudflare is moving into content? Perhaps it's fair to say some content fits better with Cloudflare, or making it eas…
In defense? Someone else can acquire it.
Earlier quoted context omitted.
I'm not sure. I wouldn't generally call Astro a "dev tool". It's more of a framework. It's possible you are right, but it isn't clear from the content of the comment.
Frameworks are a category of development tool. Things that developers utilitise to be productive.
Earlier quoted context omitted.
I expected something clearer in the blog post about deploying Astro on Cloudflare Pages, as I imagine many Astro users (like me) are on Netlify. I think every deployment pipeline having it's own preferred UI framework (and CMS, and cloud-DB solution) makes a lot of sense.
Why did you expect info about deploying Astro to Cloudflare Pages? It's been supported for a long time already.
Earlier quoted context omitted.
Why did you expect info about deploying Astro to Cloudflare Pages? It's been supported for a long time already.
Seems like an obvious thing to call out for people (like me) who don't know.
I've been skeptical about trying Astro because it seems to have unnecessary complexity. Also, I don't see any evidence that Cloudflare is going to prioritize making Astro easier to use.