Get the top HN stories in your inbox every day.
arjie
Very nice to see these dev tools get an exit. e.g. I love `uv` and friends but did consider that perhaps dev tools are just a bad business and then no one will go into making that kind of stuff. Good exits means more of these tools.
I have only used Astro for toy stuff but it seemed neat. Congrats to the team.
EDIT: To put paid to the sidebar discussion below, yes I meant "for instance, consider `uv`; they might do these nice things and go nowhere but now that companies like Bun and Astro have gotten acquired, it demonstrates a future for others; therefore we will get more things like Astral's `uv` and so on". Hope that clarifies.
woodruffw
This is Astro, not Astral. uv is Astral :-)
Edit: OP clarified what they meant, I'm sorry for the misunderstanding on my part!
satvikpendem
They know, hence why they used e.g., i.e. exempli gratia
woodruffw
I don't think that's really clear. I think we could both defer to the OP clarifying.
For pedantry's sake: neither i.e. nor e.g. would be correct here. You want cf. ("conferatur") to invite a comparison; e.g. is when an example pertains to an instance. In this case uv would not pertain to the instance, because Astro is not Astral.
725686
For the perplex:
e.g. is latin for "exempli gratia" = for example i.e. is latin for "id est" = that is
thayne
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.
dvfjsdhgfv
It confused me as hell as my first thought was "oh great, astral.sh got bought by a large company, now we've eliminated the last obstacle to using uv in enterprise context" only to realize that it's another company with similar name.
I mean good for them, but it would be nice if the same happened to e.g. Astral (cf.).
umpalumpaaa
I think DevTools can be a very good money maker… I wrote two apps that were basically dev tools and they were the biggest of my money makers. I think it’s easier to make money from dev tools that are “apps” than dev tools that are “fundamental technologies” though so it probably heavily depends on the type of dev tools…
mikepurvis
It's probably also easier to make cottage-industry money from a single useful tool and some associated services/consulting than it is to turn the whole thing into a big company expected to do the hockey stick curve thing (eg Docker).
It'll be interesting to see where Astral ends up landing on that; afaik they have a small team and have only raised seed money, but who knows.
CamouflagedKiwi
I don't know if it's easier. I definitely think it's better, but there can be a lure to VC money that puts a company like Docker on that path. There's a world where Docker is a small company earning individually good money but with no hockey stick curve, and I think that's more sustainable and ultimately better for them.
I suppose they might disagree, of course :)
css_apologist
i'm interpreting this in the reverse
if dev tools can only be "monetized" by being bought out, it does not feel sustainable on any level
we will see companies attempt to do things like close source these projects, go subscription based, or just straight up drop support
there is no incentives for cloudflare to make astro better, or even keep it around
same goes with bun, svelte, and i'm sure countless others
pembrook
Then we'll finally be getting the world we deserve.
Decades of VC cash has trained developers to never pay for anything that powers their entire career like dev tools. The assumption is you can always squeeze some rich business customer that employs the dev.
If AI kills hiring of software engineers, then there's less devs inside businesses to sell to. So we can either pay for the products we use directly, or not have them at all.
It will take a decade to shift penny pinching behavioral habits of devs but slowly over time the market will correct itself. Chefs have always had to buy their own knives. This is good imo.
JavierFlores09
Who's to say there's no incentive. Anthropic using Bun internally is plenty incentive to make it better even if for their own use-case. I think it is a bit of a doomer perspective to think anything being bought out means the end of the line for that project. Sure, some things might change depending on the interests of the new owners but that's not to say it'll automatically become bad. Microsoft bought Github and Mojang, they're both doing better than ever for example
catlifeonmars
GitHub continues to become less and less usable (slower performance) while the number of features proliferate. On the one hand, being part of larger company _can_ relieve the pressure to stay profitable. But on the other hand, acquisitions tend to get cannibalized by the companies that acquire them. Profitability tends to become less and less aligned with usability.
stephenr
GitHub is without question worse for users now.
Joeri
Realistically to maintain a modern web framework to even a minimal standard you need a few people working fulltime on it, and more than a few if you want to take it places. There needs to be some kind of long term sustainable vehicle for funding those developers, either a corporate sponsor or a foundation.
So all those frameworks have to end up somewhere, and I’d rather it be somewhere else than vercel, as they already own way too much of the web frontend space.
mb2100
that very much depends on your definition of "modern web framework".
re-thc
> there is no incentives for cloudflare to make astro better, or even keep it around
There is - to counter NextJs. NextJs is a pain to host outside Vercel and makes Cloudflare lose customers. In theory that's why Gatsby was bought out.
> same goes with bun, svelte, and i'm sure countless others
Svelte was also taken over by Vercel. To control frontend hosting. Bun isn't in the same bucket. There isn't such competition going on.
undefined
stephenr
> Very nice to see these dev tools get an exit. e.g. I love `uv` and friends but did consider that perhaps dev tools are just a bad business
I can't even begin to comprehend what kind of world view you need to have, to think that being bought out by some megacorp with an at-best 50/50 chance of continuing existing products is an accurate measure of a "good business", much less that its the only measure.
alephnerd
> Very nice to see these dev tools get an exit...
You'll see a lot more in the next 12 months ;)
twelvedogs
yeah the thing about dev tools is that devs love writing them and your market is just devs
reactordev
Dev tools that support an ecosystem of things. A dev tool by itself isn’t that valuable unless it’s a backbone of an ecosystem. Astro is. React is. TUI.js is not.
A brand - like charm bracelet - with dev tools is another avenue. Why build one when you can build dozens?
In the end it’s about providing value. Not novelty but value. Make your new overlords better or faster or make everyone better or faster. Provide a value that can be measured.
nindalf
I’ve used Astro on Cloudflare for a few years for my personal website (username.com). They’ve both been absolutely fantastic, I can’t say enough good things about both of them. My website has all 100s on PageSpeed/Lighthouse, and that’s because of the performance focus of both Astro and Cloudflare. No credit to me at all. It was mainly because Astro prioritised shipping 0 JS unless it was absolutely necessary and Cloudflare is exceedingly good at serving static HTML.
But I also see the difficulty that Astro faced here. Despite being happy with the framework, I never paid for it. The paid offerings didn’t strike a chord with me. And it was partly because whatever they offered, Cloudflare already offered on a very generous free tier.
I'm glad the team have got a second life within Cloudflare,. I'm happy for the people who've given me such excellent software for free for years. Thanks folks!
ljm
Out of curiosity, how do you become ‘exceedingly good’ at serving static HTML?
By all accounts, they’ve centralised the delivery of this static HTML at several layers of the network stack, and you’re not getting static HTML anymore because some other part of the business fucked it up.
The World Wide Web was serving static HTML for decades before Cloudflare came along. Open an FTP client, drag and drop, and boom - new HTMl is served.
fartfeatures
When we talk static HTML I think that still includes images, stylesheets and potentially even very basic javascript (e.g. setting classes). Those take advantage of CDNs; Cloudflare have an extensive CDN with decent latency / locations. They also are a DNS registrar and a lot of people use them for their local DNS provider so again latency benefits. That's before we talk about the DDoS protection, injecting stuff like metrics etc etc. I don't want to sound like a Cloudflare rep here but I can see where this user is coming from.
kmacdough
The biggest advantage? Regional caches.
If your traffic volume stays well below server capacity, the network connection is impeccable and throughput isn't a major factor in ISP costs, then the improvement is indeed negligible.
However, if the server or it's network ever experience congestion or disruption, or you simply face sheer volume, that's when CDNs shine.
Regional caches insulate clients from network or performance issues with your server or its connection. If you have high volume, they also drastically reduce traffic through the backbone which can reduce ISP costs, depending on your contract.
Like others say, this really applies to all static content, including static media, css and js.
I hear you ask, "how can you be exceedingly good at this?" Caching itself isn't tricky, but catching efficiently and effectively at such huge scales is. The fact that Cloudflare offers these services for FREE, is a pretty good (perhaps Faustian) deal.
undefined
LtdJorge
If everything is static, they'll cache it in a DC close to you. That's better than what we had before.
kevinskii
Likewise! I built my personal blog with Astro and host on Cloudflare (username.dev), and feel guilty about taking advantage of such excellent software and free tier. Here’s hoping they find a way to take my money soon.
snorremd
I'm in the same boat as you. I've built a personal home page with Astro and hosted it on Cloudflare. It has been really cheap, only paying for worker subscription at 5 dollars per month. The site has been running non-stop essentially without downtime. And as you say the user experience of Astro's static HTML, css and minimal JS output on Cloudflare edge CDN network is really good.
But with the events of the world being what they are I have been considering moving my Astro page to BunnyCDN and thus Europe (where I live). The only Cloudflare specific feature I've used is D1 database so migrating now shouldn't be too difficult. I really hope Cloudflare does not make it difficult to use Astro on other providers, either intentionally or by accident. Next.js for a long time was essentially a framework that only ran great on Vercel, and using other providers was asking to become a second citizen. I believe it is somewhat better now with proper provider plugin system, but still.
Astro has been great and I understand they need to find a way to economically sustain their business. Joining a big company like Cloudflare is one way to do that. I can't complain too much never having opted to use Astro's commercial offerings. So I only hope they keep Astro open. I'm building a new product on top of Astro now and would hate to see it become a Cloudflare-only product.
Congratulations to the Astro team!
deepfriedbits
I appreciate your honest testimonial. It's so rare these days to read a sentence like, "No credit to me at all" haha
BenGosub
amazing performance.
philipallstar
It would be good to understand what Cloudflare gets out of the deal. The article is very much just "Astro, but someone else pays the bills!" which is of course lovely for Astro.
mpeg
Same reason vercel buys open source... it makes cloudflare always a great deployment option for all Astro sites, which in turn helps cloudflare's core business.
For example, Cloudflare released their vite plugin which makes it effortless for frameworks that use the vite env API to run inside workerd (meaning you get to use cloudflare service bindings in dev) back in April and only React Router had support for it. Nextjs has no support, the draft PR to add support for Sveltekit has been parked until the next major version, Astro only just added support in their beta 6.0 release 3 days ago
With this acquisition, Astro will probably be first to future updates that increase compatibility with cloudflare. It's smart, and was probably not very expensive (more of an acqui-hire)
Seattle3503
So when folks say they want to see big companies invest in open source, this is what that looks like. CF could have kept coasting on what Astro was building, but instead they are paying for it. But in return they get a lot of control.
skybrian
Well, hopefully more like Go's relationship with Google? The company that pays the bills is their first and most important customer, but as far as I can tell from the outside, the Go team makes its own plans and management doesn't pull rank.
ignoramous
> CF could have kept coasting on what Astro was building, but instead they are paying for it. But in return they get a lot of control.
Supabase pioneered the modern implementation of this model. Probably, RedHat before it? Google also tend to "acquihire" maintainers of popular FOSS projects, like Ben Goodger (Firefox), Scott Remnant (Upstart), Junio Hamano (Git), Guido von Rossum (Python).
cornholio
So, cloudification: lock the customer into a complex cloud dependent solution they can't easily migrate to some other commodity infrastructure provider.
taraindara
The easier/convenient a cloud makes it for a business to use, the more the industry will continue to trend towards lock in
mynameisvlad
What lock in? They explicitly said:
> Staying open to all was a non-negotiable requirement for both us and for Cloudflare.
They have deployment guides for practically every provider out there: https://docs.astro.build/en/guides/deploy/
And at the end of the day, most of the deployment is just deploying a static site... Which you can do practically anywhere.
sofixa
No? It's still the same Astro that you can move to any other provider that supports it - and it's just Javascript, so pretty much everyone supports it.
jtbaker
> Nextjs has no support
From what I remember, you can't even run a NextJS app through vite?
mpeg
Yes, that's part of the problem, deploying nextjs to cloudflare in the first place used to be an absolute nightmare, let alone the dev experience (I think it's better now)
Vinnl
That doesn't sound too preposterous; I wouldn't assume you'd be able to run a React Router project on Turbopack or Webpack either, and Next.js I think has a way more intricate dependence on the bundler to power a significant chunk of its features.
mattgreenrocks
This is insane to me, and validates my irrational dislike of next.
jjmarr
I use Astro so I could make my blog a static site and deploy it to Cloudflare pages.
I was impressed since I got interactive compilation and state tracking of how many exercises the user completed.
slfreference
I have a question. Why can't Whatsapp or Meta make a markdown INFO only website for small business owners (e.g. technicians, shopkeepers, handyman, etc) using their immense reach and clout. The method of using whatsapp groups to keep users updated of the latest updates is not scalable or open.
Y_Y
This reads like marketing copy. Maybe it reflects your actual feelings but it's hard to imagine that if you don't write like a human.
satvikpendem
It does not read like marketing copy to me, what part of talking about draft PRs and framrworks sounds like marketing speak? They're right that CloudFlare having priority access to new Astro features is beneficial for them.
mpeg
Not sure how to feel about this! I’ve been known to use em dashes every now and then, but I am indeed a fellow human.
I’m close to the vite plugin in particular and have contributed to multiple frameworks around cf integration (simply because I use cf), that’s why I chose it as an example (and it’s one of Astro 6’s biggest features)
ghurtado
What a bizarre comment. What part of it was "not human" in your opinion?
pxtail
It's obvious when you look at https://astro.build/blog/astro-6-beta/ and see "Cloudflare" sprinkled everywhere in the article.
paxys
They get to make Astro -> Cloudflare the default publishing pipeline. Sure users may pick something else, but even if a small % stick with Cloudflare that's an overall win.
threetonesun
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.
HumanOstrich
Why did you expect info about deploying Astro to Cloudflare Pages? It's been supported for a long time already.
csomar
Nextjs doesn’t really work on cloudflare with the latest versions. There is an adapter but it’s buggy as hell. The direction is also likely to continue: https://omarabid.com/nextjs-vercel
Source: I use cloudflare and used to run my app there (nextjs) and had to do a migration to vite.js. So the way I see it, this is cloudflare response to vercel.
solarkraft
My god. Every time I touch Next.js in some project I think “hey, this actually doesn’t feel so bad to develop with, dare I say it feels nice?“ and every time I read about it I think “what the hell, this is the worst choice you can make“.
It’s wild that they’re somewhat taking the whole React ecosystem with them.
everybodyknows
Following your link, the fault for this appears to lie entirely with Vercel management.
Cross fingers that CloudFlare never try similar lock-in games, now that they control Astro?
csomar
I don’t think so since they are using the worker model. My guess is that the first class support will go to that. Though they can do lockin differently (kv, queues, etc..)
nindalf
None of us have access to Cloudflare's internal data. But a reasonable guess is that enough of their current and future paying customers use Astro? I'm one of those - Astro hosted on Cloudflare.
bflesch
Cloudflare definitely gets positive PR out of this which makes people forget their CEO's recent meltdown on twitter.
chuckadams
The "meltdown" where he refused to jump to the whims of Italy's football cartel and block whatever addresses they wanted without accountability or review? More meltdowns, please.
epolanski
A meltdown is a meltdown.
Cloudflare is bound to respect the laws of the countries it operates, and if he disagrees with the process, understandable, that was not the way to express it.
Aissen
What does Vercel get out of Next.js? Just default integration of overpriced cloud infra.
azangru
Vercel was founded (or co-founded?) by the author of Next.js. That's a very different story. Vercel is like what some hypothetical Astro Cloud could have become if it had grown out of Astro.
amitav1
"I don't care, it's a stupid question."
pjmlp
It gets to be THE platform where to deploy frontends for many headless enterprise CMS and comerce stores that due to partnerships with Vercel only have Next.js based SDKs.
Additionally, I wish more serveless cloud vendors would offer a free tier like Vercel, including support for compiled languages on the backend (C, C++, Rust, Go) without asking me for a credit card upfront.
zipy124
Sometimes it is cheaper to buy a company than build the internal tool team you might have had to build from scratch anyway. Half acqui-hire, half knowing you've built something on-top of it and want it to stick around.
I also wouldn't be surprised if cloudflare wants to build this into their site-hosting capabilities.
mmooss
I don't understand how Cloudflare's bottom line benefits:
Some here say they gain Astro users, that Cloudflare will become part of the default deployment. But given Cloudflare's current scale, how much are Astro's users worth? Is it even worth the distraction for Cloudflare? Companies lose energy to lots of small, low-value operations.
Most acquisitions begin with announcments that nothing will change, in order to retain customers and employees. They say '<acquistion> is so great, we don't want to interfere, and we're keeping existing management and letting them run things'. After the transition period - often 1 year - the old managers leave and the big changes happen, sometimes including shutting down the product because it was an acqui-hire all along or an IP acquisition.
It seems like Cloudflare must perceive some profit beyond what is announced.
jimmyl02
It's very powerful to have ownership over a framework that many developers are familiar and like!
It might not be clear just yet what the path to monetization looks like but an easy example would be deeper integrations with the rest of the Cloudflare ecosystem (for example allowing R2 to be easily along with something like duckdb to live in a world of truly local analytics or something like that).
It seems like these great open source frameworks need to monetize by building a platform around the product but these days it's hyper competitive (ex. Vercel, Cloudflare) and it's hard to get started without an incredible differentiator. So, while monetizing independently as a company might be difficult, Astro can provide a lot of value to the rest of the Cloudflare ecosystem.
some1else
Why does Vercel provide Next.js? Aside from talent & tightly coupling Astro to their services, their North Star might be similar to Weekly Number of New Domains Hosted On Cloudflare. Sponsoring a framework that helps ship performant websites feeds into that metric.
I have no inside knowledge, though.
doxick
Vercel is a platform that, simplified, sells compute by time and by query.
Static optimized sites take very little compute, and little queries.
Since they have the most used framework (nextjs), they made it more server-heavy and changed the paradigm to one where a single page is built up using multiple queries for even just the html.
They then made sure that self hosting that monstrosity is terribly complex for anything serious, and incompatible with the "serverless environment" of their own platform, unless you have devops maintaining it.
And then they severely overhauled the pricing and gimped the included limits. (We were on <1% usage before. And now at 95%< while changing nothing...)
It could of course be a coincidence, but if that were the case, they would be very bad, yet lucky, business people.
100% will never put anything new on vercel and have been avoiding nextjs like the plague.
willtemperley
They get control and market differentiation. There will probably be a CloudFlare Astro CMS offering.
I personally would like a highly managed Astro solution. Astro is simple but highly extendable.
I can only hope they wean themselves off NPM somehow.
mikodin
Yeah I see the benefit right off the bat, this is a direct head to Vercel and NextJS.
With that said, I have no idea on the market share or profitability of any of that or Cloudflare vs Vercel.
Also perhaps the rails that will be put in place for seamless 1 click Astro deploy will continue to push them forward with other technologies as well, so it's not just about Astro.
I do feel that fear as well, is this an unnecessary distraction for CloudFlare? Time will tell.
twelvedogs
vertical integration probably, if you sell web services helping people get to the point that they need them is worth
buying into something that becomes popular is good advertising for cheap (react is probably the only reason for any kind of goodwill at all towards facebook)
as a function of earnings this is a rounding error purchase for them
NicoJuicy
More devs get acquainted with Cloudflare.
Cloudflare is becoming an alternative for Azure, AWS, ... Many don't realize it yet, because they don't know what Cloudflare is offering.
alexjurkiewicz
Developer goodwill. And it probably cost a song.
tonyhart7
marketshare ???
like do you understand which company doing the same thing ????? Vercel is
now we talking, cloudflare want to extend their portofolio and product offering by integrate from top to bottom like vercel does
its doens't make sense/oblivious because we view it as standalone product rather than entire suite of product offering that well integrate vertically
embedding-shape
> 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't make any sense anymore, and of course this should be rendered server-side.
Why are we doomed to repeat this, and why does it happen so quickly particularly in web development? We have each other's histories and knowledge right in front of us, what's missing for us to not continue just running around in circles like this?
afavour
IMO it's because the web has a huge diversity of behaviors (in a way that, say, native apps do not) but a monoculture on the development side.
React makes sense if you're making Gmail. It doesn't really make sense if you're making a mostly static blog. But because there are more job opportunities in the former (when you consider the wealth of internal web apps out there in the world) all the training courses folks take emphasize React and an app-centric way of thinking about the web.
And perhaps most importantly, it's good enough. It works. Users get by with it. And the developer experience is better than it was in the days of Backbone etc. So few push for change.
Zanfa
> React makes sense if you're making Gmail.
Except the old Gmail used to be so much faster…
shimman
Also the old Gmail never used react...
zcw100
Many technical directions in the past 15 years have been a thinly veiled attempt to actually get paid for doing work.
timeon
> Users get by with it.
They would not if they had choice.
afavour
And they don't. Web development practices are largely driven by what developers want, not what users want. Which is why Google started doing things like measuring Core Web Vitals and having it affect SEO rankings, to force developers to care.
Vinnl
Whenever you think that everything old is new again and we're just retracing our steps from the past, you risk missing the lessons learned in the meantime.
giancarlostoro
It gets worse, some teams would get x real estate on a website, and one team would use React, another Vue, another would use Angular because they owned that real estate on your site and that's what the team was best with. Astro lets you still do that, but turns it all into static content. Think of orgs the size of Google or YouTube, there are different teams responsible for what looks like a small thing but different pieces of a giant pie.
maelito
> 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.
This is wrong. Some websites are better mostly (mostly) rendered on the client (we call them "apps", like a map application) and some are better mostly rendered on the server (like blogs).
It was and will be.
Squarex
What is the preffered way to do the opposite now? Not every webapp should be architected as an website.
s4i
Vite + React is the go-to recipe.
philipwhiuk
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.
mpeg
The key difference between islands and what we used to do back in the day (js on a static page) is that with an islands approach you architect your site with a components-driven approach where everything encapsulates the js/css/html it needs, then you mark it as an "interactive" island if you actually need client-side js to run – the code is the same, but it either runs only in the server (default) or in both server and client.
I know this sounds similar, but, compared to the more traditional approach, there is a certain simplicity to having everything just be javascript. You can often run the same libraries on both server and client depending on your needs, plus it fulfills the promise of web components in a way that is easier to work with (though WCs have also come a long way!)
charleszw
I will also say encapsulating everything you just said in a single term, "islands," is a lot simpler and prettier to discuss. At least from my perspective, the naming also makes a lot of sense. Literal islands of interactivity surrounded by an ocean of static.
dreadnip
You can do this with just about any programming language or scripting language that can render HTML on the server + plain HTML and JS. You could do this with PHP 30 years ago.
graypegg
It has been funny seeing the tide come in and out now a few times. Though I will admit that each time, the ergonomics get better. AJAX as a pattern was pretty gnarly if you wanted to do a bit more than update a notification badge or comment box.
There's a really nice pattern of using Custom Elements [0] for that sort of JS interactivity sprinkling. You can make your web application however you want, and when you want the client to run some JS, you just drop in `<my-component x="..." y="...">...</my-component>` with whatever flavour of HTML templating you have available to you. (also possibly with the is= attribute in the future [1], which will let you keep more of the HTML template out of JS)
It saves you the hassle of element targeting and lets you structure that part of your app a bit more without going overboard on "everything is a react component, even the server bits".
Want something "server side generated" in that JS? Just render it in attributes/body/a slot element/a template element, and expect to pick it up in the JS side of things. Feels like how it's supposed to be... and there's no framework required!
[0] https://developer.mozilla.org/en-US/docs/Web/API/Web_compone...
[1] https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
WorldMaker
Custom Elements do start to feel like the dream of the Knockout-era web of "Progressive Enhancement" is finally almost entirely out of the box in the browser. Especially ignoring the Shadow DOM and using Light DOM to style your unpopulated or static rendered fallback states as close to your "live" JS-driven state can lead to some very good experiences, including and especially when JS is disabled (or erroring).
buu700
Here's a trivial example: https://supremecommander.ai. A raw CSS implementation of my blog's logo would have been a pain to build and maintain, but with Astro the code is relatively straightforward JS that becomes pure HTML/CSS at build-time.
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.
weakfish
Your website also reloads itself every 4 seconds for me on mobile Firefox
verdverm
The have Rust now so the entire tooling layer can justifiably be rewritten a few more times
boxed
[flagged]
__jonas
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.
shimman
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).
undefined
Aurornis
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.
pier25
A fix is coming: https://github.com/withastro/astro/pull/15227
giancarlostoro
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.
__jonas
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.
mpeg
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...
catoAppreciator
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.
__jonas
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.
MatthewPhillips
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:
sureglymop
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.
halfcat
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?
yawnxyz
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...
fr3dx
It is mentioned in the cloudflare blog post [1]
"At Cloudflare, we use Astro, too — for our developer docs, website, landing pages, and more"
buu700
Coincidentally, I just migrated some support docs to Starlight a few hours before this acquisition announcement. Really nice framework.
w10-1
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 easier to just have static sites is beneficial to Cloudflare?
Is there a convention about announcements, for the acquired to announce happily first to bring customers, and then the acquirer to confirm their benign intentions? When can we expect Cloudflare's take?
sixo
> So why acquire it instead of supporting it?
Lots of reasons, but above all, control.
re-thc
> The Astro claim is that astro developers will all continue full-time on it. So why acquire it instead of supporting it?
In defense? Someone else can acquire it.
nozzlegear
I'm a little wary of this. I'd been using Gatsby for my static websites for a long time, until it got eaten up by Netlify and then sunset; I switched over to Astro at that point, but now I'm getting a sense of déjà vu.
jakubmazanec
Gatsby was sunset because it was a bad framework build on bad decisions [1]. I tried to use it when it was new, and it was immediately obvious that "GraphQL for everything" leads to horrible DX.
nozzlegear
It was definitely a terrible DX, I remember having trouble wrapping my head around querying for blog posts inside my blog post component instead of receiving them as props. But I was using a custom F# + asp.net blog engine I'd written for what amounted to a static site, so I just switched to that Gatsby thing I'd been hearing a lot about at the time.
brunoarueira
I had moved out from Gatsby to Astro on my blog/site (username.com), mostly because the enormous dependency hell full of security issues, I know it's just things to generate static files, but it was causing a lot of headaches to upgrade and remove the issues. With Astro, I receive a lot less issues and the maintenance is easier! From my perspective if Cloudflare keep it that way, it'll be a win.
nozzlegear
> I had moved out from Gatsby to Astro on my blog/site (username.com), mostly because the enormous dependency hell full of security issues, I know it's just things to generate static files, but it was causing a lot of headaches to upgrade and remove the issues.
That's exactly what made me move to Astro. I would've been happy sticking with Gatsby since it still technically does what it says on the tin, but there were so many security warnings and issues with upgrading dependencies that I gave up.
undefined
piffey
Just setup my personal blog again after a four years hiatus using Astro (loved the good docs). Kind of disappointed, but given how simple static site generators are, probably something Claude could crank out easily with parity of features I actually use then wouldn't be beholden to any project's creators.
stared
I love Astro - migrated my blog there (here it was a gradual improvement), migrated company website there (here a lot, to joy of everyone). In the times of vibe coding, there is much less reason to use WYSWIG website editors. In our company, a non-technical assistant, modified website with Claude Code.
I hope that this acquisition will go well. It would be sad to lose this great framework. At the same time, we deploy on Cloudflare. So their business is to keep Astro cool so that more people will use Claudflare, it would be a win-win!
pier25
Astro is amazing. I've been using it for a couple of years now. Initially only for static sites but now I'm building the UI of all my web projects with it.
I wonder if there will be some sort of collab between Hono and Astro given that Yusukue also works at Cloudflare.
upcoming-sesame
Yup, there's a lot of overlap especially with the HonoX framework that has island architecture as well!
TurdF3rguson
This is the main thing for me. If I can keep the cf workers backend in the same repo and deploy them together I will consider leaving Next.js for good.
phartenfeller
Why does Cloudflare need a web framework? Most obvious would be they think they can make money from hosting astro sites (like Vercel and NextJS). I hope Cloudflare's impact on Astro will be tiny. But another great thing being swallowed by big tech...
arcanemachiner
> But another great thing being swallowed by big tech...
I will never use Cloudflare if I can help it, but this outcome is preferable to Astro becoming abandonware.
phartenfeller
There are so many more options than being acquired and abandonware. Its hard but there are many independent and stable open source projects.
arcfour
This is overly cynical without reason. CloudFlare is hardly "big tech" even if it is a "big" "tech" company. They have no record of killing or abusing open source projects.
phartenfeller
Maybe not by market capitalization but Cloudflare is used by around 25 % of the web. Internet giant in my books.
dvtkrlbs
They are using astro starlight for their docs page and using astro itself in number of their landing pages.
Get the top HN stories in your inbox every day.
https://www.cloudflare.com/pl-pl/press/press-releases/2026/c...