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.
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.
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.
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).
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.
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.
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.
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.
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.
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)
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)
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.
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.
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.
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.
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.
I hope they maintain a clear path to delay separately too.
With these sort of combinations the deploy to cloudflare button gets ever bigger than over time. And then features get added that only work with CF and eventually it’s still open source but only half the stuff works standalone etc
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 exceedingly 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!
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.
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.
The "refreshing" part here is actually the problem.
When an open-source project with real users can't find a sustainable business model, we treat honest admission as a virtue. But the real question is: why was monetization urgent in the first place?
VC-backed projects operate on extraction timelines—raise capital, hit growth targets, exit within 5-7 years. That model works for some businesses, but it's terrible for infrastructure tools that need decades to mature.
Contrast this with projects that grow without extraction pressure:
- SQLite: 23 years old, powers billions of devices, never took VC money
- Linux: 33 years old, runs the internet, community-funded
- Nginx: Built slowly, sold on founder's timeline (not investor timeline)
Astro built something valuable. But VC money came with a clock. When the clock ran out before sustainable revenue appeared, acquisition was the only exit.
This isn't a failure of Astro. It's a feature of the funding model. We need more ways to fund infrastructure that don't require artificial monetization timelines.
(Disclosure: I run a tuition-free school exclusively for entrepreneurs... 100% founder-funded specifically to avoid this extraction pressure.)
SQLite made and makes a lot of money from a lot of the people who use them. It's free for us to use, but it wasn't free for Motorola and AOL and Nokia (and later Google, Apple and Adobe) who contracted the team to build it out, add features, fix bugs on it. This wasn't FOSS funded by a few people's free time. It was a commercial business that made money by finding product market fit - the best embedded database in the world. Their scale then allowed them to find more bugs, fix them and become more reliable than anything else.
> I scrambled around and came up with some pricing strategy. [Motorola] wanted some enhancements to it so it could go in their phones, and I gave them a quote and at the time, I thought this was a quote for all the money in the world. It was just huge. ($80k)
> [Nokia] flew me over and said, “Hey, yeah, this is great. We want this but we need some enhancements.” I [Richard Hipp] said, “Great,” and we cut a contract to do some development work for them.
> We were going around boasting to everybody naively that SQLite didn’t have any bugs in it, or no serious bugs, but Android definitely proved us wrong. Look, I used to think that I could write software with no bugs in it. It’s amazing how many bugs will crop up when your software suddenly gets shipped on millions of devices.
If you can find paying customers that can fund your development, then it's fantastic. It's even better if those contracts give you scale that none of your competitors have. You don't need VC money if that's the case. But let's not pretend that Astro were in that situation. No one was paying for a web framework.
> If you can find paying customers that can fund your development, then it's fantastic. It's even better if those contracts give you scale that none of your competitors have. You don't need VC money if that's the case. But let's not pretend that Astro were in that situation. No one was paying for a web framework.
Didn't this just happen right now that Astro got acquired by Cloudflare? I am sure that Cloudflare has bot tons of money right now so Astro got an offer to good to refuse but worst case scenario they could've still partnered up with cloudflare,netlify,vercel etc. but also companies who deploy astro (even google deploys astro pages)
Plus, Astro has a very strong focus on being performant/fast (getting 100 lightscore) so they could've definitely focused on consultance as well to actually have the people who work in the craft who can take a look and help you get score who literally know the inside out of Astro
That being said, the Question is, could they have survived long enough to be in a position of sustainability without VC money or could they have gotten sustainability from the start, if so what could be the path that they could've taken so that they didn't need VC money or could be (day-1 profitable ie?)
Problem is, it was possible to get there with minimal effort. The default config of Astro was 100. I know absolutely nothing about web dev and my personal website was all 100s.
And in any case, consultancy doesn't scale. Interestingly Tailwind has that kind of model - free software, pay for beautifully crafted components. And their business isn't doing well.
We don't know what would have happened in an alternate universe. But it's hard out there building businesses on FOSS. Can't blame anyone for trying - VC or otherwise.
Meta response: This account’s recent comment history is almost exclusively self promotion for their content, YouTube channel, and school. Much of the comment text appears LLM generated with classic signs such as the em dash, bullet point lists, and this-not-that comparisons that are common to LLM generated output.
It’s noteworthy because this comment is currently the top voted comment, probably because it hits all the notes of what you’d get if you asked an LLM to generate some content to tap into anger in a Hacker News comment section. It’s scary that this type of LLM powered engagement bait is so successfully being used to advertise on HN.
The criticism is also not very pointed. Like, I don't understand what the core message is. There is disdain for VC money and an implication that Astro could have gone without monetization. Both of which don't seem very well argued. But even if we grant those points ... so what? What is our take away supposed to be? It's a bunch of negative observations that don't funnel into some concrete conclusion.
It seems like the takeaway is supposed to be to look favorably on the commenter. "This is bad. I am good."
The top comment doesn't even make sense. Sqlite actually had to get funding to continue operating! They weren't immune from worries like paying rent or buying groceries.
It's just an ad that people are upvoting uncritically.
> Linux: 33 years old, runs the internet, community-funded
Only in dreams, it took off thanks to the likes of IBM that decided it was a way to save costs on their UNIX development efforts, many key projects have been founded thanks to Red-Hat Enterprise licenses, nowadays also part of IBM.
GCC, clang, GNOME, Linux kernel, systemd, CUPS, AMD/NVidia drivers, have plenty of big corp money.
It's still the community when the community is via corporations.
Corporations are just groups of people. Pure grass roots "We collect the money, anonymously in cash shaking a bucket at our annual fundraiser" does not work at this scale. Even Zig, which I'm guessing is about as far away from "It's all just owned by an inhuman corporation" as you could ask for, does have big ticket corporate donors. So does ISRG (Let's Encrypt) or the EFF.
Venture Capital is a bad fit, that's the conjecture here. VC funding for infrastructure is a mistake because that big pay day won't happen if you did it correctly. That doesn't make VC inherently bad, or projects like Linux inherently defective, the claim was that it's just a bad match, like how an Irish Stout doesn't pair well with a subtle tomato and angel hair pasta dish.
The tone of OP was more like the "community of peace and love without money from the man".
Gathering around projects, talking over USENET, Gopher, phpBB forums, sharing code over email, Sourceforge, Savannah , living the FOSS dream, the whole mantra of when the GNU manifesto came to be.
All a matter of if the project dies when the money fountain runs dry, and developers have to find another way to pay bills other than a few meagre donations.
Not sure it's dreams to say "community-funded". Depends on terminology.
The funding assertion leverages the re-definition of “community” in “community funded” and relates to why all those big projects offer CE or Community Editions instead of calling it free or open source editions.
Enterprises are willing to take a look at free, but "community editions" are clearly for peons, not the big boys, so they license the commercial edition. It also productizes a subset of licensing rights in contrast with the commercial licensing rights.
In any case, in today's common parlance, community doesn't mean ICs and IC donations. It can, but it's been mostly co-opted by corp donations, which are still donations and not VC.
European Commission issues call for evidence on open source
The EU is looking for facts like this as it figures out how to use OS to begin to extend its digital sovereignty. I don't think it's as simple as, "get funding from a giant continental government instead of VCs!" but what I hope is that there is a structure the EU and Open Source can forge together that gives OS software the funding it needs to build more Nginxes and SQLites in a way that fosters the independence of those projects along with the independence of the entities that use it.
I did notice after seeing all the em-dashes. Shame because in a sense I could've agreed with them or atleast have a good discussion but if they didn't even take time to write their posts then oof
If the purpose of this was to promote their academy or school or whatever, what was the point? Because at this point, they have lost all credibility and respect and HN isn't a gullible audience so I don't understand the point of why they did this
> If the purpose of this was to promote their academy or school or whatever, what was the point? Because at this point, they have lost all credibility and respect and HN isn't a gullible audience so I don't understand the point of why they did this
It’s the top voted comment right now. Their comment history has similar comments with links to their products and content.
I think they’re doing it because it was working for them. I bet they’re happy with the additional traffic they’re picking up for a minute or two of promoting an LLM and then appending a link at the end.
I thought this was a cheap shot, but then I checked the account’s comment history. Not all of the comments look like LLM output but a lot of the comments from this account are definitely in LLM style. It even has an em dash. With the plug attached at the end I think this is their advertising strategy: Plug into outrage threads with LLM generated content and then guide people toward their program after the hook.
The VC funding model is broken in general - it's not only bad for open source projects, it's bad for most projects.
Modern expectations that a VC pumps in millions (or billions) of dollars and then extracts 10s of billions a few years later is an unrealistic expectation for most companies, and forcing everything into that model is killing off a lot of projects that could be successful on a smaller scale. The pressure forces small companies to sell out to bigger corporations, consolidating the industry into a few huge players who gate keep and limit competition and choice.
SQLite probably never took VC money, yes. People pay them for work.
Many, many people working on Linux work for companies that pay them to work on Linux. Linux is not, and I don't believe has ever claimed to be, community-funded.
Nginx was bought, a couple of times maybe, so they have had cash injections of some sort.
> We need more ways to fund infrastructure that don't require artificial monetization timelines.
Funding infrastructure isn't the problem, exactly. VC is for a specific type of funding: risky businesses that need scale to make money. We have found the answer: VCs, who are willing to lose all their money on your project.
This is 100% an AI generated post. Incredibly disappointing to see this stuff making its way to HN. If you want to promote your school, at least write a post yourself.
Not really an apples to apples comparison. You are comparing it to core technologies that millions of things sit on. There will always be money for 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'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?
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.
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.
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.
> 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).
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.
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 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!)
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.
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!
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).
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:
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!
Only mildly surprising - Astro + CF Pages/Workers have been my go-to for when I want to spin up a static site or do anything else and it does feel like they've been really working on the integration between the two.
Wow, these are the same people behind Pika/Skypack and Snowpack. I can remember the day when they announced the Astro project, and now it's joining Cloudflare, incredible progress.
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.
My favorite framework, and what has brought me much deeper into the world of web development. It's what I have used for me personal page https://bryanhogan.com/ . I'm happy to see it get funding, although I hope this doesn't introduce entshittification. So far I'm hopeful though.
It's the first framework I recommend to web dev beginners, after they have built something with plain HTML and CSS.
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...
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.
It's kind of past that phase, according to Gemini, it's a tax play:
The "No" (Non-GAAP & Free Cash Flow)
If you look at Non-GAAP (adjusted) figures—which many investors use to judge the actual "engine" of the business—Cloudflare is solidly profitable.
Adjusted Income: They reported a non-GAAP net income of $102.6 million for Q3 2025.
Cash Flow: Cloudflare is Free Cash Flow (FCF) positive. They are generating more cash from their operations than they are spending to keep the business running, reporting $75 million in FCF in their most recent quarter.
Why the difference?
The main reason Cloudflare still shows a "loss" on paper is Stock-Based Compensation (SBC). Like many high-growth tech companies, they pay a significant portion of employee salaries in stock rather than cash.
The GAAP view counts that stock as an expense (creating a "loss").
The Investor view often ignores it because it doesn't drain the company's bank account (showing "profit").
Astro is my favorite way to build websites (at least, of the kind its great at) and I'm happy for the team; Cloudflare is a super cool place to work. Excited to see in what directions this will develop. They have a real shot at being the next Next.
From a developer perspecive, I was going to go "Ahh shit here we go again"
But to be really honest, thinking more about it. atleast from an "AI" bubble perspective, Cloudflare is pretty rock solid and isn't involved in the AI bubble deals whereas vercel has
If you were to use cloudflare workers say the past few months, you would've noticed some serious UI/UX improvements and its projects highlighted astro template was one of the first things (I think second was sveltekit iirc)
Anyways thinking about it now, I am sure that cloudflare must have been in talks with them for quite some time and they had the astro deployments on cloudflare workers so they must have seen its usage and other data we have no idea about to justify this purchase
That being said, I had been part of astro community almost exactly the time they had partnered up with turso (It was my holidays so I wanted to build a website from scratch, I sadly lost it but it was really cool and it had BMO from adventure time's pixel art that I lost oof :<)
So I was in their discord when they had just joined turso for astro DB and at that point, you couldn't host it locally (some tried with wasm) not sure what's the reality now though. But its interesting to see this because cloudflare offers a turso (serverless sqlite) alternative as Cloudflare D1, So we might see Astro shift to d1?
Once again, I have not been part of community for almost around 1-2 years so I don't know the current state of Astro aside from tweaking around making my own custom editor in bun for some astro templates (astro templates are really cool)
Perhaps, we are gonna see astro templates website + cloudflare workers to create an instant deployment of astro templates on cloudflare workers as a first class citizen. Honestly I would love that because cf workers/pages are free/cheapest in the whole market.
I hope that Astro still stays local first and still its serverless features can benefit everybody and not just cloudflare (looking at you vercel for nextjs)
Crazy how my Sveltekit app is running on Cloudflare Pages, and my Astro app is running on Vercel. But I appreciate them having these services to let us showcase our personal projects for free at least
This is cool, I use astro when I just want to spin up a quick site without having to fight the framework (looking at you, Nextjs) and the main thing I disliked was the initiatives around paid extras they had going
Astro and Tanstack are probably the best full-stack routers these days, and Astro wins in terms of the wide support for almost any client-side tech
It still baffles me why Netlify did that. Gatsby seemed to have already been dying, even before the acquisition; and it didn't look like Netlify was planning to invest in it.
Netlify didn't buy Gatsby for the framework. They wanted the hosting business and the GraphQL thing. They said this at the time, and it's true. It was barely resourced. Cloudflare is only interested in the framework (because Astro has nothing else).
Source/disclosure: I worked at Gatsby, Netlify, Astro and Cloudflare
Seemed a good idea at the time. The unified data layer was always the best thing about Gatsby (which is why I nicked the idea for the Astro content layer), but maybe not as a hosted product
Welp, I'm worried. I like Astro, but maybe it's time to make my own SSG, to not ever end up in the hand of a few big-sharks that consolidate and enshittify everything.
I experimented a lot with bootstrapping React projects this past fall, and Astro was by far the least painful to use. Notably, it was the least goofy of all of the React starter kits to use for server API development.
Unironically have been migrating my static pages (from Nextjs and Eleventy) to plain HTML and love it.
Of course depends on your use case if that is feasible.
Disliked the templating solutions, the messy documentation, the loss in momentum, and liked a lot of the stuff (especially the tooling and principles) in astro.
Also strongly disliked how political eleventy got.
I just wanted a website, not a an internal debate about what I am potentially being absorbed into. I can vote, and spend money on donations, I don't need to enact change through my tech stack.
Well, there's this other project that recently secured funding from a company that has a proven track record of supporting great open-source projects like Astro, TanStack, and Hono without trying to capture or lock anything down.
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"
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.
I mean, you have to have an .astro file if you want your route to be picked up, and then import and use React components in that file. IIRC, you cannot just directly use React.
Oh right, yeah I get what you're saying now. Indeed I think .astro templates make sense at the page level say to define a layout, and I actually like the syntax of stuffing the server js into a frontmatter style block, it's pretty nice.
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.
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.
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).
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.
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.
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.
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.
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...
Wow. Good callout.
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.
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)
> Nextjs has no support
From what I remember, you can't even run a NextJS app through vite?
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)
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.
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.
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.
Cloudflare definitely gets positive PR out of this which makes people forget their CEO's recent meltdown on twitter.
It's obvious when you look at https://astro.build/blog/astro-6-beta/ and see "Cloudflare" sprinkled everywhere in the article.
What does Vercel get out of Next.js? Just default integration of overpriced cloud infra.
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.
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.
Mindshare with developers is what cloudflare gets
I for one host several Astro sites on Cloudflare Pages.
Its quite a nice DX actually.
I could see Cloudflare just wanting to push for a bit more vertical integration in the space to give themselves some more options.
https://www.tumblr.com/ourincrediblejourney
This is probably just an acquihire.
Probably better support for CF Workers/Pages and better integration with Wrangler.
Feels like they are trying to do vertical integration on the whole stack and compete with Vercel.
For me, anyone that tries to compete with Vercel has to beat their offering in backend runtimes.
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.
I hope they maintain a clear path to delay separately too.
With these sort of combinations the deploy to cloudflare button gets ever bigger than over time. And then features get added that only work with CF and eventually it’s still open source but only half the stuff works standalone etc
That said - good for them.
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 exceedingly 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!
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.
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.
The "refreshing" part here is actually the problem.
When an open-source project with real users can't find a sustainable business model, we treat honest admission as a virtue. But the real question is: why was monetization urgent in the first place?
VC-backed projects operate on extraction timelines—raise capital, hit growth targets, exit within 5-7 years. That model works for some businesses, but it's terrible for infrastructure tools that need decades to mature.
Contrast this with projects that grow without extraction pressure:
Astro built something valuable. But VC money came with a clock. When the clock ran out before sustainable revenue appeared, acquisition was the only exit.This isn't a failure of Astro. It's a feature of the funding model. We need more ways to fund infrastructure that don't require artificial monetization timelines.
(Disclosure: I run a tuition-free school exclusively for entrepreneurs... 100% founder-funded specifically to avoid this extraction pressure.)
SQLite made and makes a lot of money from a lot of the people who use them. It's free for us to use, but it wasn't free for Motorola and AOL and Nokia (and later Google, Apple and Adobe) who contracted the team to build it out, add features, fix bugs on it. This wasn't FOSS funded by a few people's free time. It was a commercial business that made money by finding product market fit - the best embedded database in the world. Their scale then allowed them to find more bugs, fix them and become more reliable than anything else.
The whole story (https://corecursive.com/066-sqlite-with-richard-hipp/) is fascinating, but here are a couple of interesting excerpts:
> I scrambled around and came up with some pricing strategy. [Motorola] wanted some enhancements to it so it could go in their phones, and I gave them a quote and at the time, I thought this was a quote for all the money in the world. It was just huge. ($80k)
> [Nokia] flew me over and said, “Hey, yeah, this is great. We want this but we need some enhancements.” I [Richard Hipp] said, “Great,” and we cut a contract to do some development work for them.
> We were going around boasting to everybody naively that SQLite didn’t have any bugs in it, or no serious bugs, but Android definitely proved us wrong. Look, I used to think that I could write software with no bugs in it. It’s amazing how many bugs will crop up when your software suddenly gets shipped on millions of devices.
If you can find paying customers that can fund your development, then it's fantastic. It's even better if those contracts give you scale that none of your competitors have. You don't need VC money if that's the case. But let's not pretend that Astro were in that situation. No one was paying for a web framework.
> If you can find paying customers that can fund your development, then it's fantastic. It's even better if those contracts give you scale that none of your competitors have. You don't need VC money if that's the case. But let's not pretend that Astro were in that situation. No one was paying for a web framework.
Didn't this just happen right now that Astro got acquired by Cloudflare? I am sure that Cloudflare has bot tons of money right now so Astro got an offer to good to refuse but worst case scenario they could've still partnered up with cloudflare,netlify,vercel etc. but also companies who deploy astro (even google deploys astro pages)
Plus, Astro has a very strong focus on being performant/fast (getting 100 lightscore) so they could've definitely focused on consultance as well to actually have the people who work in the craft who can take a look and help you get score who literally know the inside out of Astro
That being said, the Question is, could they have survived long enough to be in a position of sustainability without VC money or could they have gotten sustainability from the start, if so what could be the path that they could've taken so that they didn't need VC money or could be (day-1 profitable ie?)
> they could've still partnered up with cloudflare,netlify,vercel etc.
What makes you think they aren't? https://docs.astro.build/en/getting-started/ says on the bottom left: Sponsored by Cloudflare, Netlify, Webflow, MUX.
> consulting to get to 100 Lightscore
Problem is, it was possible to get there with minimal effort. The default config of Astro was 100. I know absolutely nothing about web dev and my personal website was all 100s.
And in any case, consultancy doesn't scale. Interestingly Tailwind has that kind of model - free software, pay for beautifully crafted components. And their business isn't doing well.
We don't know what would have happened in an alternate universe. But it's hard out there building businesses on FOSS. Can't blame anyone for trying - VC or otherwise.
Meta response: This account’s recent comment history is almost exclusively self promotion for their content, YouTube channel, and school. Much of the comment text appears LLM generated with classic signs such as the em dash, bullet point lists, and this-not-that comparisons that are common to LLM generated output.
It’s noteworthy because this comment is currently the top voted comment, probably because it hits all the notes of what you’d get if you asked an LLM to generate some content to tap into anger in a Hacker News comment section. It’s scary that this type of LLM powered engagement bait is so successfully being used to advertise on HN.
Also: "This isn't X. It's Y.".
The criticism is also not very pointed. Like, I don't understand what the core message is. There is disdain for VC money and an implication that Astro could have gone without monetization. Both of which don't seem very well argued. But even if we grant those points ... so what? What is our take away supposed to be? It's a bunch of negative observations that don't funnel into some concrete conclusion.
It seems like the takeaway is supposed to be to look favorably on the commenter. "This is bad. I am good."
The top comment doesn't even make sense. Sqlite actually had to get funding to continue operating! They weren't immune from worries like paying rent or buying groceries.
It's just an ad that people are upvoting uncritically.
> Linux: 33 years old, runs the internet, community-funded
Only in dreams, it took off thanks to the likes of IBM that decided it was a way to save costs on their UNIX development efforts, many key projects have been founded thanks to Red-Hat Enterprise licenses, nowadays also part of IBM.
GCC, clang, GNOME, Linux kernel, systemd, CUPS, AMD/NVidia drivers, have plenty of big corp money.
From https://en.wikipedia.org/wiki/History_of_Linux
"1998: Many major companies such as IBM, Compaq and Oracle announce their support for Linux."
It's still the community when the community is via corporations.
Corporations are just groups of people. Pure grass roots "We collect the money, anonymously in cash shaking a bucket at our annual fundraiser" does not work at this scale. Even Zig, which I'm guessing is about as far away from "It's all just owned by an inhuman corporation" as you could ask for, does have big ticket corporate donors. So does ISRG (Let's Encrypt) or the EFF.
Venture Capital is a bad fit, that's the conjecture here. VC funding for infrastructure is a mistake because that big pay day won't happen if you did it correctly. That doesn't make VC inherently bad, or projects like Linux inherently defective, the claim was that it's just a bad match, like how an Irish Stout doesn't pair well with a subtle tomato and angel hair pasta dish.
The tone of OP was more like the "community of peace and love without money from the man".
Gathering around projects, talking over USENET, Gopher, phpBB forums, sharing code over email, Sourceforge, Savannah , living the FOSS dream, the whole mantra of when the GNU manifesto came to be.
Big corp money is not VC money. That's the point.
Depends on which corporation.
No, it depends on whether they have an ownership stake in what they’re funding or not.
All a matter of if the project dies when the money fountain runs dry, and developers have to find another way to pay bills other than a few meagre donations.
Ok sure, but now you’re just describing something completely different.
Not sure it's dreams to say "community-funded". Depends on terminology.
The funding assertion leverages the re-definition of “community” in “community funded” and relates to why all those big projects offer CE or Community Editions instead of calling it free or open source editions.
Enterprises are willing to take a look at free, but "community editions" are clearly for peons, not the big boys, so they license the commercial edition. It also productizes a subset of licensing rights in contrast with the commercial licensing rights.
In any case, in today's common parlance, community doesn't mean ICs and IC donations. It can, but it's been mostly co-opted by corp donations, which are still donations and not VC.
Community isn't certainly big corporations, some of which have been born out of VC money as well.
It reminds me of this HN article: https://news.ycombinator.com/item?id=46550912
European Commission issues call for evidence on open source
The EU is looking for facts like this as it figures out how to use OS to begin to extend its digital sovereignty. I don't think it's as simple as, "get funding from a giant continental government instead of VCs!" but what I hope is that there is a structure the EU and Open Source can forge together that gives OS software the funding it needs to build more Nginxes and SQLites in a way that fosters the independence of those projects along with the independence of the entities that use it.
LLM generated reply right here. Not the worst I've seen but please just post your prompt.
Damn, I didn't notice it at all, but now it's quite obvious, it feels like stuff like this is taking the enjoyment out of consuming anything.
I did notice after seeing all the em-dashes. Shame because in a sense I could've agreed with them or atleast have a good discussion but if they didn't even take time to write their posts then oof
If the purpose of this was to promote their academy or school or whatever, what was the point? Because at this point, they have lost all credibility and respect and HN isn't a gullible audience so I don't understand the point of why they did this
> If the purpose of this was to promote their academy or school or whatever, what was the point? Because at this point, they have lost all credibility and respect and HN isn't a gullible audience so I don't understand the point of why they did this
It’s the top voted comment right now. Their comment history has similar comments with links to their products and content.
I think they’re doing it because it was working for them. I bet they’re happy with the additional traffic they’re picking up for a minute or two of promoting an LLM and then appending a link at the end.
I thought this was a cheap shot, but then I checked the account’s comment history. Not all of the comments look like LLM output but a lot of the comments from this account are definitely in LLM style. It even has an em dash. With the plug attached at the end I think this is their advertising strategy: Plug into outrage threads with LLM generated content and then guide people toward their program after the hook.
The VC funding model is broken in general - it's not only bad for open source projects, it's bad for most projects.
Modern expectations that a VC pumps in millions (or billions) of dollars and then extracts 10s of billions a few years later is an unrealistic expectation for most companies, and forcing everything into that model is killing off a lot of projects that could be successful on a smaller scale. The pressure forces small companies to sell out to bigger corporations, consolidating the industry into a few huge players who gate keep and limit competition and choice.
Markus Allen of Founderstowne thinks the umpteenth js web framework is infrastructure and puts it in a category with Linux.
You AI generated this whole comment…
SQLite probably never took VC money, yes. People pay them for work.
Many, many people working on Linux work for companies that pay them to work on Linux. Linux is not, and I don't believe has ever claimed to be, community-funded.
Nginx was bought, a couple of times maybe, so they have had cash injections of some sort.
> We need more ways to fund infrastructure that don't require artificial monetization timelines.
Funding infrastructure isn't the problem, exactly. VC is for a specific type of funding: risky businesses that need scale to make money. We have found the answer: VCs, who are willing to lose all their money on your project.
Are you using LLM-generated comments to peddle your book/fake college?
I think Andrew Kelley would argue that the issue is for-profit companies, VC money just makes timelines shorter.
https://andrewkelley.me/post/why-we-cant-have-nice-software....
Nitpick: While Linux is not VC-funded, I don't believe you can say Linux is "community-funded".
Is it just me or is this entire comment AI-generated?
This is 100% an AI generated post. Incredibly disappointing to see this stuff making its way to HN. If you want to promote your school, at least write a post yourself.
Not really an apples to apples comparison. You are comparing it to core technologies that millions of things sit on. There will always be money for that.
Holy survivorship bias Batman, and yeah, nice punchy AI sentences you got there.
> 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?
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.
> Users get by with it.
They would not if they had choice.
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.
Most non-technical users have no idea what they want. They will happily request a feature to implement an email client in your database.
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.
> 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.
What is the preffered way to do the opposite now? Not every webapp should be architected as an website.
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.
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 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!)
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.
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/...
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).
The have Rust now so the entire tooling layer can justifiably be rewritten a few more times
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...
Astro on Cloudflare workers has been my goto stack for multiple years now. I am very happy with it, and hope this makes the integration stronger.
Now we just need Cloudflare to buy one of the DBaaS companies so they have a solid relational offering.
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!
I'm incredibly relieved they didn't join Vercel (which everyone else seems to be doing these days).
Only mildly surprising - Astro + CF Pages/Workers have been my go-to for when I want to spin up a static site or do anything else and it does feel like they've been really working on the integration between the two.
Wow, these are the same people behind Pika/Skypack and Snowpack. I can remember the day when they announced the Astro project, and now it's joining Cloudflare, incredible progress.
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.
Yup, there's a lot of overlap especially with the HonoX framework that has island architecture as well!
I don’t want a framework that’s coupled to a hosting provider.
My favorite framework, and what has brought me much deeper into the world of web development. It's what I have used for me personal page https://bryanhogan.com/ . I'm happy to see it get funding, although I hope this doesn't introduce entshittification. So far I'm hopeful though.
It's the first framework I recommend to web dev beginners, after they have built something with plain HTML and CSS.
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...
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.
> CloudFlare is hardly "big tech"
yeah, it's still losing money
It's kind of past that phase, according to Gemini, it's a tax play:
The "No" (Non-GAAP & Free Cash Flow)
If you look at Non-GAAP (adjusted) figures—which many investors use to judge the actual "engine" of the business—Cloudflare is solidly profitable.
Adjusted Income: They reported a non-GAAP net income of $102.6 million for Q3 2025.
Cash Flow: Cloudflare is Free Cash Flow (FCF) positive. They are generating more cash from their operations than they are spending to keep the business running, reporting $75 million in FCF in their most recent quarter.
Why the difference?
The main reason Cloudflare still shows a "loss" on paper is Stock-Based Compensation (SBC). Like many high-growth tech companies, they pay a significant portion of employee salaries in stock rather than cash.
The GAAP view counts that stock as an expense (creating a "loss"). The Investor view often ignores it because it doesn't drain the company's bank account (showing "profit").
> according to Gemini
thanks for the unrequested slop!
you know what GAAP stands for?
"generally accepted accounting practices"
so what does non-gaap mean?
"non-generally accepted accounting practices"
aka: bullshit
> 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.
Refreshing to see an acquisition (acquihire?) that just plainly says they were not able to monetize.
Very unexpected but it's a great match. I have been using Astro with Cloudflare Pages and the dev UX is fantastic
Astro is my favorite way to build websites (at least, of the kind its great at) and I'm happy for the team; Cloudflare is a super cool place to work. Excited to see in what directions this will develop. They have a real shot at being the next Next.
From a developer perspecive, I was going to go "Ahh shit here we go again"
But to be really honest, thinking more about it. atleast from an "AI" bubble perspective, Cloudflare is pretty rock solid and isn't involved in the AI bubble deals whereas vercel has
If you were to use cloudflare workers say the past few months, you would've noticed some serious UI/UX improvements and its projects highlighted astro template was one of the first things (I think second was sveltekit iirc)
Anyways thinking about it now, I am sure that cloudflare must have been in talks with them for quite some time and they had the astro deployments on cloudflare workers so they must have seen its usage and other data we have no idea about to justify this purchase
That being said, I had been part of astro community almost exactly the time they had partnered up with turso (It was my holidays so I wanted to build a website from scratch, I sadly lost it but it was really cool and it had BMO from adventure time's pixel art that I lost oof :<)
So I was in their discord when they had just joined turso for astro DB and at that point, you couldn't host it locally (some tried with wasm) not sure what's the reality now though. But its interesting to see this because cloudflare offers a turso (serverless sqlite) alternative as Cloudflare D1, So we might see Astro shift to d1?
Once again, I have not been part of community for almost around 1-2 years so I don't know the current state of Astro aside from tweaking around making my own custom editor in bun for some astro templates (astro templates are really cool)
Perhaps, we are gonna see astro templates website + cloudflare workers to create an instant deployment of astro templates on cloudflare workers as a first class citizen. Honestly I would love that because cf workers/pages are free/cheapest in the whole market.
I hope that Astro still stays local first and still its serverless features can benefit everybody and not just cloudflare (looking at you vercel for nextjs)
Crazy how my Sveltekit app is running on Cloudflare Pages, and my Astro app is running on Vercel. But I appreciate them having these services to let us showcase our personal projects for free at least
I knew it was too good to last hah
Congratulations!
I hope CLoudflare or another tech company buy deno. Deno is great, its lacking a big brand sponsorship.
This is cool, I use astro when I just want to spin up a quick site without having to fight the framework (looking at you, Nextjs) and the main thing I disliked was the initiatives around paid extras they had going
Astro and Tanstack are probably the best full-stack routers these days, and Astro wins in terms of the wide support for almost any client-side tech
I use Astro deployed on Cloudflare, blog-newsletter kind of site [1], moved over from Hugo. If this keeps Astro viable then it seems like a net win.
[1] https://cto4.ai
Astro is great and I hope they keep improving after the acquisition.
Given what agents can do, I feel a lot of the sites built on Webflow, Framer and so on will move to code and Astro is a great framework for this.
Perfect direction! Astro has been incredible for small static pages. CF workers are also really easy to impl
After Netlify acquired GatsbyJS, I am not very hopeful about the future of Astro. I hope to be wrong because Astro is a great framework.
It still baffles me why Netlify did that. Gatsby seemed to have already been dying, even before the acquisition; and it didn't look like Netlify was planning to invest in it.
Netlify didn't buy Gatsby for the framework. They wanted the hosting business and the GraphQL thing. They said this at the time, and it's true. It was barely resourced. Cloudflare is only interested in the framework (because Astro has nothing else).
Source/disclosure: I worked at Gatsby, Netlify, Astro and Cloudflare
Why did they want Gatsby's graphQL thing? What was attractive about it?
Seemed a good idea at the time. The unified data layer was always the best thing about Gatsby (which is why I nicked the idea for the Astro content layer), but maybe not as a hosted product
Welp, I'm worried. I like Astro, but maybe it's time to make my own SSG, to not ever end up in the hand of a few big-sharks that consolidate and enshittify everything.
jumped on the same train, still using astro in production but on the side im using Elixir to create an SSG to use moving forward for anything new.
Fork it and call it Cosmo
Did they just break Cloudflare?
Astro is great. It checks all of my checkboxes. I hope this is not the beginning of the end.
Cloudflare: Astro Vercel: NuxtLabs, Next. All open source. What a strange competition.
Nice. I love astro and I love cloudflare. Most of my static pages are that stack.
So this is what happens to open source now? It runs out of money and one of the big corpos gobbles it up. Lovely.
I think donating to the Apache Foundation is preferable.
Damn. What alternatives does HN recommend?
I experimented a lot with bootstrapping React projects this past fall, and Astro was by far the least painful to use. Notably, it was the least goofy of all of the React starter kits to use for server API development.
HTML.
Unironically have been migrating my static pages (from Nextjs and Eleventy) to plain HTML and love it. Of course depends on your use case if that is feasible.
https://lume.land/ a good, straightforward SSG.
There's one other I've seen recently that looked good but I have misplaced the link
Mastering HTML, CSS and vanilajs.
Then one is pretty much safe from framework tides.
Eleventy, of course :-)
But why are you looking for alternatives already?
Dropped eleventy recently.
Disliked the templating solutions, the messy documentation, the loss in momentum, and liked a lot of the stuff (especially the tooling and principles) in astro.
Also strongly disliked how political eleventy got.
I just wanted a website, not a an internal debate about what I am potentially being absorbed into. I can vote, and spend money on donations, I don't need to enact change through my tech stack.
I'm not! Just preparing myself for the worst-case scenario and creating some bookmarks meanwhile.
Well, there's this other project that recently secured funding from a company that has a proven track record of supporting great open-source projects like Astro, TanStack, and Hono without trying to capture or lock anything down.
There's even an article about it somewhere.
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.
I mean, you have to have an .astro file if you want your route to be picked up, and then import and use React components in that file. IIRC, you cannot just directly use React.
Oh right, yeah I get what you're saying now. Indeed I think .astro templates make sense at the page level say to define a layout, and I actually like the syntax of stuffing the server js into a frontmatter style block, it's pretty nice.
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 ;-)
Substack only really makes sense if you want to monetize your content.
This sucks
Tried Astro after being utterly confused with Hugo templating and found it rather over-engineered. Went with 11tty instead and don't regret it.
Another open source framework likely be dead soon, what are the alternatives ?