311–320 of 409 posts
Surprised this isn't in the article, but Cloudflare has been moving all their docs to Astro's Starlight docs framework. I'm guessing this is a way to prioritize features for Cloudflare: > https://blog.cloudflare.com/open-source-all-the-way-down-upg...
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.
What Vercel really did was make Next.js work well in serverless environments, which involves a lot of custom infrastructure [0]. Cloudflare wanted that same behavior on CF Workers, but Vercel never open-sourced how they do it, and that is not really their responsibility.
Next.js is not locked to Vercel. The friction shows up when trying to run it in a serverless model without building the same kind of platform Vercel has.
I found that Vite does a great job of deploying static websites. All I had to do was add Vite as a dev dependency in my pacakge.json and make sure all the page routes in vite.config.js. 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.
Earlier quoted context omitted.
Definitely irrational. There are lots of logical reasons to dislike Next (like the fact that they pile new shiny bit on top of new shiny bit without caring about the regular user experience) ... but being mad that it can't run on Vite is silly. It's like being mad that Rails can't run on Python, or that React can't run on jQuery. Next already has its own build system, so of course it doesn't work with another build s…
Isn’t the next.js build system known for being slow/memory hungry?
It's also wise to use monorepo orchestration with build caching like Turborepo.
They did well on the turbo stuff, no doubt about it.
The main bottleneck with big projects in my experience is Typescript. Looking forward to the Go rewrite. :)
I have always liked Astro. It also works great with AI tools since its combination of markdown and code. Was able to vibe code a quick blog template and deploy to cloudflare in minutes with an existing headless backend - https://sleekcms-astro-blog.pages.dev/
This is making me even less interested in trying Astro. Websites should not be vibe coded.
That sounds like shooting yourself in the foot out of pure spite, but you do you.
is astro any good ? havent tried it yet
Earlier quoted context omitted.
Astro isn't just a static site generator either. Not sure what your point is.
[flagged]
And yes I can see you're posting the same lie all over the comments here.
Stop being a potty mouth.
Earlier quoted context omitted.
What in Astro would make it easier to use? Or, what makes it more complex to use than you'd like? We're always open to feedback!
The first thing I would do is stop trying to support AI tools, and remove any comments about AI from the documentation. Generative AI is not suitable for building content-driven websites because it lacks context to understand subjective user preferences. Also, having .astro files to implement island functionality is unnecessary. Interactivity can be implemented with Javascript using web components.
I love web components (one of the things that got me into Astro), but it can be helpful to reach for something like Solid when you get into more complex UI. Most Astro projects will never need to reach for that, which is why there's no UI framework available by default.
Astro definitely tries to stick to a minimal defaults approach by design. We'd rather people start from a simple, minimal boilerplate, and reach for solutions (e.g. UI frameworks, on-demand rendering) only when they run into a problem it solves.