Very nice to see these dev tools get an exit. e.g. I love `uv` and friends but did consider that perhaps dev tools are just a bad business and then no one will go into making that kind of stuff. Good exits means more of these tools.
I have only used Astro for toy stuff but it seemed neat. Congrats to the team.
EDIT: To put paid to the sidebar discussion below, yes I meant "for instance, consider `uv`; they might do these nice things and go nowhere but now that companies like Bun and Astro have gotten acquired, it demonstrates a future for others; therefore we will get more things like Astral's `uv` and so on". Hope that clarifies.
I don't think that's really clear. I think we could both defer to the OP clarifying.
For pedantry's sake: neither i.e. nor e.g. would be correct here. You want cf. ("conferatur") to invite a comparison; e.g. is when an example pertains to an instance. In this case uv would not pertain to the instance, because Astro is not Astral.
I agree! That's why I think it's probably just a confusion between entities. It doesn't make sense either as example or as a comparison (although IMO it makes more sense as the latter).
It's all good. Hardly matters. It was just becoming too big a discussion for something far too minor. Any frustration I had from being misunderstood (primarily self-directed) was alleviated from satvikpendem guessing correctly what I intended.
"e.g." isn't used correctly here. It's intended use is as a connector linking a clause to examples supporting that clause. You can't simply substitute "for example" with "e.g." anywhere in a sentence and expect it to function correctly.
Regardless, these Latin abbreviations best avoided entirely due to the surprising number of readers who don't understand them.
As someone who was perplexed, I've only heard perplex used in past tense (I was perplexed) so seeing "For the perplex" just made me confused as to what "perplex" meant and I had to do a further search to decipher this tree of comments haha
IMO saying a framework is a dev tool is like saying a cake mix is a cooking tool, because it allows you to be more productive when making a cake. Sure, if you look at it a certain way, it is correct. But that isn't the way the term is usually used.
It confused me as hell as my first thought was "oh great, astral.sh got bought by a large company, now we've eliminated the last obstacle to using uv in enterprise context" only to realize that it's another company with similar name.
I mean good for them, but it would be nice if the same happened to e.g. Astral (cf.).
I think DevTools can be a very good money maker… I wrote two apps that were basically dev tools and they were the biggest of my money makers. I think it’s easier to make money from dev tools that are “apps” than dev tools that are “fundamental technologies” though so it probably heavily depends on the type of dev tools…
It's probably also easier to make cottage-industry money from a single useful tool and some associated services/consulting than it is to turn the whole thing into a big company expected to do the hockey stick curve thing (eg Docker).
It'll be interesting to see where Astral ends up landing on that; afaik they have a small team and have only raised seed money, but who knows.
I don't know if it's easier. I definitely think it's better, but there can be a lure to VC money that puts a company like Docker on that path. There's a world where Docker is a small company earning individually good money but with no hockey stick curve, and I think that's more sustainable and ultimately better for them.
Maybe, but I think it could have made a small team very wealthy and successful much more than it did a large company.
It was obviously pitched as an ecosystem/platform play, like "the next vmware" or something, but there was never anything close to a real moat there. Running a registry involved a lot of storage and transfer costs plus spam/abuse management, and private registry was always going to be a better fit for being integrated with CI platforms and the like more than a standalone service with its own auth and billing concerns.
Then we'll finally be getting the world we deserve.
Decades of VC cash has trained developers to never pay for anything that powers their entire career like dev tools. The assumption is you can always squeeze some rich business customer that employs the dev.
If AI kills hiring of software engineers, then there's less devs inside businesses to sell to. So we can either pay for the products we use directly, or not have them at all.
It will take a decade to shift penny pinching behavioral habits of devs but slowly over time the market will correct itself. Chefs have always had to buy their own knives. This is good imo.
Who's to say there's no incentive. Anthropic using Bun internally is plenty incentive to make it better even if for their own use-case. I think it is a bit of a doomer perspective to think anything being bought out means the end of the line for that project. Sure, some things might change depending on the interests of the new owners but that's not to say it'll automatically become bad. Microsoft bought Github and Mojang, they're both doing better than ever for example
GitHub continues to become less and less usable (slower performance) while the number of features proliferate. On the one hand, being part of larger company _can_ relieve the pressure to stay profitable. But on the other hand, acquisitions tend to get cannibalized by the companies that acquire them. Profitability tends to become less and less aligned with usability.
Realistically to maintain a modern web framework to even a minimal standard you need a few people working fulltime on it, and more than a few if you want to take it places. There needs to be some kind of long term sustainable vehicle for funding those developers, either a corporate sponsor or a foundation.
So all those frameworks have to end up somewhere, and I’d rather it be somewhere else than vercel, as they already own way too much of the web frontend space.
> Very nice to see these dev tools get an exit. e.g. I love `uv` and friends but did consider that perhaps dev tools are just a bad business
I can't even begin to comprehend what kind of world view you need to have, to think that being bought out by some megacorp with an at-best 50/50 chance of continuing existing products is an accurate measure of a "good business", much less that its the only measure.
Dev tools that support an ecosystem of things. A dev tool by itself isn’t that valuable unless it’s a backbone of an ecosystem. Astro is. React is. TUI.js is not.
A brand - like charm bracelet - with dev tools is another avenue. Why build one when you can build dozens?
In the end it’s about providing value. Not novelty but value. Make your new overlords better or faster or make everyone better or faster. Provide a value that can be measured.
I’ve used Astro on Cloudflare for a few years for my personal website (username.com). They’ve both been absolutely fantastic, I can’t say enough good things about both of them. My website has all 100s on PageSpeed/Lighthouse, and that’s because of the performance focus of both Astro and Cloudflare. No credit to me at all. It was mainly because Astro prioritised shipping 0 JS unless it was absolutely necessary and Cloudflare is exceedingly good at serving static HTML.
But I also see the difficulty that Astro faced here. Despite being happy with the framework, I never paid for it. The paid offerings didn’t strike a chord with me. And it was partly because whatever they offered, Cloudflare already offered on a very generous free tier.
I'm glad the team have got a second life within Cloudflare,. I'm happy for the people who've given me such excellent software for free for years. Thanks folks!
Out of curiosity, how do you become ‘exceedingly good’ at serving static HTML?
By all accounts, they’ve centralised the delivery of this static HTML at several layers of the network stack, and you’re not getting static HTML anymore because some other part of the business fucked it up.
The World Wide Web was serving static HTML for decades before Cloudflare came along. Open an FTP client, drag and drop, and boom - new HTMl is served.
When we talk static HTML I think that still includes images, stylesheets and potentially even very basic javascript (e.g. setting classes). Those take advantage of CDNs; Cloudflare have an extensive CDN with decent latency / locations. They also are a DNS registrar and a lot of people use them for their local DNS provider so again latency benefits. That's before we talk about the DDoS protection, injecting stuff like metrics etc etc. I don't want to sound like a Cloudflare rep here but I can see where this user is coming from.
If your traffic volume stays well below server capacity, the network connection is impeccable and throughput isn't a major factor in ISP costs, then the improvement is indeed negligible.
However, if the server or it's network ever experience congestion or disruption, or you simply face sheer volume, that's when CDNs shine.
Regional caches insulate clients from network or performance issues with your server or its connection. If you have high volume, they also drastically reduce traffic through the backbone which can reduce ISP costs, depending on your contract.
Like others say, this really applies to all static content, including static media, css and js.
I hear you ask, "how can you be exceedingly good at this?" Caching itself isn't tricky, but catching efficiently and effectively at such huge scales is. The fact that Cloudflare offers these services for FREE, is a pretty good (perhaps Faustian) deal.
Likewise! I built my personal blog with Astro and host on Cloudflare (username.dev), and feel guilty about taking advantage of such excellent software and free tier. Here’s hoping they find a way to take my money soon.
I'm in the same boat as you. I've built a personal home page with Astro and hosted it on Cloudflare. It has been really cheap, only paying for worker subscription at 5 dollars per month. The site has been running non-stop essentially without downtime. And as you say the user experience of Astro's static HTML, css and minimal JS output on Cloudflare edge CDN network is really good.
But with the events of the world being what they are I have been considering moving my Astro page to BunnyCDN and thus Europe (where I live). The only Cloudflare specific feature I've used is D1 database so migrating now shouldn't be too difficult. I really hope Cloudflare does not make it difficult to use Astro on other providers, either intentionally or by accident. Next.js for a long time was essentially a framework that only ran great on Vercel, and using other providers was asking to become a second citizen. I believe it is somewhat better now with proper provider plugin system, but still.
Astro has been great and I understand they need to find a way to economically sustain their business. Joining a big company like Cloudflare is one way to do that. I can't complain too much never having opted to use Astro's commercial offerings. So I only hope they keep Astro open. I'm building a new product on top of Astro now and would hate to see it become a Cloudflare-only product.
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)
So when folks say they want to see big companies invest in open source, this is what that looks like. CF could have kept coasting on what Astro was building, but instead they are paying for it. But in return they get a lot of control.
Well, hopefully more like Go's relationship with Google? The company that pays the bills is their first and most important customer, but as far as I can tell from the outside, the Go team makes its own plans and management doesn't pull rank.
> CF could have kept coasting on what Astro was building, but instead they are paying for it. But in return they get a lot of control.
Supabase pioneered the modern implementation of this model. Probably, RedHat before it? Google also tend to "acquihire" maintainers of popular FOSS projects, like Ben Goodger (Firefox), Scott Remnant (Upstart), Junio Hamano (Git), Guido von Rossum (Python).
So, cloudification: lock the customer into a complex cloud dependent solution they can't easily migrate to some other commodity infrastructure provider.
I essentially do a 1 click deployment for my personal site with Cloudflare.
I don't want to deal with the cloud infra for my personal site.
I could, I've done it in corporate, I've done it for my startup 2 years ago.
But I'm rusty, I don't know what the latest people are using for configuration, etc.
Because there is 1 click with CF or Vercel and I don't have to think about it—I don't.
If they increase their price it likely wouldn't be enough friction for me dust off the rust.
I think this is the relation.
I'm not locked in, it's just HTML pages, but I am through my own habit energy, tech changing, and what I want to put effort into, which is not infra and serving my site.
They can stay open source, but stop putting any effort into supporting deploying to cloudflare's competitors, including accepting PRs for such improvements.
Or they could add features that only work if you deploy via cloudflare.
I also take anything said in an acquisition announcement with a grain of salt. It is pretty common for companies to make changes they said they wouldn't a few years after an acquisition.
Vercel does not make Next.js hard to deploy elsewhere. Next.js runs fine on serverful platforms like Railway, Render, and Heroku. I have run a production Next.js SaaS on Railway for years with no issues.
What Vercel really did was make Next.js work well in serverless environments, which involves a lot of custom infrastructure [0]. Cloudflare wanted that same behavior on CF Workers, but Vercel never open-sourced how they do it, and that is not really their responsibility.
Next.js is not locked to Vercel. The friction shows up when trying to run it in a serverless model without building the same kind of platform Vercel has.
Can you describe what you mean here? Because I have heard this about 100 times and never understood what people mean when they say this. I am hosting a NextJS site without Vercel and I had no special consideration for it.
Did YOU even bother to look at their site? They support more than static generation, including SSR and even API endpoints. That means Astro has a server that can run server-side (or serverless) to do more than static site generation, so it's not just a static site generator either.
And yes I can see you're posting the same lie all over the comments here.
They can say whatever they want, and then do whatever they want. They have no contractual or legal obligation.
Almost every (it seems) acquisition begins with saying, 'nothing will change and the former management will stay on'. A year later, the former managment leaves and things change dramatically.
That's always been true. Perhaps even more so as Astro constantly faced an existential battle for a working business. Now they don't have to do that and Cloudflare makes their money on their infra business. Locking Astro up now or in the future gains them very little compared to how much they make with hosted upsell services. [edit: clarity]
It's a static site builder. It creates a static site. HTML, CSS, and JS. That you can then upload literally anywhere.
Once again, what lock in? There is literally nothing to lock in. Explain exactly how they are going to lock somebody in, moreso than the lazy "for now" which you seem to constantly repeat.
No? It's still the same Astro that you can move to any other provider that supports it - and it's just Javascript, so pretty much everyone supports it.
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)
That doesn't sound too preposterous; I wouldn't assume you'd be able to run a React Router project on Turbopack or Webpack either, and Next.js I think has a way more intricate dependence on the bundler to power a significant chunk of its features.
Definitely irrational. There are lots of logical reasons to dislike Next (like the fact that they pile new shiny bit on top of new shiny bit without caring about the regular user experience) ... but being mad that it can't run on Vite is silly.
It's like being mad that Rails can't run on Python, or that React can't run on jQuery. Next already has its own build system, so of course it doesn't work with another build system.
Luckily DX is much better now with Turbopack as a bundler. First they improved the dev server, now with Turbo builds the production builds are faster as well. Still not fully stable in my opinion, but they will get there.
It's also wise to use monorepo orchestration with build caching like Turborepo.
They did well on the turbo stuff, no doubt about it.
The main bottleneck with big projects in my experience is Typescript. Looking forward to the Go rewrite. :)
I have a question. Why can't Whatsapp or Meta make a markdown INFO only website for small business owners (e.g. technicians, shopkeepers, handyman, etc) using their immense reach and clout. The method of using whatsapp groups to keep users updated of the latest updates is not scalable or open.
too big to deliver simple solutions? youre making way too much sense and this would die in committee or be replaced when someone new needs to justify themselves by launching a new product to supplant an existing one.
It does not read like marketing copy to me, what part of talking about draft PRs and framrworks sounds like marketing speak? They're right that CloudFlare having priority access to new Astro features is beneficial for them.
Not sure how to feel about this! I’ve been known to use em dashes every now and then, but I am indeed a fellow human.
I’m close to the vite plugin in particular and have contributed to multiple frameworks around cf integration (simply because I use cf), that’s why I chose it as an example (and it’s one of Astro 6’s biggest features)
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.
"Hey don't forget it's easy to deploy Astro on Cloudflare pages" with a link to the docs? I saw them mention deployments to Cloudflare (and continuing to support other platforms) but had to go look up what Cloudflare's platform is even called myself. Seems like a missed marketing opportunity.
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.
My god. Every time I touch Next.js in some project I think “hey, this actually doesn’t feel so bad to develop with, dare I say it feels nice?“ and every time I read about it I think “what the hell, this is the worst choice you can make“.
It’s wild that they’re somewhat taking the whole React ecosystem with them.
I don’t think so since they are using the worker model. My guess is that the first class support will go to that. Though they can do lockin differently (kv, queues, etc..)
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.
The "meltdown" where he refused to jump to the whims of Italy's football cartel and block whatever addresses they wanted without accountability or review? More meltdowns, please.
Cloudflare is bound to respect the laws of the countries it operates, and if he disagrees with the process, understandable, that was not the way to express it.
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.
Sometimes it is cheaper to buy a company than build the internal tool team you might have had to build from scratch anyway. Half acqui-hire, half knowing you've built something on-top of it and want it to stick around.
I also wouldn't be surprised if cloudflare wants to build this into their site-hosting capabilities.
I don't understand how Cloudflare's bottom line benefits:
Some here say they gain Astro users, that Cloudflare will become part of the default deployment. But given Cloudflare's current scale, how much are Astro's users worth? Is it even worth the distraction for Cloudflare? Companies lose energy to lots of small, low-value operations.
Most acquisitions begin with announcments that nothing will change, in order to retain customers and employees. They say '<acquistion> is so great, we don't want to interfere, and we're keeping existing management and letting them run things'. After the transition period - often 1 year - the old managers leave and the big changes happen, sometimes including shutting down the product because it was an acqui-hire all along or an IP acquisition.
It seems like Cloudflare must perceive some profit beyond what is announced.
It's very powerful to have ownership over a framework that many developers are familiar and like!
It might not be clear just yet what the path to monetization looks like but an easy example would be deeper integrations with the rest of the Cloudflare ecosystem (for example allowing R2 to be easily along with something like duckdb to live in a world of truly local analytics or something like that).
It seems like these great open source frameworks need to monetize by building a platform around the product but these days it's hyper competitive (ex. Vercel, Cloudflare) and it's hard to get started without an incredible differentiator. So, while monetizing independently as a company might be difficult, Astro can provide a lot of value to the rest of the Cloudflare ecosystem.
Why does Vercel provide Next.js? Aside from talent & tightly coupling Astro to their services, their North Star might be similar to Weekly Number of New Domains Hosted On Cloudflare. Sponsoring a framework that helps ship performant websites feeds into that metric.
Vercel is a platform that, simplified, sells compute by time and by query.
Static optimized sites take very little compute, and little queries.
Since they have the most used framework (nextjs), they made it more server-heavy and changed the paradigm to one where a single page is built up using multiple queries for even just the html.
They then made sure that self hosting that monstrosity is terribly complex for anything serious, and incompatible with the "serverless environment" of their own platform, unless you have devops maintaining it.
And then they severely overhauled the pricing and gimped the included limits. (We were on <1% usage before. And now at 95%< while changing nothing...)
It could of course be a coincidence, but if that were the case, they would be very bad, yet lucky, business people.
100% will never put anything new on vercel and have been avoiding nextjs like the plague.
Yeah I see the benefit right off the bat, this is a direct head to Vercel and NextJS.
With that said, I have no idea on the market share or profitability of any of that or Cloudflare vs Vercel.
Also perhaps the rails that will be put in place for seamless 1 click Astro deploy will continue to push them forward with other technologies as well, so it's not just about Astro.
I do feel that fear as well, is this an unnecessary distraction for CloudFlare? Time will tell.
vertical integration probably, if you sell web services helping people get to the point that they need them is worth
buying into something that becomes popular is good advertising for cheap (react is probably the only reason for any kind of goodwill at all towards facebook)
as a function of earnings this is a rounding error purchase for them
> 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.
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.
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).
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.
Islands is just a catchy name I guess. I always thought the markojs terms for it made sense, but are more technical / less catchy: they called it “full page hydration” -> everything needs to be delivered as js and “component level hydration” -> islands, only specific component sub-trees need to be hydrated.
Then “sub-component level hydration” would be resumability like in qwik where only events and their dependencies get serialised as client js.
Yeah. Well to their defense, it is probably to be understood as islands of interactivity lost in a sea of static elements.
The term is definitely more evocative.
You can do this with just about any programming language or scripting language that can render HTML on the server + plain HTML and JS. You could do this with PHP 30 years ago.
Yes and no, php didn’t give you any tools to manage this, most people writing php sites back in the day (including myself) were writing js that was coupled to a specific markup yet was maintained separately. This didn’t scale well.
Then along came libraries like mootools, knockout, etc all the precursors of react, then react changed the game around encapsulation of markup and code into one place, and straightforward data flow.
SPAs were inefficient so server side rendering of js became ubiquitous, islands are a further optimisation of ssr.
This hasn’t happened in a vacuum, if you look at modern php frameworks like inertia they have a lot more in common with Astro than they do the good old 90s php
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).
Here's a trivial example: https://supremecommander.ai. A raw CSS implementation of my blog's logo would have been a pain to build and maintain, but with Astro the code is relatively straightforward JS that becomes pure HTML/CSS at build-time.
The other nice thing is that you can throw all kinds of preexisting components from React/whatever into your site, and it will ship zero JS to the client until you explicitly flag a specific JS resource as an "island".
The only special thing about "islands" is that they're an escape hatch from the default behavior of JS being strictly build-time-evaluated. I found the terminology and description a little confusing at first too, because it makes it sound more special than it is. But the concept makes sense when you understand the context of Astro's intentional default behavior.
Good to know, thanks! I can't reproduce that on Android (and it's especially weird since the site has almost no JS), but I'll investigate and try to figure it out.
lol, well I'd appreciate the heads up even if it were meant to be aggressive, but thanks. Should be good now; the issue was most likely a CSS animation causing your browser tab to crash, so now it'll just turn off the animation whenever the page is quickly reloaded twice in a row.
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.
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).
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.
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.
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 have a preview release ready, if you scroll down you'll see the instructions. If you're able to try it out and leave a comment on whether it fixes your issue it'd be a big help.
Interesting. Do you just build web components instead of React/etc, and add the client:load and Astro gives you the static (fast) initial page load, and lazy loading of web components?
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 agree a good exit for devtools is good for devtools. I'd like to understand it better.
The Astro claim is that astro developers will all continue full-time on it. So why acquire it instead of supporting it?
The reason given in complementarity (content and infrastructure), but doesn't that mean that Cloudflare is moving into content? Perhaps it's fair to say some content fits better with Cloudflare, or making it easier to just have static sites is beneficial to Cloudflare?
Is there a convention about announcements, for the acquired to announce happily first to bring customers, and then the acquirer to confirm their benign intentions? When can we expect Cloudflare's take?
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.
Gatsby was sunset because it was a bad framework build on bad decisions [1]. I tried to use it when it was new, and it was immediately obvious that "GraphQL for everything" leads to horrible DX.
It was definitely a terrible DX, I remember having trouble wrapping my head around querying for blog posts inside my blog post component instead of receiving them as props. But I was using a custom F# + asp.net blog engine I'd written for what amounted to a static site, so I just switched to that Gatsby thing I'd been hearing a lot about at the time.
I had moved out from Gatsby to Astro on my blog/site (username.com), mostly because the enormous dependency hell full of security issues, I know it's just things to generate static files, but it was causing a lot of headaches to upgrade and remove the issues. With Astro, I receive a lot less issues and the maintenance is easier! From my perspective if Cloudflare keep it that way, it'll be a win.
> I had moved out from Gatsby to Astro on my blog/site (username.com), mostly because the enormous dependency hell full of security issues, I know it's just things to generate static files, but it was causing a lot of headaches to upgrade and remove the issues.
That's exactly what made me move to Astro. I would've been happy sticking with Gatsby since it still technically does what it says on the tin, but there were so many security warnings and issues with upgrading dependencies that I gave up.
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.
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!
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.
This is the main thing for me. If I can keep the cf workers backend in the same repo and deploy them together I will consider leaving Next.js for good.
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.
Been running my technical knowledge base on Astro for about a year now (ketankhairnar.com). Congrats to the team on the acquisition - here's what stood out from a product/engineering perspective:
Content modeling that actually scales. Built a three-tier system: Concepts (foundational knowledge) → Deep Dives (series-based learning paths) → Systems (production case studies). Each concept tracks prerequisites, related topics, interview relevance by level (L5-L8), and links back to which deep dives use it. Zod validates everything at build time. This isn't a blog template - it's a knowledge graph with static output.
Islands architecture delivers on its promise. React hydrates only for search (Fuse.js across all content types) and a few interactive bits. Rest is zero-JS HTML. Coming from years of Next.js, the bundle size difference is stark. Users on flaky mobile connections notice.
Extensibility without framework lock-in. Wrote a custom Shiki transformer for ASCII diagram highlighting - ERROR renders red, FIX green, DECISION orange. Dynamic OG images generated at build via Satori+Resvg. No Lambda cold starts, no external services, just static assets. Infra cost: basically zero.
View Transitions shipped before others figured it out. One import, smooth page transitions. Small detail, big UX lift.
Where it gets tricky: Complex content relationships require multiple getCollection() calls and manual joins. Works fine, but a query builder would help for sites with heavy cross-linking. Also, the content layer is powerful but documentation assumes simpler use cases.
Product observation: Astro found a real gap - content sites that need occasional interactivity but don't want SPA overhead. Most frameworks optimize for apps and retrofit content. Astro did the opposite and it shows.
Curious how Cloudflare integration plays out. Edge rendering + this content model could be interesting for personalization without sacrificing static performance.
I love astro, it's been such a pleasure to use and totally solved my need for a flexible platform. I managed to retire a bunch of Wordpress sites and I've never looked back. Hopefully I can still run it on netlify.
I noticed the astro docs has lot of mention of Cloudflare worker as well, is there any reason why you didnt go with Cloudflare pages instead? I’d have guessed pages would be the perfect fit for hosting a rendered astro website
D1 is fine when it fits the use case, but most of the time I just want Postgres that I will use for absolutely everything. It has happened often enough that I have tried to make systems work with other storage systems, and eventually just give up and revert to Postgres. Every time I just start with Postgres I don't have issues until it turns out my laziness has caused a performance problem, and those I can fix.
Big difference is that Anthropic blocks competitors from using its products (they literally cut direct api access. Or even through 3rd party like Cursor).
All wrongs in Gatsby have been gotten right in Astro. What will happen next remains to be seen, but currently Astro is amazing for a few specific cases it covers. The performance, developer experience and documentation are all great.
Hope that SSR remains first class as time goes on. I think Astro’s DX is superb overall, and am bullish on server-rendered components in MPAs with a sprinkling of hypermedia libs for better UX.
Some features of my SSR-based side project feel like I had to hack them on, such as a hook that runs only on app start (hacked in via middleware) or manually needing to set cache control headers for auth’d content.
All in all, really happy with it. And it isn’t next.js.
This was inevitable. We're seeing the "Vercel-ification" of the edge. For a long time, Cloudflare had the superior infrastructure (Workers, R2, KV), but lacked the cohesive "onramp" that Next.js provides for Vercel. By acquiring Astro, Cloudflare finally owns the full stack, from the local dev experience to the global edge delivery.
The real question is whether Cloudflare can maintain Astro's "framework agnostic" soul while being incentivized to push everyone toward Workers/Pages.
I have always liked Astro. It also works great with AI tools since its combination of markdown and code. Was able to vibe code a quick blog template and deploy to cloudflare in minutes with an existing headless backend - https://sleekcms-astro-blog.pages.dev/
So.. just because a tool can be potentially mishandled (e.g. put in the hands of a toddler, which is basically what vibe code ends up being) because it's easy to use, you never want to take a look at said tool?
That sounds like shooting yourself in the foot out of pure spite, but you do you.
Astro is enabling vibe coders with a section of the documentation that gives advice on using AI, an Astro docs MCP server, and a copy of the documentation that is specifically formatted for LLM use.
This is a great news for Astro. It ticks all the boxes when being used to build heavy content and SEO driven websites. I've been using (Astro + Cloudflare workers/pages) as my go-to stack to build my Java gamedev resources website [1] and gaming portal [2], so far and the experience is very positive. Deploying static files to Cloudflare edges feels natural and frictionless.
Still a bit concerned that it might be too tempting to build an entire website infrastructure around cloudflare, which is a single point of failure. But there is really no better alternatives at the moment. I tried self-hosting but eventually resorted to cloudflare because of bad bots, ai, scrappers kept hammering on my sites.
About the download stats for open source frameworks and libraries.. I keep reading claims of "millions of weekly downloads" -- surely this is a noisy metric, right?
NPM just counts GET requests. A significant number of those must be from CI/CD pipelines, mirrors, build servers, etc.
It still signals popularity, but probably to a much lesser degree than implied.
How to measure the popularity of FOSS projects though?
Number of downloads? Number of stars on GH? Number of content on social medias?
The absolute value is meaningless in itself, but there's a big difference between a library that is downloaded a thousand or millions of times each week.
That's the idea.
Meanwhile for-profit projects have actual customers or revenues to demonstrate popularity.
VC still use github stars as a viable metric, at some point you have to say aloud that they are basically engaging in shammanism and ritual sacrifices.
Cloudflare's goal is to become the default choice for anyone deploying an app to the cloud. It makes sense for them to support popular frameworks such as Astro, so that they can ensure that the frameworks work very well on their Workers platform.
Anyone except users that need to serve the German market. Due to peering issues with the biggest German ISP that have been unresolved for years, websites hosted with Cloudflare simply don’t load in the evening.
Adobe could have benefited from doing this acquisition but they can be somewhat forgiven as they are already pushing Edge Delivery Services which is based in NextJS although it's a different approach. Combined with the Universal Editor they have a solid headless authoring setup for enterprise CMS.
But I really feel like Akamai is who dropped the ball here, this was a low hanging fruit for them and they're lacking offering this capability to offer their corporate clients as they transition to full headless. Now it's going to be their competition (Cloudflare, even Fastly through Adobe & the EDS push) who will try to take a portion of their cake.
I've been using Astro for a couple years and it's delightful. I actually started using it for my docs because I saw Cloudflare was using it. I hope they are a good steward of the tech!
Oh no. This isn’t good. I’m glad that the team gets a payout but as an Astro user I don’t love it being owned by CF and that the goals of the project (at least indirectly) goes from the best way to deploy it to the best way to deploy it using CF.
I don't anticipate it changing like that. You still do a build using Vite and deploy the static assets. How could they change that to make it difficult to host elsewhere?
Let’s hope you’re right. I think vendor lock in is possible if they focus on features tightly coupled to Cloudflare. Look at Next.js. In theory you can deploy it anywhere, but in practice it is harder outside Vercel because of tight coupling around things like caching. You do not have to use those features, but if the framework is built to expect them, it pushes people into that platform. I can imagine Astro becoming very attractive to use with Cloudflare Workers and slowly locking people into that model.
It is not similar imho. First NextJS build system is not really exposed apart from a simple docker example and all advanced features of NextJS is kinda coupled to Vercel. For Astro it is just a Vite project with integration designed from day mind they would have to rip everything apart and that would probably cause a prominent fork. The other part is Cloudflare is not dependent Astro being vendor locked as much as Vercel being dependent on NextJS being vendor locked.
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.
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.
Astro is my favorite framework for static sites. It's hard to describe but it just "makes sense". You don't need complex build setups and you can get the best of all worlds with great SSG capabilities + can easily express things with React when needed for example.
I wish there was another path to monetization besides joining a larger company but I'm happy that the team will get to continue building out an amazing framework!
I found that Vite does a great job of deploying static websites. All I had to do was add Vite as a dev dependency in my pacakge.json and make sure all the page routes in vite.config.js.
I've been skeptical about trying Astro because it seems to have unnecessary complexity. Also, I don't see any evidence that Cloudflare is going to prioritize making Astro easier to use.
Yeah, I agree on the AI front. Although outside of the AI page, I don't believe we have other content on it. It was intentional to keep it separate from the rest of the docs. I know we've recently discussed making changes / removing some of that content.
I love web components (one of the things that got me into Astro), but it can be helpful to reach for something like Solid when you get into more complex UI. Most Astro projects will never need to reach for that, which is why there's no UI framework available by default.
Astro definitely tries to stick to a minimal defaults approach by design. We'd rather people start from a simple, minimal boilerplate, and reach for solutions (e.g. UI frameworks, on-demand rendering) only when they run into a problem it solves.
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
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)
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
Wow, amazing news. At Themefisher, we’ve built 40+ Astro templates used by hundreds of Astro devs and many client sites. Also great to hear it was Cloudflare!!
Hope Astro keeps growing.
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.
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.
If you want some precedent look at Hono. Initially it was just for the CF Workers runtime (not developed by CF). Then CF started using Hono internally and hired the dev to work on Hono full time. Hono works on any JS runtime.
I suppose we’ll see — I’d be surprised if the whole promise of nothing will change don’t hold over the long term. I don’t love that Astro is tied to a narrow set of hosting providers either.
Congrats to Fred and team! Developing and maintaining a complex framework takes lots of funding, and I’m glad Astro found a new home that provides that.
With [Mastro], we have a different approach. The name originally stood for "minimal Astro", and we’re staying true to that. At just ~700 lines of TypeScript, Mastro will always be easily maintainable – even if by just a single person. And it's amazing how much you can do if you're very deliberate in your API's design.
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
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.
First, it doesn't have any provisions for code reuse. So, if you have multiple pages that use the same header, same footer, or same navigation menu, your options are either to copy-paste it (gross), or to build the final html out of smaller pieces, at which point you've reinvented either a static site generator or a web server.
Second, if you write long stretches of text, the html markup can get in the way, as opposed to unobtrusiveness of something like markdown.
Yea I think I’ll write my own static generator that just combines 3 templates for header/body/footer and converts markdown from the body.
Should be fun project.
I’m tired of the constant update pressure from existing solutions and I only need something dead simple.
> at which point you've reinvented either a static site generator ...
It doesn't have to be Astro though. You can build something super simple that just includes the header, footer, and nav. Leaving most of the site as plain HTML.
How would this help? You would want your header render on the server, wouldn't you? Not to incur a CLS penalty, right? How does a web component help in this scenario?
Same, and I was starting to feel kind of strange doing anything in html/php in 2026 but then I looked at everything else and realized I'd have to start from scratch again. Plain ol' HTML has worked great.
I recently rebuilt my site with Parcel + React Server Components. RSC are designed to solve many of the same problems that Astro does. And Parcel is “just” a bundler and not a framework, so it has less magic and gives you more control.
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.
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.
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.
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.
This spam LLM account "MarkusAllen" (towards the very end) could be used by an adversory to discredit books / courses /"youtube channel" they link to. This is reverse psychology attack vector made possible by an LLM.
ITT People arguing about how cloudflare is gonna unfairly favor their own platform and lock people in by making easier to deploy astro sites as if you can't already do it just by connecting a git repo to cloudflare pages with 1 click.
i'd personalloy love a quick video demo on the home screen, with someone walking through the experience of using the app; other than that, looks interesting;
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.
You become beholden to these platforms and they're inherently not portable. There is risk here, and given the track record of Internet companies I think it's fair to say the risk is not worth it for many people.
Your costs could explode, or worse, the business could go under and you lose all your shit.
It's very simple to use. I tried a few static site generators and Astro gave me the most freedom and was the most approachable, pretty much no learning curve. You can use it with MULTIPLE web frameworks at the same time so it's pretty damn great. It gives you many options to do one thing so you can do things your way which is a delight for tinkerers
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.
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.
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.
> 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.
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.
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.
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.
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.
Very nice to see these dev tools get an exit. e.g. I love `uv` and friends but did consider that perhaps dev tools are just a bad business and then no one will go into making that kind of stuff. Good exits means more of these tools.
I have only used Astro for toy stuff but it seemed neat. Congrats to the team.
EDIT: To put paid to the sidebar discussion below, yes I meant "for instance, consider `uv`; they might do these nice things and go nowhere but now that companies like Bun and Astro have gotten acquired, it demonstrates a future for others; therefore we will get more things like Astral's `uv` and so on". Hope that clarifies.
This is Astro, not Astral. uv is Astral :-)
Edit: OP clarified what they meant, I'm sorry for the misunderstanding on my part!
They know, hence why they used e.g., i.e. exempli gratia
I don't think that's really clear. I think we could both defer to the OP clarifying.
For pedantry's sake: neither i.e. nor e.g. would be correct here. You want cf. ("conferatur") to invite a comparison; e.g. is when an example pertains to an instance. In this case uv would not pertain to the instance, because Astro is not Astral.
cf. would invite a fair bit of confusion on an article about cloudflare
I agree! That's why I think it's probably just a confusion between entities. It doesn't make sense either as example or as a comparison (although IMO it makes more sense as the latter).
(For the OP: I'm sorry if I misinterpreted you.)
It's all good. Hardly matters. It was just becoming too big a discussion for something far too minor. Any frustration I had from being misunderstood (primarily self-directed) was alleviated from satvikpendem guessing correctly what I intended.
"e.g." IS correct because uv is an example or instance of a dev tool.
"e.g." isn't used correctly here. It's intended use is as a connector linking a clause to examples supporting that clause. You can't simply substitute "for example" with "e.g." anywhere in a sentence and expect it to function correctly.
Regardless, these Latin abbreviations best avoided entirely due to the surprising number of readers who don't understand them.
For the perplex:
e.g. is latin for "exempli gratia" = for example i.e. is latin for "id est" = that is
As someone who was perplexed, I've only heard perplex used in past tense (I was perplexed) so seeing "For the perplex" just made me confused as to what "perplex" meant and I had to do a further search to decipher this tree of comments haha
Ha, ha, sorry. English is not my native language.
A good way to remember it is to use a backronym:
e.g. - example given
i.e. - in effect
i.e. - in eother (words)
in explanation
I'm not sure. I wouldn't generally call Astro a "dev tool". It's more of a framework.
It's possible you are right, but it isn't clear from the content of the comment.
Frameworks are a category of development tool. Things that developers utilitise to be productive.
IMO saying a framework is a dev tool is like saying a cake mix is a cooking tool, because it allows you to be more productive when making a cake. Sure, if you look at it a certain way, it is correct. But that isn't the way the term is usually used.
Like coffee?
It confused me as hell as my first thought was "oh great, astral.sh got bought by a large company, now we've eliminated the last obstacle to using uv in enterprise context" only to realize that it's another company with similar name.
I mean good for them, but it would be nice if the same happened to e.g. Astral (cf.).
I think DevTools can be a very good money maker… I wrote two apps that were basically dev tools and they were the biggest of my money makers. I think it’s easier to make money from dev tools that are “apps” than dev tools that are “fundamental technologies” though so it probably heavily depends on the type of dev tools…
It's probably also easier to make cottage-industry money from a single useful tool and some associated services/consulting than it is to turn the whole thing into a big company expected to do the hockey stick curve thing (eg Docker).
It'll be interesting to see where Astral ends up landing on that; afaik they have a small team and have only raised seed money, but who knows.
I don't know if it's easier. I definitely think it's better, but there can be a lure to VC money that puts a company like Docker on that path. There's a world where Docker is a small company earning individually good money but with no hockey stick curve, and I think that's more sustainable and ultimately better for them.
I suppose they might disagree, of course :)
Docker was not gonna make it as a small individual tool as something podman like would get traction in that market.
Maybe, but I think it could have made a small team very wealthy and successful much more than it did a large company.
It was obviously pitched as an ecosystem/platform play, like "the next vmware" or something, but there was never anything close to a real moat there. Running a registry involved a lot of storage and transfer costs plus spam/abuse management, and private registry was always going to be a better fit for being integrated with CI platforms and the like more than a standalone service with its own auth and billing concerns.
i'm interpreting this in the reverse
if dev tools can only be "monetized" by being bought out, it does not feel sustainable on any level
we will see companies attempt to do things like close source these projects, go subscription based, or just straight up drop support
there is no incentives for cloudflare to make astro better, or even keep it around
same goes with bun, svelte, and i'm sure countless others
Then we'll finally be getting the world we deserve.
Decades of VC cash has trained developers to never pay for anything that powers their entire career like dev tools. The assumption is you can always squeeze some rich business customer that employs the dev.
If AI kills hiring of software engineers, then there's less devs inside businesses to sell to. So we can either pay for the products we use directly, or not have them at all.
It will take a decade to shift penny pinching behavioral habits of devs but slowly over time the market will correct itself. Chefs have always had to buy their own knives. This is good imo.
Who's to say there's no incentive. Anthropic using Bun internally is plenty incentive to make it better even if for their own use-case. I think it is a bit of a doomer perspective to think anything being bought out means the end of the line for that project. Sure, some things might change depending on the interests of the new owners but that's not to say it'll automatically become bad. Microsoft bought Github and Mojang, they're both doing better than ever for example
GitHub continues to become less and less usable (slower performance) while the number of features proliferate. On the one hand, being part of larger company _can_ relieve the pressure to stay profitable. But on the other hand, acquisitions tend to get cannibalized by the companies that acquire them. Profitability tends to become less and less aligned with usability.
GitHub is without question worse for users now.
Realistically to maintain a modern web framework to even a minimal standard you need a few people working fulltime on it, and more than a few if you want to take it places. There needs to be some kind of long term sustainable vehicle for funding those developers, either a corporate sponsor or a foundation.
So all those frameworks have to end up somewhere, and I’d rather it be somewhere else than vercel, as they already own way too much of the web frontend space.
that very much depends on your definition of "modern web framework".
> there is no incentives for cloudflare to make astro better, or even keep it around
There is - to counter NextJs. NextJs is a pain to host outside Vercel and makes Cloudflare lose customers. In theory that's why Gatsby was bought out.
> same goes with bun, svelte, and i'm sure countless others
Svelte was also taken over by Vercel. To control frontend hosting. Bun isn't in the same bucket. There isn't such competition going on.
> Very nice to see these dev tools get an exit. e.g. I love `uv` and friends but did consider that perhaps dev tools are just a bad business
I can't even begin to comprehend what kind of world view you need to have, to think that being bought out by some megacorp with an at-best 50/50 chance of continuing existing products is an accurate measure of a "good business", much less that its the only measure.
> Very nice to see these dev tools get an exit...
You'll see a lot more in the next 12 months ;)
yeah the thing about dev tools is that devs love writing them and your market is just devs
Dev tools that support an ecosystem of things. A dev tool by itself isn’t that valuable unless it’s a backbone of an ecosystem. Astro is. React is. TUI.js is not.
A brand - like charm bracelet - with dev tools is another avenue. Why build one when you can build dozens?
In the end it’s about providing value. Not novelty but value. Make your new overlords better or faster or make everyone better or faster. Provide a value that can be measured.
I’ve used Astro on Cloudflare for a few years for my personal website (username.com). They’ve both been absolutely fantastic, I can’t say enough good things about both of them. My website has all 100s on PageSpeed/Lighthouse, and that’s because of the performance focus of both Astro and Cloudflare. No credit to me at all. It was mainly because Astro prioritised shipping 0 JS unless it was absolutely necessary and Cloudflare is exceedingly good at serving static HTML.
But I also see the difficulty that Astro faced here. Despite being happy with the framework, I never paid for it. The paid offerings didn’t strike a chord with me. And it was partly because whatever they offered, Cloudflare already offered on a very generous free tier.
I'm glad the team have got a second life within Cloudflare,. I'm happy for the people who've given me such excellent software for free for years. Thanks folks!
Out of curiosity, how do you become ‘exceedingly good’ at serving static HTML?
By all accounts, they’ve centralised the delivery of this static HTML at several layers of the network stack, and you’re not getting static HTML anymore because some other part of the business fucked it up.
The World Wide Web was serving static HTML for decades before Cloudflare came along. Open an FTP client, drag and drop, and boom - new HTMl is served.
When we talk static HTML I think that still includes images, stylesheets and potentially even very basic javascript (e.g. setting classes). Those take advantage of CDNs; Cloudflare have an extensive CDN with decent latency / locations. They also are a DNS registrar and a lot of people use them for their local DNS provider so again latency benefits. That's before we talk about the DDoS protection, injecting stuff like metrics etc etc. I don't want to sound like a Cloudflare rep here but I can see where this user is coming from.
The biggest advantage? Regional caches.
If your traffic volume stays well below server capacity, the network connection is impeccable and throughput isn't a major factor in ISP costs, then the improvement is indeed negligible.
However, if the server or it's network ever experience congestion or disruption, or you simply face sheer volume, that's when CDNs shine.
Regional caches insulate clients from network or performance issues with your server or its connection. If you have high volume, they also drastically reduce traffic through the backbone which can reduce ISP costs, depending on your contract.
Like others say, this really applies to all static content, including static media, css and js.
I hear you ask, "how can you be exceedingly good at this?" Caching itself isn't tricky, but catching efficiently and effectively at such huge scales is. The fact that Cloudflare offers these services for FREE, is a pretty good (perhaps Faustian) deal.
If everything is static, they'll cache it in a DC close to you. That's better than what we had before.
Likewise! I built my personal blog with Astro and host on Cloudflare (username.dev), and feel guilty about taking advantage of such excellent software and free tier. Here’s hoping they find a way to take my money soon.
I'm in the same boat as you. I've built a personal home page with Astro and hosted it on Cloudflare. It has been really cheap, only paying for worker subscription at 5 dollars per month. The site has been running non-stop essentially without downtime. And as you say the user experience of Astro's static HTML, css and minimal JS output on Cloudflare edge CDN network is really good.
But with the events of the world being what they are I have been considering moving my Astro page to BunnyCDN and thus Europe (where I live). The only Cloudflare specific feature I've used is D1 database so migrating now shouldn't be too difficult. I really hope Cloudflare does not make it difficult to use Astro on other providers, either intentionally or by accident. Next.js for a long time was essentially a framework that only ran great on Vercel, and using other providers was asking to become a second citizen. I believe it is somewhat better now with proper provider plugin system, but still.
Astro has been great and I understand they need to find a way to economically sustain their business. Joining a big company like Cloudflare is one way to do that. I can't complain too much never having opted to use Astro's commercial offerings. So I only hope they keep Astro open. I'm building a new product on top of Astro now and would hate to see it become a Cloudflare-only product.
Congratulations to the Astro team!
I appreciate your honest testimonial. It's so rare these days to read a sentence like, "No credit to me at all" haha
amazing performance.
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)
So when folks say they want to see big companies invest in open source, this is what that looks like. CF could have kept coasting on what Astro was building, but instead they are paying for it. But in return they get a lot of control.
Well, hopefully more like Go's relationship with Google? The company that pays the bills is their first and most important customer, but as far as I can tell from the outside, the Go team makes its own plans and management doesn't pull rank.
You know this because you work on the Go team or part of google management?
> as far as I can tell from the outside
Anyone with actual knowledge, feel free to chime in.
Definitely!
> CF could have kept coasting on what Astro was building, but instead they are paying for it. But in return they get a lot of control.
Supabase pioneered the modern implementation of this model. Probably, RedHat before it? Google also tend to "acquihire" maintainers of popular FOSS projects, like Ben Goodger (Firefox), Scott Remnant (Upstart), Junio Hamano (Git), Guido von Rossum (Python).
So, cloudification: lock the customer into a complex cloud dependent solution they can't easily migrate to some other commodity infrastructure provider.
The easier/convenient a cloud makes it for a business to use, the more the industry will continue to trend towards lock in
I don't see the relation between those two
I essentially do a 1 click deployment for my personal site with Cloudflare.
I don't want to deal with the cloud infra for my personal site.
I could, I've done it in corporate, I've done it for my startup 2 years ago. But I'm rusty, I don't know what the latest people are using for configuration, etc.
Because there is 1 click with CF or Vercel and I don't have to think about it—I don't. If they increase their price it likely wouldn't be enough friction for me dust off the rust.
I think this is the relation. I'm not locked in, it's just HTML pages, but I am through my own habit energy, tech changing, and what I want to put effort into, which is not infra and serving my site.
What lock in? They explicitly said:
> Staying open to all was a non-negotiable requirement for both us and for Cloudflare.
They have deployment guides for practically every provider out there: https://docs.astro.build/en/guides/deploy/
And at the end of the day, most of the deployment is just deploying a static site... Which you can do practically anywhere.
They can stay open source, but stop putting any effort into supporting deploying to cloudflare's competitors, including accepting PRs for such improvements.
Or they could add features that only work if you deploy via cloudflare.
I also take anything said in an acquisition announcement with a grain of salt. It is pretty common for companies to make changes they said they wouldn't a few years after an acquisition.
Once again, it’s a static site builder. How, exactly, would they “stop supporting deploying to cloudflare’s competitors”? Be specific.
The same ways Vercel makes it harder to deploy Next.js sites to competitors or for self hosting.
Vercel does not make Next.js hard to deploy elsewhere. Next.js runs fine on serverful platforms like Railway, Render, and Heroku. I have run a production Next.js SaaS on Railway for years with no issues.
What Vercel really did was make Next.js work well in serverless environments, which involves a lot of custom infrastructure [0]. Cloudflare wanted that same behavior on CF Workers, but Vercel never open-sourced how they do it, and that is not really their responsibility.
Next.js is not locked to Vercel. The friction shows up when trying to run it in a serverless model without building the same kind of platform Vercel has.
0. https://www.youtube.com/watch?v=sIVL4JMqRfc
So it is vendor locked by Vercel. That's why there is OpenNext - https://opennext.js.org/
How is it vendor locked?
Recent features are more dependent on Vercel and it's OpenNext that makes it platform independent with adapters.
Can you describe what you mean here? Because I have heard this about 100 times and never understood what people mean when they say this. I am hosting a NextJS site without Vercel and I had no special consideration for it.
Next.js isn't just a static site generator.
Astro isn't just a static site generator either. Not sure what your point is.
[flagged]
Did YOU even bother to look at their site? They support more than static generation, including SSR and even API endpoints. That means Astro has a server that can run server-side (or serverless) to do more than static site generation, so it's not just a static site generator either.
And yes I can see you're posting the same lie all over the comments here.
Stop being a potty mouth.
They can say whatever they want, and then do whatever they want. They have no contractual or legal obligation.
Almost every (it seems) acquisition begins with saying, 'nothing will change and the former management will stay on'. A year later, the former managment leaves and things change dramatically.
Yeah. For now.
That's always been true. Perhaps even more so as Astro constantly faced an existential battle for a working business. Now they don't have to do that and Cloudflare makes their money on their infra business. Locking Astro up now or in the future gains them very little compared to how much they make with hosted upsell services. [edit: clarity]
It's a static site builder. It creates a static site. HTML, CSS, and JS. That you can then upload literally anywhere.
Once again, what lock in? There is literally nothing to lock in. Explain exactly how they are going to lock somebody in, moreso than the lazy "for now" which you seem to constantly repeat.
No? It's still the same Astro that you can move to any other provider that supports it - and it's just Javascript, so pretty much everyone supports it.
For now.
> 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)
Wasn't this a decision made by Vercel to incentivize people using Vercel for NextJS apps? I can't recall.
It's gotten a lot better since last year with OpenNext. Last I tested was Next.js 15 though. Who knows what Vercel has broken with Next.js 16.
https://opennext.js.org/cloudflare
That doesn't sound too preposterous; I wouldn't assume you'd be able to run a React Router project on Turbopack or Webpack either, and Next.js I think has a way more intricate dependence on the bundler to power a significant chunk of its features.
This is insane to me, and validates my irrational dislike of next.
Definitely irrational. There are lots of logical reasons to dislike Next (like the fact that they pile new shiny bit on top of new shiny bit without caring about the regular user experience) ... but being mad that it can't run on Vite is silly.
It's like being mad that Rails can't run on Python, or that React can't run on jQuery. Next already has its own build system, so of course it doesn't work with another build system.
Isn’t the next.js build system known for being slow/memory hungry?
Luckily DX is much better now with Turbopack as a bundler. First they improved the dev server, now with Turbo builds the production builds are faster as well. Still not fully stable in my opinion, but they will get there.
It's also wise to use monorepo orchestration with build caching like Turborepo.
They did well on the turbo stuff, no doubt about it.
The main bottleneck with big projects in my experience is Typescript. Looking forward to the Go rewrite. :)
For those stuck in the past yes, they have replaced it with a Rust based toolchain, as is so fashionable nowadays.
100% rational. Nuxt/Astro FTW.
I use Astro so I could make my blog a static site and deploy it to Cloudflare pages.
I was impressed since I got interactive compilation and state tracking of how many exercises the user completed.
https://jjmarr.com/blog/structured-bindings-structs/
I have a question. Why can't Whatsapp or Meta make a markdown INFO only website for small business owners (e.g. technicians, shopkeepers, handyman, etc) using their immense reach and clout. The method of using whatsapp groups to keep users updated of the latest updates is not scalable or open.
too big to deliver simple solutions? youre making way too much sense and this would die in committee or be replaced when someone new needs to justify themselves by launching a new product to supplant an existing one.
Because they much rather have those small businesses use a Facebook page for that purpose, which is the status quo in the West.
This reads like marketing copy. Maybe it reflects your actual feelings but it's hard to imagine that if you don't write like a human.
It does not read like marketing copy to me, what part of talking about draft PRs and framrworks sounds like marketing speak? They're right that CloudFlare having priority access to new Astro features is beneficial for them.
Not sure how to feel about this! I’ve been known to use em dashes every now and then, but I am indeed a fellow human.
I’m close to the vite plugin in particular and have contributed to multiple frameworks around cf integration (simply because I use cf), that’s why I chose it as an example (and it’s one of Astro 6’s biggest features)
What a bizarre comment. What part of it was "not human" in your opinion?
It's obvious when you look at https://astro.build/blog/astro-6-beta/ and see "Cloudflare" sprinkled everywhere in the article.
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.
Why did you expect info about deploying Astro to Cloudflare Pages? It's been supported for a long time already.
Seems like an obvious thing to call out for people (like me) who don't know.
So something like "now that we own Astro, all of you using Netlify should start migrating to Cloudflare Pages"?
"Hey don't forget it's easy to deploy Astro on Cloudflare pages" with a link to the docs? I saw them mention deployments to Cloudflare (and continuing to support other platforms) but had to go look up what Cloudflare's platform is even called myself. Seems like a missed marketing opportunity.
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.
My god. Every time I touch Next.js in some project I think “hey, this actually doesn’t feel so bad to develop with, dare I say it feels nice?“ and every time I read about it I think “what the hell, this is the worst choice you can make“.
It’s wild that they’re somewhat taking the whole React ecosystem with them.
Following your link, the fault for this appears to lie entirely with Vercel management.
Cross fingers that CloudFlare never try similar lock-in games, now that they control Astro?
I don’t think so since they are using the worker model. My guess is that the first class support will go to that. Though they can do lockin differently (kv, queues, etc..)
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.
Cloudflare definitely gets positive PR out of this which makes people forget their CEO's recent meltdown on twitter.
The "meltdown" where he refused to jump to the whims of Italy's football cartel and block whatever addresses they wanted without accountability or review? More meltdowns, please.
A meltdown is a meltdown.
Cloudflare is bound to respect the laws of the countries it operates, and if he disagrees with the process, understandable, that was not the way to express it.
You get what you pay for with free PR commentary.
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.
"I don't care, it's a stupid question."
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.
Sometimes it is cheaper to buy a company than build the internal tool team you might have had to build from scratch anyway. Half acqui-hire, half knowing you've built something on-top of it and want it to stick around.
I also wouldn't be surprised if cloudflare wants to build this into their site-hosting capabilities.
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.
Mindshare with developers is what cloudflare gets
Probably better support for CF Workers/Pages and better integration with Wrangler.
https://www.tumblr.com/ourincrediblejourney
This is probably just an acquihire.
Advertise their solution? Now astro can put them into the main deploying option and that's a good way for cloudfare to acquire new customers
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.
VMware maintained spring framework for many years. It was good ( as a user)
cloudflare wants to be vercel
Cloudflare wants to be worth much less?
I don't understand how Cloudflare's bottom line benefits:
Some here say they gain Astro users, that Cloudflare will become part of the default deployment. But given Cloudflare's current scale, how much are Astro's users worth? Is it even worth the distraction for Cloudflare? Companies lose energy to lots of small, low-value operations.
Most acquisitions begin with announcments that nothing will change, in order to retain customers and employees. They say '<acquistion> is so great, we don't want to interfere, and we're keeping existing management and letting them run things'. After the transition period - often 1 year - the old managers leave and the big changes happen, sometimes including shutting down the product because it was an acqui-hire all along or an IP acquisition.
It seems like Cloudflare must perceive some profit beyond what is announced.
It's very powerful to have ownership over a framework that many developers are familiar and like!
It might not be clear just yet what the path to monetization looks like but an easy example would be deeper integrations with the rest of the Cloudflare ecosystem (for example allowing R2 to be easily along with something like duckdb to live in a world of truly local analytics or something like that).
It seems like these great open source frameworks need to monetize by building a platform around the product but these days it's hyper competitive (ex. Vercel, Cloudflare) and it's hard to get started without an incredible differentiator. So, while monetizing independently as a company might be difficult, Astro can provide a lot of value to the rest of the Cloudflare ecosystem.
Why does Vercel provide Next.js? Aside from talent & tightly coupling Astro to their services, their North Star might be similar to Weekly Number of New Domains Hosted On Cloudflare. Sponsoring a framework that helps ship performant websites feeds into that metric.
I have no inside knowledge, though.
Vercel is a platform that, simplified, sells compute by time and by query.
Static optimized sites take very little compute, and little queries.
Since they have the most used framework (nextjs), they made it more server-heavy and changed the paradigm to one where a single page is built up using multiple queries for even just the html.
They then made sure that self hosting that monstrosity is terribly complex for anything serious, and incompatible with the "serverless environment" of their own platform, unless you have devops maintaining it.
And then they severely overhauled the pricing and gimped the included limits. (We were on <1% usage before. And now at 95%< while changing nothing...)
It could of course be a coincidence, but if that were the case, they would be very bad, yet lucky, business people.
100% will never put anything new on vercel and have been avoiding nextjs like the plague.
They get control and market differentiation. There will probably be a CloudFlare Astro CMS offering.
I personally would like a highly managed Astro solution. Astro is simple but highly extendable.
I can only hope they wean themselves off NPM somehow.
Yeah I see the benefit right off the bat, this is a direct head to Vercel and NextJS.
With that said, I have no idea on the market share or profitability of any of that or Cloudflare vs Vercel.
Also perhaps the rails that will be put in place for seamless 1 click Astro deploy will continue to push them forward with other technologies as well, so it's not just about Astro.
I do feel that fear as well, is this an unnecessary distraction for CloudFlare? Time will tell.
vertical integration probably, if you sell web services helping people get to the point that they need them is worth
buying into something that becomes popular is good advertising for cheap (react is probably the only reason for any kind of goodwill at all towards facebook)
as a function of earnings this is a rounding error purchase for them
More devs get acquainted with Cloudflare.
Cloudflare is becoming an alternative for Azure, AWS, ... Many don't realize it yet, because they don't know what Cloudflare is offering.
Developer goodwill. And it probably cost a song.
marketshare ???
like do you understand which company doing the same thing ????? Vercel is
now we talking, cloudflare want to extend their portofolio and product offering by integrate from top to bottom like vercel does
its doens't make sense/oblivious because we view it as standalone product rather than entire suite of product offering that well integrate vertically
> 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.
> React makes sense if you're making Gmail.
Except the old Gmail used to be so much faster…
Also the old Gmail never used react...
Many technical directions in the past 15 years have been a thinly veiled attempt to actually get paid for doing work.
> 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.
Fine, "what would best serve users", then.
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.
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.
Vite + React is the go-to recipe.
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.
the naming is backwards then. An island is static, an ocean is not. See how it is a buzzword up to your interpretation?
now that you say it :o
Should be astro lakes or something.
Islands is just a catchy name I guess. I always thought the markojs terms for it made sense, but are more technical / less catchy: they called it “full page hydration” -> everything needs to be delivered as js and “component level hydration” -> islands, only specific component sub-trees need to be hydrated.
Then “sub-component level hydration” would be resumability like in qwik where only events and their dependencies get serialised as client js.
Yeah. Well to their defense, it is probably to be understood as islands of interactivity lost in a sea of static elements. The term is definitely more evocative.
Like "meteoric rise". Meteors come down, not up.
And yet, we all know what it means. Language is fun.
You can do this with just about any programming language or scripting language that can render HTML on the server + plain HTML and JS. You could do this with PHP 30 years ago.
Yes and no, php didn’t give you any tools to manage this, most people writing php sites back in the day (including myself) were writing js that was coupled to a specific markup yet was maintained separately. This didn’t scale well.
Then along came libraries like mootools, knockout, etc all the precursors of react, then react changed the game around encapsulation of markup and code into one place, and straightforward data flow.
SPAs were inefficient so server side rendering of js became ubiquitous, islands are a further optimisation of ssr.
This hasn’t happened in a vacuum, if you look at modern php frameworks like inertia they have a lot more in common with Astro than they do the good old 90s php
You could and yet nobody did.
You need to give credit to a project like Astro that takes a pattern, popularizes it and makes it straightforward to adopt via a framework.
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).
Here's a trivial example: https://supremecommander.ai. A raw CSS implementation of my blog's logo would have been a pain to build and maintain, but with Astro the code is relatively straightforward JS that becomes pure HTML/CSS at build-time.
The other nice thing is that you can throw all kinds of preexisting components from React/whatever into your site, and it will ship zero JS to the client until you explicitly flag a specific JS resource as an "island".
The only special thing about "islands" is that they're an escape hatch from the default behavior of JS being strictly build-time-evaluated. I found the terminology and description a little confusing at first too, because it makes it sound more special than it is. But the concept makes sense when you understand the context of Astro's intentional default behavior.
Your website also reloads itself every 4 seconds for me on mobile Firefox
Good to know, thanks! I can't reproduce that on Android (and it's especially weird since the site has almost no JS), but I'll investigate and try to figure it out.
Np! Hopefully my comment didn’t come off aggressive, meant it to be helpful
lol, well I'd appreciate the heads up even if it were meant to be aggressive, but thanks. Should be good now; the issue was most likely a CSS animation causing your browser tab to crash, so now it'll just turn off the animation whenever the page is quickly reloaded twice in a row.
By the way, I'm getting a 404 at https://www.weakphi.sh/showcase.
Hah, thank you! Trading off website help :)
The have Rust now so the entire tooling layer can justifiably be rewritten a few more times
[flagged]
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.
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).
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.
A fix is coming: https://github.com/withastro/astro/pull/15227
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.
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.
Sorry we haven't fixed this issue sooner. In this case it's a complicated CSS issue, but nevertheless I've got a fix I'm working on here:
https://github.com/withastro/astro/pull/15227
Wow! That's a pretty impressive turnaround time from my comment to a PR, thanks for your work. I'll be happy to include this in my projects.
I have a preview release ready, if you scroll down you'll see the instructions. If you're able to try it out and leave a comment on whether it fixes your issue it'd be a big help.
I used it just with web components and pure html/js. Honestly don't even have a need for any framework with it, it's a great ssg like that already.
Interesting. Do you just build web components instead of React/etc, and add the client:load and Astro gives you the static (fast) initial page load, and lazy loading of web components?
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...
It is mentioned in the cloudflare blog post [1]
"At Cloudflare, we use Astro, too — for our developer docs, website, landing pages, and more"
[1] https://blog.cloudflare.com/astro-joins-cloudflare/
Coincidentally, I just migrated some support docs to Starlight a few hours before this acquisition announcement. Really nice framework.
I agree a good exit for devtools is good for devtools. I'd like to understand it better.
The Astro claim is that astro developers will all continue full-time on it. So why acquire it instead of supporting it?
The reason given in complementarity (content and infrastructure), but doesn't that mean that Cloudflare is moving into content? Perhaps it's fair to say some content fits better with Cloudflare, or making it easier to just have static sites is beneficial to Cloudflare?
Is there a convention about announcements, for the acquired to announce happily first to bring customers, and then the acquirer to confirm their benign intentions? When can we expect Cloudflare's take?
> So why acquire it instead of supporting it?
Lots of reasons, but above all, control.
> The Astro claim is that astro developers will all continue full-time on it. So why acquire it instead of supporting it?
In defense? Someone else can acquire it.
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.
Gatsby was sunset because it was a bad framework build on bad decisions [1]. I tried to use it when it was new, and it was immediately obvious that "GraphQL for everything" leads to horrible DX.
[1] https://news.ycombinator.com/item?id=39619110
It was definitely a terrible DX, I remember having trouble wrapping my head around querying for blog posts inside my blog post component instead of receiving them as props. But I was using a custom F# + asp.net blog engine I'd written for what amounted to a static site, so I just switched to that Gatsby thing I'd been hearing a lot about at the time.
I had moved out from Gatsby to Astro on my blog/site (username.com), mostly because the enormous dependency hell full of security issues, I know it's just things to generate static files, but it was causing a lot of headaches to upgrade and remove the issues. With Astro, I receive a lot less issues and the maintenance is easier! From my perspective if Cloudflare keep it that way, it'll be a win.
> I had moved out from Gatsby to Astro on my blog/site (username.com), mostly because the enormous dependency hell full of security issues, I know it's just things to generate static files, but it was causing a lot of headaches to upgrade and remove the issues.
That's exactly what made me move to Astro. I would've been happy sticking with Gatsby since it still technically does what it says on the tin, but there were so many security warnings and issues with upgrading dependencies that I gave up.
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.
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!
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!
This is the main thing for me. If I can keep the cf workers backend in the same repo and deploy them together I will consider leaving Next.js for good.
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...
> 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.
There are so many more options than being acquired and abandonware. Its hard but there are many independent and stable open source projects.
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.
Maybe not by market capitalization but Cloudflare is used by around 25 % of the web. Internet giant in my books.
> CloudFlare is hardly "big tech"
yeah, it's still losing money
[flagged]
> 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
why are you doing this?
Giving counterarguments? Wonder.
They are using astro starlight for their docs page and using astro itself in number of their landing pages.
Been running my technical knowledge base on Astro for about a year now (ketankhairnar.com). Congrats to the team on the acquisition - here's what stood out from a product/engineering perspective:
Content modeling that actually scales. Built a three-tier system: Concepts (foundational knowledge) → Deep Dives (series-based learning paths) → Systems (production case studies). Each concept tracks prerequisites, related topics, interview relevance by level (L5-L8), and links back to which deep dives use it. Zod validates everything at build time. This isn't a blog template - it's a knowledge graph with static output.
Islands architecture delivers on its promise. React hydrates only for search (Fuse.js across all content types) and a few interactive bits. Rest is zero-JS HTML. Coming from years of Next.js, the bundle size difference is stark. Users on flaky mobile connections notice.
Extensibility without framework lock-in. Wrote a custom Shiki transformer for ASCII diagram highlighting - ERROR renders red, FIX green, DECISION orange. Dynamic OG images generated at build via Satori+Resvg. No Lambda cold starts, no external services, just static assets. Infra cost: basically zero.
View Transitions shipped before others figured it out. One import, smooth page transitions. Small detail, big UX lift.
Where it gets tricky: Complex content relationships require multiple getCollection() calls and manual joins. Works fine, but a query builder would help for sites with heavy cross-linking. Also, the content layer is powerful but documentation assumes simpler use cases.
Product observation: Astro found a real gap - content sites that need occasional interactivity but don't want SPA overhead. Most frameworks optimize for apps and retrofit content. Astro did the opposite and it shows.
Curious how Cloudflare integration plays out. Edge rendering + this content model could be interesting for personalization without sacrificing static performance.
I love astro, it's been such a pleasure to use and totally solved my need for a flexible platform. I managed to retire a bunch of Wordpress sites and I've never looked back. Hopefully I can still run it on netlify.
Refreshing to see an acquisition (acquihire?) that just plainly says they were not able to monetize.
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 noticed the astro docs has lot of mention of Cloudflare worker as well, is there any reason why you didnt go with Cloudflare pages instead? I’d have guessed pages would be the perfect fit for hosting a rendered astro website
Even just having a better DX/UI around D1 and their other current offerings would be a great start
I'd love to see D1 as a supported catalog for https://ducklake.select/
What about Cloudflare D1?
D1 is fine when it fits the use case, but most of the time I just want Postgres that I will use for absolutely everything. It has happened often enough that I have tried to make systems work with other storage systems, and eventually just give up and revert to Postgres. Every time I just start with Postgres I don't have issues until it turns out my laziness has caused a performance problem, and those I can fix.
It's quite slow.
Astro to Cloudflare, Bun to Anthropic. Good trend seeing people toiling away at OS financially rewarded.
Big difference is that Anthropic blocks competitors from using its products (they literally cut direct api access. Or even through 3rd party like Cursor).
Two whole projects. A stampede.
big beloved projects
All wrongs in Gatsby have been gotten right in Astro. What will happen next remains to be seen, but currently Astro is amazing for a few specific cases it covers. The performance, developer experience and documentation are all great.
This news made my morning. I can't wait to see how they improve Astro build times and hosting on Cloudflare.
I'm incredibly relieved they didn't join Vercel (which everyone else seems to be doing these days).
Hope that SSR remains first class as time goes on. I think Astro’s DX is superb overall, and am bullish on server-rendered components in MPAs with a sprinkling of hypermedia libs for better UX.
Some features of my SSR-based side project feel like I had to hack them on, such as a hook that runs only on app start (hacked in via middleware) or manually needing to set cache control headers for auth’d content.
All in all, really happy with it. And it isn’t next.js.
This was inevitable. We're seeing the "Vercel-ification" of the edge. For a long time, Cloudflare had the superior infrastructure (Workers, R2, KV), but lacked the cohesive "onramp" that Next.js provides for Vercel. By acquiring Astro, Cloudflare finally owns the full stack, from the local dev experience to the global edge delivery.
The real question is whether Cloudflare can maintain Astro's "framework agnostic" soul while being incentivized to push everyone toward Workers/Pages.
I have always liked Astro. It also works great with AI tools since its combination of markdown and code. Was able to vibe code a quick blog template and deploy to cloudflare in minutes with an existing headless backend - https://sleekcms-astro-blog.pages.dev/
This is making me even less interested in trying Astro.
Websites should not be vibe coded.
The code is vibe-coded. Not the content. Which I think is more important for a blog site.
So.. just because a tool can be potentially mishandled (e.g. put in the hands of a toddler, which is basically what vibe code ends up being) because it's easy to use, you never want to take a look at said tool?
That sounds like shooting yourself in the foot out of pure spite, but you do you.
Astro is enabling vibe coders with a section of the documentation that gives advice on using AI, an Astro docs MCP server, and a copy of the documentation that is specifically formatted for LLM use.
This is a great news for Astro. It ticks all the boxes when being used to build heavy content and SEO driven websites. I've been using (Astro + Cloudflare workers/pages) as my go-to stack to build my Java gamedev resources website [1] and gaming portal [2], so far and the experience is very positive. Deploying static files to Cloudflare edges feels natural and frictionless.
Still a bit concerned that it might be too tempting to build an entire website infrastructure around cloudflare, which is a single point of failure. But there is really no better alternatives at the moment. I tried self-hosting but eventually resorted to cloudflare because of bad bots, ai, scrappers kept hammering on my sites.
[1] https://raizensoft.com/tutorials/ [2] https://ookigame.com
Great for Astro..
About the download stats for open source frameworks and libraries.. I keep reading claims of "millions of weekly downloads" -- surely this is a noisy metric, right?
NPM just counts GET requests. A significant number of those must be from CI/CD pipelines, mirrors, build servers, etc.
It still signals popularity, but probably to a much lesser degree than implied.
How to measure the popularity of FOSS projects though?
Number of downloads? Number of stars on GH? Number of content on social medias?
The absolute value is meaningless in itself, but there's a big difference between a library that is downloaded a thousand or millions of times each week. That's the idea.
Meanwhile for-profit projects have actual customers or revenues to demonstrate popularity.
Availability in Debian, is the measure I personally use.
VC still use github stars as a viable metric, at some point you have to say aloud that they are basically engaging in shammanism and ritual sacrifices.
Very unexpected but it's a great match. I have been using Astro with Cloudflare Pages and the dev UX is fantastic
Cloudflare's goal is to become the default choice for anyone deploying an app to the cloud. It makes sense for them to support popular frameworks such as Astro, so that they can ensure that the frameworks work very well on their Workers platform.
Anyone except users that need to serve the German market. Due to peering issues with the biggest German ISP that have been unresolved for years, websites hosted with Cloudflare simply don’t load in the evening.
Adobe could have benefited from doing this acquisition but they can be somewhat forgiven as they are already pushing Edge Delivery Services which is based in NextJS although it's a different approach. Combined with the Universal Editor they have a solid headless authoring setup for enterprise CMS.
But I really feel like Akamai is who dropped the ball here, this was a low hanging fruit for them and they're lacking offering this capability to offer their corporate clients as they transition to full headless. Now it's going to be their competition (Cloudflare, even Fastly through Adobe & the EDS push) who will try to take a portion of their cake.
I've been using Astro for a couple years and it's delightful. I actually started using it for my docs because I saw Cloudflare was using it. I hope they are a good steward of the tech!
Oh no. This isn’t good. I’m glad that the team gets a payout but as an Astro user I don’t love it being owned by CF and that the goals of the project (at least indirectly) goes from the best way to deploy it to the best way to deploy it using CF.
I don't anticipate it changing like that. You still do a build using Vite and deploy the static assets. How could they change that to make it difficult to host elsewhere?
Let’s hope you’re right. I think vendor lock in is possible if they focus on features tightly coupled to Cloudflare. Look at Next.js. In theory you can deploy it anywhere, but in practice it is harder outside Vercel because of tight coupling around things like caching. You do not have to use those features, but if the framework is built to expect them, it pushes people into that platform. I can imagine Astro becoming very attractive to use with Cloudflare Workers and slowly locking people into that model.
It is not similar imho. First NextJS build system is not really exposed apart from a simple docker example and all advanced features of NextJS is kinda coupled to Vercel. For Astro it is just a Vite project with integration designed from day mind they would have to rip everything apart and that would probably cause a prominent fork. The other part is Cloudflare is not dependent Astro being vendor locked as much as Vercel being dependent on NextJS being vendor locked.
Let’s hope you are being right. Note that I am not talking about Astro today but rather Astro in 5 years.
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.
I'm glad they were able to pivot into Astro when Vite won the hot dev server game a few years back.
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.
Astro is my favorite framework for static sites. It's hard to describe but it just "makes sense". You don't need complex build setups and you can get the best of all worlds with great SSG capabilities + can easily express things with React when needed for example.
I wish there was another path to monetization besides joining a larger company but I'm happy that the team will get to continue building out an amazing framework!
Cloudflare is getting into static site hosting game, like Vercel.
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.
I found that Vite does a great job of deploying static websites. All I had to do was add Vite as a dev dependency in my pacakge.json and make sure all the page routes in vite.config.js.
I've been skeptical about trying Astro because it seems to have unnecessary complexity. Also, I don't see any evidence that Cloudflare is going to prioritize making Astro easier to use.
What in Astro would make it easier to use? Or, what makes it more complex to use than you'd like? We're always open to feedback!
The first thing I would do is stop trying to support AI tools, and remove any comments about AI from the documentation.
Generative AI is not suitable for building content-driven websites because it lacks context to understand subjective user preferences.
Also, having .astro files to implement island functionality is unnecessary. Interactivity can be implemented with Javascript using web components.
Yeah, I agree on the AI front. Although outside of the AI page, I don't believe we have other content on it. It was intentional to keep it separate from the rest of the docs. I know we've recently discussed making changes / removing some of that content.
I love web components (one of the things that got me into Astro), but it can be helpful to reach for something like Solid when you get into more complex UI. Most Astro projects will never need to reach for that, which is why there's no UI framework available by default.
Astro definitely tries to stick to a minimal defaults approach by design. We'd rather people start from a simple, minimal boilerplate, and reach for solutions (e.g. UI frameworks, on-demand rendering) only when they run into a problem it solves.
What are you doing about repeated content?
There's a Vite plugin that can be used to insert identical HTML on multiple pages without JavaScript. I use it for the navbar and footer: https://www.npmjs.com/package/vite-plugin-handlebars
For repeated content where JavaScript is required, I use web components.
What's the next best/popular alternative to Astro?
Used this for a portfolio site and and not sure if this news is good or bad for its future.
I'm not jumping off Astro yet, but if I did I would probably go to Vike (https://vike.dev/)
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
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)
Yep, Astro is and will always be platform-agnostic!
Crossing fingers (but not holding breath) this doesn't lead to vendor lock-in or otherwise wreck Astro.
Cloudflare doesn't need to vendor lock astro like vercel needed to vendor lock next. They have a massive amount of other things to sell.
I know. Still, not holding breath.
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.
Wow, amazing news. At Themefisher, we’ve built 40+ Astro templates used by hundreds of Astro devs and many client sites. Also great to hear it was Cloudflare!! Hope Astro keeps growing.
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.
I knew it was too good to last hah
Congratulations!
I hope they've got rewarded astro...nomically well lol!
My apologies friends, I could not resist!
Congrats Astro team!
Is that a good deal for the employees of Astro? They're now Cloudflare employees, which I guess looks good on your CV.
But do such acquihires usually result in higher salaries for regular (non-leadership) employees or? Also, what about NSOs?
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.
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
Based on a request presumably from a HN viewer, I made the repo [2] for this site public.
[2] https://github.com/cto4ai/cto4ai-blog
Makes perfect sense. I use Astro with Cloudflare for all my frontend projects.
Congrats! I love Astro and published an i18next plugin https://github.com/gutenye/astro-i18next
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.
I don’t want a framework that’s coupled to a hosting provider.
It's not and will probably never be.
If you want some precedent look at Hono. Initially it was just for the CF Workers runtime (not developed by CF). Then CF started using Hono internally and hired the dev to work on Hono full time. Hono works on any JS runtime.
https://hono.dev/docs/concepts/web-standard
I suppose we’ll see — I’d be surprised if the whole promise of nothing will change don’t hold over the long term. I don’t love that Astro is tied to a narrow set of hosting providers either.
Astro runs on many JS runtimes. It can be deployed anywhere.
Congrats to Fred and team! Developing and maintaining a complex framework takes lots of funding, and I’m glad Astro found a new home that provides that.
With [Mastro], we have a different approach. The name originally stood for "minimal Astro", and we’re staying true to that. At just ~700 lines of TypeScript, Mastro will always be easily maintainable – even if by just a single person. And it's amazing how much you can do if you're very deliberate in your API's design.
[Mastro]: https://mastrojs.github.io/
Love Astro and it is exactly my stack with Cloudflare but wow, the "Forward-Looking Statements" disclaimer is longer than the press release itself
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
This is great news for the Astro team. Cloudflare has been doing a lot of good things for the open source community lately.
I’ve been expecting this for a while - their last few releases have all had big features included for their cloudflare adapter
Damn. What alternatives does HN recommend?
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.
Plain html has two things going against it.
First, it doesn't have any provisions for code reuse. So, if you have multiple pages that use the same header, same footer, or same navigation menu, your options are either to copy-paste it (gross), or to build the final html out of smaller pieces, at which point you've reinvented either a static site generator or a web server.
Second, if you write long stretches of text, the html markup can get in the way, as opposed to unobtrusiveness of something like markdown.
Yea I think I’ll write my own static generator that just combines 3 templates for header/body/footer and converts markdown from the body. Should be fun project.
I’m tired of the constant update pressure from existing solutions and I only need something dead simple.
> at which point you've reinvented either a static site generator ...
It doesn't have to be Astro though. You can build something super simple that just includes the header, footer, and nav. Leaving most of the site as plain HTML.
Yes; that's Eleventy. Or Hugo. Or Jekyll. They are extremely simple, without the bells and whistles of Astro.
Or I don't know, use WebComponents.
How would this help? You would want your header render on the server, wouldn't you? Not to incur a CLS penalty, right? How does a web component help in this scenario?
You use server includes in that case, a simple Apache configuration.
Welcome to the 1990's web coding.
Same, and I was starting to feel kind of strange doing anything in html/php in 2026 but then I looked at everything else and realized I'd have to start from scratch again. Plain ol' HTML has worked great.
I recently rebuilt my site with Parcel + React Server Components. RSC are designed to solve many of the same problems that Astro does. And Parcel is “just” a bundler and not a framework, so it has less magic and gives you more control.
https://micahcantor.com/blog/rsc-rewrite.html
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.
Mastering HTML, CSS and vanilajs.
Then one is pretty much safe from framework tides.
Vite. https://codeberg.org/createthirdplaces/frontend/src/branch/m...
https://lume.land/ a good, straightforward SSG.
There's one other I've seen recently that looked good but I have misplaced the link
https://mastrojs.github.io/ was the one I couldn't recall.
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.
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.
What are you referring to re: it getting political?
I'm not! Just preparing myself for the worst-case scenario and creating some bookmarks meanwhile.
Open source alone can’t sustain companies long-term. Eventually everyone needs a bigger, safer home.
Perfect direction! Astro has been incredible for small static pages. CF workers are also really easy to impl
I hope CLoudflare or another tech company buy deno. Deno is great, its lacking a big brand sponsorship.
Cloudflare are neck deep in v8 as their js runtime of choice. I doubt they'll be looking for another any time soon
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.
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
This spam LLM account "MarkusAllen" (towards the very end) could be used by an adversory to discredit books / courses /"youtube channel" they link to. This is reverse psychology attack vector made possible by an LLM.
ITT People arguing about how cloudflare is gonna unfairly favor their own platform and lock people in by making easier to deploy astro sites as if you can't already do it just by connecting a git repo to cloudflare pages with 1 click.
i'd personalloy love a quick video demo on the home screen, with someone walking through the experience of using the app; other than that, looks interesting;
Another open source framework likely be dead soon, what are the alternatives ?
Did they just break Cloudflare?
Vercel 2.0
This sucks
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.
There are tons of options for sharing state between islands.
The docs show how to use nanostores but you can use other libs like vue refs, etc.
https://docs.astro.build/en/recipes/sharing-state-islands/
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 ;-)
You become beholden to these platforms and they're inherently not portable. There is risk here, and given the track record of Internet companies I think it's fair to say the risk is not worth it for many people.
Your costs could explode, or worse, the business could go under and you lose all your shit.
Substack only really makes sense if you want to monetize your content.
Why ? Spinning up a blog these days with one of these frameworks is almost quicker than signing up to one of the blog hosting platforms.
And you get to keep your data in markdown easily portable
Astro is life!
is astro any good ? havent tried it yet
It's very simple to use. I tried a few static site generators and Astro gave me the most freedom and was the most approachable, pretty much no learning curve. You can use it with MULTIPLE web frameworks at the same time so it's pretty damn great. It gives you many options to do one thing so you can do things your way which is a delight for tinkerers
Awesome!
> Now Astro is downloaded almost 1,000,000 times per week [...]
Are these numbers supposed to provide any sense of the popularity if you're not often looking at npm trends?
Tried Astro after being utterly confused with Hugo templating and found it rather over-engineered. Went with 11tty instead and don't regret it.
[flagged]
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.
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.
Are you using LLM-generated comments to peddle your book/fake college?
[dead]
You AI generated this whole comment…
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.
Is it just me or is this entire comment AI-generated?
Holy survivorship bias Batman, and yeah, nice punchy AI sentences you got there.
> 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.
Nope, it is still the community getting funding out of somewhere.
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.
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.
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.
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.
Markus Allen of Founderstowne thinks the umpteenth js web framework is infrastructure and puts it in a category with Linux.
Nitpick: While Linux is not VC-funded, I don't believe you can say Linux is "community-funded".
> I write everything myself here. In my words.
> I fully admit using Ai as my editor
No one enjoys reading AI slop. It has 0 value, and it's a huge turnoff on forums like this. You should stop doing it.
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.
[dead]
[dead]
[dead]
[dead]
Oh wow, Cloudflare enschitification is practically in real time right now.
Vercel buys frameworks. Cloudflare does the same.
We all lose while they all tell us we're winning.