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 will never use Cloudflare if I can help it, but this outcome is preferable to Astro becoming abandonware.
yeah, it's still losing money
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").
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
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)
From what I remember, you can't even run a NextJS app through vite?
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.
This is probably just an acquihire.
I think every deployment pipeline having it's own preferred UI framework (and CMS, and cloud-DB solution) makes a lot of sense.
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.
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.
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"
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
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.
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.
> They still don't support inter-island communication
Can't you just use standard DOM events for that on the client? This would work even pushing events from React to Vue to Vanilla.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?
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.
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!)
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/...
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.
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.
They would not if they had choice.
There's even an article about it somewhere.
But why are you looking for alternatives already?
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.
There's one other I've seen recently that looked good but I have misplaced the link
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.
Then one is pretty much safe from framework tides.
Source/disclosure: I worked at Gatsby, Netlify, Astro and Cloudflare
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.
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.
For example, here's all the code in the svelte integration: https://github.com/withastro/astro/tree/main/packages/integr...
When the client side interactivity is very contained and small in scope I also quite like just using plain JavaScript without a framework.
[1] https://cto4.ai
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.)
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."
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.
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.
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.
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.
https://andrewkelley.me/post/why-we-cant-have-nice-software....
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 think donating to the Apache Foundation is preferable.
> https://blog.cloudflare.com/open-source-all-the-way-down-upg...
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!
Now we just need Cloudflare to buy one of the DBaaS companies so they have a solid relational offering.
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!
It's the first framework I recommend to web dev beginners, after they have built something with plain HTML and CSS.
pier25•1h ago
I wonder if there will be some sort of collab between Hono and Astro given that Yusukue also works at Cloudflare.
upcoming-sesame•1h ago