[HN Gopher] Cloudflare acquires Astro
___________________________________________________________________
Cloudflare acquires Astro
https://www.cloudflare.com/pl-pl/press/press-releases/2026/c...
Author : todotask2
Score : 915 points
Date : 2026-01-16 14:25 UTC (1 days ago)
(HTM) web link (astro.build)
(TXT) w3m dump (astro.build)
| pier25 wrote:
| Astro is amazing. I've been using it for a couple of years now.
| Initially only for static sites but now I'm building the UI of
| all my web projects with it.
|
| I wonder if there will be some sort of collab between Hono and
| Astro given that Yusukue also works at Cloudflare.
| upcoming-sesame wrote:
| Yup, there's a lot of overlap especially with the HonoX
| framework that has island architecture as well!
| TurdF3rguson wrote:
| 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.
| mpeg wrote:
| 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
| phartenfeller wrote:
| Why does Cloudflare need a web framework? Most obvious would be
| they think they can make money from hosting astro sites (like
| Vercel and NextJS). I hope Cloudflare's impact on Astro will be
| tiny. But another great thing being swallowed by big tech...
| arcanemachiner wrote:
| > But another great thing being swallowed by big tech...
|
| I will never use Cloudflare if I can help it, but this outcome
| is preferable to Astro becoming abandonware.
| phartenfeller wrote:
| There are so many more options than being acquired and
| abandonware. Its hard but there are many independent and
| stable open source projects.
| arcfour wrote:
| 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.
| blibble wrote:
| > CloudFlare is hardly "big tech"
|
| yeah, it's still losing money
| phartenfeller wrote:
| Maybe not by market capitalization but Cloudflare is used by
| around 25 % of the web. Internet giant in my books.
| dvtkrlbs wrote:
| They are using astro starlight for their docs page and using
| astro itself in number of their landing pages.
| tnolet wrote:
| Refreshing to see an acquisition (acquihire?) that just plainly
| says they were not able to monetize.
| philipallstar wrote:
| 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.
| lateral_cloud wrote:
| Mindshare with developers is what cloudflare gets
| pxtail wrote:
| It's obvious when you look at
| https://astro.build/blog/astro-6-beta/ and see "Cloudflare"
| sprinkled everywhere in the article.
| philipwhiuk wrote:
| Feels like they are trying to do vertical integration on the
| whole stack and compete with Vercel.
| pjmlp wrote:
| For me, anyone that tries to compete with Vercel has to beat
| their offering in backend runtimes.
| mpeg wrote:
| 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)
| jtbaker wrote:
| > Nextjs has no support
|
| From what I remember, you can't even run a NextJS app through
| vite?
| mpeg wrote:
| 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)
| sp4cec0wb0y wrote:
| Wasn't this a decision made by Vercel to incentivize
| people using Vercel for NextJS apps? I can't recall.
| jamieatlason wrote:
| 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
| mattgreenrocks wrote:
| This is insane to me, and validates my irrational dislike
| of next.
| jtbaker wrote:
| 100% rational. Nuxt/Astro FTW.
| hungryhobbit wrote:
| 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.
| mattgreenrocks wrote:
| Isn't the next.js build system known for being
| slow/memory hungry?
| pjmlp wrote:
| For those stuck in the past yes, they have replaced it
| with a Rust based toolchain, as is so fashionable
| nowadays.
| mzronek wrote:
| 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. :)
| Vinnl wrote:
| 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.
| cornholio wrote:
| So, cloudification: lock the customer into a complex cloud
| dependent solution they can't easily migrate to some other
| commodity infrastructure provider.
| taraindara wrote:
| The easier/convenient a cloud makes it for a business to
| use, the more the industry will continue to trend towards
| lock in
| ghurtado wrote:
| I don't see the relation between those two
| mikodin wrote:
| 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.
| mynameisvlad wrote:
| 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.
| mplewis wrote:
| Yeah. For now.
| bahmboo wrote:
| 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]
| mynameisvlad wrote:
| 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.
| thayne wrote:
| 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.
| mynameisvlad wrote:
| Once again, it's a static site builder. How, exactly,
| would they "stop supporting deploying to cloudflare's
| competitors"? Be specific.
| HumanOstrich wrote:
| The same ways Vercel makes it harder to deploy Next.js
| sites to competitors or for self hosting.
| fady0 wrote:
| Next.js isn't just a static site generator.
| HumanOstrich wrote:
| Astro isn't just a static site generator either. Not sure
| what your point is.
| mynameisvlad wrote:
| Yes it is. All of the providers support "Static", which
| literally means uploading /dist to your provider of
| choice.
|
| They also have three pages worth of deployment adapters
| for one line deployment on many platforms, including many
| built by the community. https://astro.build/integrations/
| ?search=&categories%5B%5D=a...
|
| Did you even bother to look at their site or even better
| the guides I posted upthread or just decide to pull that
| out of your ass?
| HumanOstrich wrote:
| 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.
| theturtletalks wrote:
| 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
| NicoJuicy wrote:
| So it is vendor locked by Vercel. That's why there is
| OpenNext - https://opennext.js.org/
| philipallstar wrote:
| How is it vendor locked?
| Capricorn2481 wrote:
| 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.
| mmooss wrote:
| 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.
| sofixa wrote:
| 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.
| mplewis wrote:
| For now.
| Y_Y wrote:
| This reads like marketing copy. Maybe it reflects your actual
| feelings but it's hard to imagine that if you don't write
| like a human.
| satvikpendem wrote:
| 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.
| ghurtado wrote:
| What a bizarre comment. What part of it was "not human" in
| your opinion?
| mpeg wrote:
| 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)
| jjmarr wrote:
| 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/
| slfreference wrote:
| 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.
| basch wrote:
| 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.
| deaux wrote:
| Because they much rather have those small businesses use
| a Facebook page for that purpose, which is the status quo
| in the West.
| Seattle3503 wrote:
| So when folks say they want to see big companies invest in
| open source, this is what that looks like. CF could have kept
| coasting on what Astro was building, but instead they are
| paying for it. But in return they get a lot of control.
| skybrian wrote:
| 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.
| Seattle3503 wrote:
| Definitely!
| knowitnone3 wrote:
| You know this because you work on the Go team or part of
| google management?
| skybrian wrote:
| > as far as I can tell from the outside
|
| Anyone with actual knowledge, feel free to chime in.
| ignoramous wrote:
| > _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).
| Aissen wrote:
| What does Vercel get out of Next.js? Just default integration
| of overpriced cloud infra.
| azangru wrote:
| Vercel was founded (or co-founded?) by the author of Next.js.
| That's a very different story. Vercel is like what some
| hypothetical Astro Cloud could have become if it had grown
| out of Astro.
| amitav1 wrote:
| "I don't care, it's a stupid question."
| pjmlp wrote:
| 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.
| richardwhiuk wrote:
| https://www.tumblr.com/ourincrediblejourney
|
| This is probably just an acquihire.
| pier25 wrote:
| Probably better support for CF Workers/Pages and better
| integration with Wrangler.
| paxys wrote:
| They get to make Astro -> Cloudflare the default publishing
| pipeline. Sure users may pick something else, but even if a
| small % stick with Cloudflare that's an overall win.
| threetonesun wrote:
| I expected something clearer in the blog post about deploying
| Astro on Cloudflare Pages, as I imagine many Astro users
| (like me) are on Netlify.
|
| I think every deployment pipeline having it's own preferred
| UI framework (and CMS, and cloud-DB solution) makes a lot of
| sense.
| HumanOstrich wrote:
| Why did you expect info about deploying Astro to Cloudflare
| Pages? It's been supported for a long time already.
| threetonesun wrote:
| Seems like an obvious thing to call out for people (like
| me) who don't know.
| HumanOstrich wrote:
| So something like "now that we own Astro, all of you
| using Netlify should start migrating to Cloudflare
| Pages"?
| threetonesun wrote:
| "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.
| csomar wrote:
| Nextjs doesn't really work on cloudflare with the latest
| versions. There is an adapter but it's buggy as hell. The
| direction is also likely to continue:
| https://omarabid.com/nextjs-vercel
|
| Source: I use cloudflare and used to run my app there (nextjs)
| and had to do a migration to vite.js. So the way I see it, this
| is cloudflare response to vercel.
| solarkraft wrote:
| My god. Every time I touch Next.js in some project I think
| "hey, this actually doesn't feel so bad to develop with, dare
| I say it feels nice?" and every time I read about it I think
| "what the hell, this is the worst choice you can make".
|
| It's wild that they're somewhat taking the whole React
| ecosystem with them.
| everybodyknows wrote:
| Following your link, the fault for this appears to lie
| entirely with Vercel management.
|
| Cross fingers that CloudFlare never try similar lock-in
| games, now that they control Astro?
| csomar wrote:
| 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..)
| bflesch wrote:
| Cloudflare definitely gets positive PR out of this which makes
| people forget their CEO's recent meltdown on twitter.
| chuckadams wrote:
| The "meltdown" where he refused to jump to the whims of
| Italy's football cartel and block whatever addresses they
| wanted without accountability or review? More meltdowns,
| please.
| epolanski wrote:
| 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.
| philipallstar wrote:
| You get what you pay for with free PR commentary.
| adverbly wrote:
| 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.
| nindalf wrote:
| 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.
| whimsicalism wrote:
| cloudflare wants to be vercel
| unfunco wrote:
| Cloudflare wants to be worth much less?
| kelvinjps10 wrote:
| 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
| zipy124 wrote:
| 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.
| jayanmn wrote:
| VMware maintained spring framework for many years. It was good
| ( as a user)
| weli wrote:
| Nice. I love astro and I love cloudflare. Most of my static pages
| are that stack.
| koakuma-chan wrote:
| 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.
| philipwhiuk wrote:
| 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.
| re5i5tor wrote:
| If you aren't realizing the importance of POSSE imho that's
| crazy ;-)
| pier25 wrote:
| Substack only really makes sense if you want to monetize your
| content.
| upcoming-sesame wrote:
| 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
| array_key_first wrote:
| 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.
| drawfloat wrote:
| 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"
| monooso wrote:
| > 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
| mpeg wrote:
| 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.
| koakuma-chan wrote:
| 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.
| mpeg wrote:
| 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.
| koakuma-chan wrote:
| 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.
| mpeg wrote:
| 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.
| CharlieDigital wrote:
| > They still don't support inter-island communication
|
| Can't you just use standard DOM events for that on the client?
| This would work even pushing events from React to Vue to
| Vanilla.
| koakuma-chan wrote:
| That's what I did, but DX is not great. I would prefer some
| kind of channel API.
| pier25 wrote:
| 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/
| embedding-shape wrote:
| > 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?
| philipwhiuk wrote:
| 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.
| verdverm wrote:
| The have Rust now so the entire tooling layer can justifiably
| be rewritten a few more times
| mpeg wrote:
| The key difference between islands and what we used to do
| back in the day (js on a static page) is that with an islands
| approach you architect your site with a components-driven
| approach where everything encapsulates the js/css/html it
| needs, then you mark it as an "interactive" island if you
| actually need client-side js to run - the code is the same,
| but it either runs only in the server (default) or in both
| server and client.
|
| I know this sounds similar, but, compared to the more
| traditional approach, there is a certain simplicity to having
| everything just be javascript. You can often run the same
| libraries on both server and client depending on your needs,
| plus it fulfills the promise of web components in a way that
| is easier to work with (though WCs have also come a long
| way!)
| charleszw wrote:
| 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.
| efilife wrote:
| the naming is backwards then. An island is static, an
| ocean is not. See how it is a buzzword up to your
| interpretation?
| aatd86 wrote:
| now that you say it :o
|
| Should be astro lakes or something.
| mpeg wrote:
| 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.
| aatd86 wrote:
| 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.
| dreadnip wrote:
| 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.
| mpeg wrote:
| 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
| s4i wrote:
| 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.
| graypegg wrote:
| It has been funny seeing the tide come in and out now a few
| times. Though I will admit that each time, the ergonomics get
| better. AJAX as a pattern was pretty gnarly if you wanted to
| do a bit more than update a notification badge or comment
| box.
|
| There's a really nice pattern of using Custom Elements [0]
| for that sort of JS interactivity sprinkling. You can make
| your web application however you want, and when you want the
| client to run some JS, you just drop in `<my-component
| x="..." y="...">...</my-component>` with whatever flavour of
| HTML templating you have available to you. (also possibly
| with the is= attribute in the future [1], which will let you
| keep more of the HTML template out of JS)
|
| It saves you the hassle of element targeting and lets you
| structure that part of your app a bit more without going
| overboard on "everything is a react component, even the
| server bits".
|
| Want something "server side generated" in that JS? Just
| render it in attributes/body/a slot element/a template
| element, and expect to pick it up in the JS side of things.
| Feels like how it's supposed to be... and there's no
| framework required!
|
| [0] https://developer.mozilla.org/en-
| US/docs/Web/API/Web_compone...
|
| [1] https://developer.mozilla.org/en-
| US/docs/Web/HTML/Reference/...
| WorldMaker wrote:
| Custom Elements do start to feel like the dream of the
| Knockout-era web of "Progressive Enhancement" is finally
| almost entirely out of the box in the browser. Especially
| ignoring the Shadow DOM and using Light DOM to style your
| unpopulated or static rendered fallback states as close to
| your "live" JS-driven state can lead to some very good
| experiences, including and especially when JS is disabled
| (or erroring).
| buu700 wrote:
| Here's a trivial example: https://supremecommander.ai. A raw
| CSS implementation of my blog's logo would have been a pain
| to build and maintain, but with Astro the code is relatively
| straightforward JS that becomes pure HTML/CSS at build-time.
|
| The other nice thing is that you can throw all kinds of
| preexisting components from React/whatever into your site,
| and it will ship zero JS to the client until you explicitly
| flag a specific JS resource as an "island".
|
| The only special thing about "islands" is that they're an
| escape hatch from the default behavior of JS being strictly
| build-time-evaluated. I found the terminology and description
| a little confusing at first too, because it makes it sound
| more special than it is. But the concept makes sense when you
| understand the context of Astro's intentional default
| behavior.
| weakfish wrote:
| Your website also reloads itself every 4 seconds for me on
| mobile Firefox
| buu700 wrote:
| 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.
| weakfish wrote:
| Np! Hopefully my comment didn't come off aggressive,
| meant it to be helpful
| buu700 wrote:
| 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.
| weakfish wrote:
| Hah, thank you! Trading off website help :)
| Vinnl wrote:
| 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.
| maelito wrote:
| > 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.
| afavour wrote:
| 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.
| timeon wrote:
| > Users get by with it.
|
| They would not if they had choice.
| afavour wrote:
| 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.
| whatevaa wrote:
| Most non-technical users have no idea what they want.
| They will happily request a feature to implement an email
| client in your database.
| afavour wrote:
| Fine, "what would best serve users", then.
| Zanfa wrote:
| > React makes sense if you're making Gmail.
|
| Except the old Gmail used to be so much faster...
| shimman wrote:
| Also the old Gmail never used react...
| zcw100 wrote:
| Many technical directions in the past 15 years have been a
| thinly veiled attempt to actually get paid for doing work.
| giancarlostoro wrote:
| 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.
| Squarex wrote:
| What is the preffered way to do the opposite now? Not every
| webapp should be architected as an website.
| s4i wrote:
| Vite + React is the go-to recipe.
| saltytostitos wrote:
| Cloudflare: Astro Vercel: NuxtLabs, Next. All open source. What a
| strange competition.
| jcmfernandes wrote:
| Damn. What alternatives does HN recommend?
| arcanemachiner wrote:
| 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.
| azangru wrote:
| Eleventy, of course :-)
|
| But why are you looking for alternatives already?
| jcmfernandes wrote:
| I'm not! Just preparing myself for the worst-case scenario
| and creating some bookmarks meanwhile.
| throwawa71973 wrote:
| 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.
| evantbyrne wrote:
| 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.
| porker wrote:
| https://lume.land/ a good, straightforward SSG.
|
| There's one other I've seen recently that looked good but I
| have misplaced the link
| porker wrote:
| https://mastrojs.github.io/ was the one I couldn't recall.
| pousada wrote:
| 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.
| azangru wrote:
| 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.
| H1Supreme wrote:
| > 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.
| azangru wrote:
| Yes; that's Eleventy. Or Hugo. Or Jekyll. They are
| extremely simple, without the bells and whistles of
| Astro.
| pousada wrote:
| 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.
| pjmlp wrote:
| Or I don't know, use WebComponents.
| azangru wrote:
| 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?
| pjmlp wrote:
| You use server includes in that case, a simple Apache
| configuration.
|
| Welcome to the 1990's web coding.
| jrnichols wrote:
| 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.
| pjmlp wrote:
| Mastering HTML, CSS and vanilajs.
|
| Then one is pretty much safe from framework tides.
| hydroxideOH- wrote:
| 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
| gulugawa wrote:
| Vite.
| https://codeberg.org/createthirdplaces/frontend/src/branch/m...
| quentindanjou wrote:
| 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.
| azangru wrote:
| 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.
| ascorbic wrote:
| 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
| azangru wrote:
| Why did they want Gatsby's graphQL thing? What was
| attractive about it?
| ascorbic wrote:
| 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
| shibel wrote:
| Astro is great. It checks all of my checkboxes. I hope this is
| not the beginning of the end.
| tin7in wrote:
| 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.
| __jonas wrote:
| 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.
| giancarlostoro wrote:
| I havent had a chance to fully use it in a project yet, but it
| is one of my favorite projects only tinker with it, I'm glad it
| will receive funding to keep it going. It is definitely a solid
| gem of open source since its not married to one single SPA
| framework.
| __jonas wrote:
| Yeah I suppose it's a tradeoff. I have had an excellent
| experience when not hydrating components at all, and I like
| their approach significantly more than other SSGs overall. My
| worry is just the massive scope of supporting integrations
| with all those frameworks AND its own .astro language /
| syntax AND server side rendering in addition to static
| generation.
| mpeg wrote:
| 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/integ
| r...
| catoAppreciator wrote:
| Wow. Good callout.
| shimman wrote:
| 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).
| catoAppreciator wrote:
| Any reason you didn't use alpine for client side interactivity?
| When I went down the "use a framework plugin in Astro" route, I
| found it too jarring and reverted to alpine which I found
| worked well enough.
| __jonas wrote:
| No, not in particular, I just like Svelte's compilation-based
| approach, but Alpine definitely looks nice.
|
| When the client side interactivity is very contained and
| small in scope I also quite like just using plain JavaScript
| without a framework.
| MatthewPhillips wrote:
| 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
| __jonas wrote:
| 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.
| MatthewPhillips wrote:
| 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.
| Aurornis wrote:
| I like the concept of making frameworks pluggable with
| different adapters. In my experience, though, it's dangerous to
| hitch your wagon to anything but the top 1 or 2 most popular
| adapters in a given project like this.
|
| The JavaScript web framework ecosystem has this problem
| everywhere lately where frameworks try to be everything to
| everyone and support every use case anyone might want. It's
| noble in theory but without dedicated and active maintainers
| for each combination there's bound to be something left behind.
|
| My heuristic has been to only use adapters that the core
| project maintainers appear to favor. The maintainers for sub-
| project adapters that are introduced later frequently have
| maintainers that come and go, with long periods where things
| start breaking and nobody is interested in fixing them.
| pier25 wrote:
| A fix is coming: https://github.com/withastro/astro/pull/15227
| sureglymop wrote:
| I used it just with web components and pure html/js. Honestly
| don't even have a need for any framework with it, it's a great
| ssg like that already.
| halfcat wrote:
| 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?
| maxencecornet wrote:
| Very unexpected but it's a great match. I have been using Astro
| with Cloudflare Pages and the dev UX is fantastic
| re5i5tor wrote:
| 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
| re5i5tor wrote:
| 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
| MarkusAllen wrote:
| [flagged]
| pjmlp wrote:
| > 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."
| haolez wrote:
| Big corp money is not VC money. That's the point.
| pjmlp wrote:
| Depends on which corporation.
| halestock wrote:
| No, it depends on whether they have an ownership stake in
| what they're funding or not.
| pjmlp wrote:
| 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.
| halestock wrote:
| Ok sure, but now you're just describing something
| completely different.
| pjmlp wrote:
| Nope, it is still the community getting funding out of
| somewhere.
| Terretta wrote:
| 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.
| pjmlp wrote:
| Community isn't certainly big corporations, some of which
| have been born out of VC money as well.
| tialaramex wrote:
| 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.
| pjmlp wrote:
| 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.
| philipallstar wrote:
| 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.
| yellow_lead wrote:
| Are you using LLM-generated comments to peddle your book/fake
| college?
| strangescript wrote:
| 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.
| idopmstuff wrote:
| 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.
| furyofantares wrote:
| LLM generated reply right here. Not the worst I've seen but
| please just post your prompt.
| Trufa wrote:
| 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.
| Imustaskforhelp wrote:
| 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
| Aurornis wrote:
| > 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.
| Aurornis wrote:
| 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.
| troyvit wrote:
| 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.
| nindalf wrote:
| 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.
| Imustaskforhelp wrote:
| > 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?)
| nindalf wrote:
| > 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.
| jlarocco wrote:
| 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.
| mp05 wrote:
| Holy survivorship bias Batman, and yeah, nice punchy AI
| sentences you got there.
| Aurornis wrote:
| 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.
| nonethewiser wrote:
| 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."
| nindalf wrote:
| 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.
| MagicMoonlight wrote:
| You AI generated this whole comment...
| einpoklum wrote:
| Nitpick: While Linux is not VC-funded, I don't believe you can
| say Linux is "community-funded".
| nonethewiser wrote:
| Markus Allen of Founderstowne thinks the umpteenth js web
| framework is infrastructure and puts it in a category with
| Linux.
| John7878781 wrote:
| Is it just me or is this entire comment AI-generated?
| PKop wrote:
| > 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.
| ramon156 wrote:
| Perfect direction! Astro has been incredible for small static
| pages. CF workers are also really easy to impl
| angelfangs wrote:
| Tried Astro after being utterly confused with Hugo templating and
| found it rather over-engineered. Went with 11tty instead and
| don't regret it.
| suyash wrote:
| Another open source framework likely be dead soon, what are the
| alternatives ?
| wahnfrieden wrote:
| This sucks
| fnoef wrote:
| 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.
| sieep wrote:
| 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.
| adzm wrote:
| Fork it and call it Cosmo
| lifetimerubyist wrote:
| 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.
| yawnxyz wrote:
| Surprised this isn't in the article, but Cloudflare has been
| moving all their docs to Astro's Starlight docs framework. I'm
| guessing this is a way to prioritize features for Cloudflare:
|
| > https://blog.cloudflare.com/open-source-all-the-way-down-upg...
| fr3dx wrote:
| 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/
| buu700 wrote:
| Coincidentally, I just migrated some support docs to Starlight
| a few hours before this acquisition announcement. Really nice
| framework.
| pcthrowaway wrote:
| I'm incredibly relieved they didn't join Vercel (which everyone
| else seems to be doing these days).
| stared wrote:
| 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!
| dkhenry wrote:
| 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.
| upcoming-sesame wrote:
| What about Cloudflare D1?
| dkhenry wrote:
| 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.
| Squarex wrote:
| It's quite slow.
| samtp wrote:
| Even just having a better DX/UI around D1 and their other
| current offerings would be a great start
| jtbaker wrote:
| I'd love to see D1 as a supported catalog for
| https://ducklake.select/
| hdra wrote:
| 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
| nindalf wrote:
| 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!
| kevinskii wrote:
| 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.
| BenGosub wrote:
| amazing performance.
| deepfriedbits wrote:
| I appreciate your honest testimonial. It's so rare these days
| to read a sentence like, "No credit to me at all" haha
| ljm wrote:
| Out of curiosity, how do you become 'exceedingly good' at
| serving static HTML?
|
| By all accounts, they've centralised the delivery of this
| static HTML at several layers of the network stack, and you're
| not getting static HTML anymore because some other part of the
| business fucked it up.
|
| The World Wide Web was serving static HTML for decades before
| Cloudflare came along. Open an FTP client, drag and drop, and
| boom - new HTMl is served.
| fartfeatures wrote:
| 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.
| LtdJorge wrote:
| If everything is static, they'll cache it in a DC close to
| you. That's better than what we had before.
| snorremd wrote:
| 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!
| 827a wrote:
| 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.
| akmittal wrote:
| I hope CLoudflare or another tech company buy deno. Deno is
| great, its lacking a big brand sponsorship.
| bobnamob wrote:
| Cloudflare are neck deep in v8 as their js runtime of choice. I
| doubt they'll be looking for another any time soon
| bryanhogan wrote:
| 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.
| Alifatisk wrote:
| 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.
| jtbaker wrote:
| I'm glad they were able to pivot into Astro when Vite won the
| hot dev server game a few years back.
| nozzlegear wrote:
| 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 deja vu.
| piffey wrote:
| 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.
| brunoarueira wrote:
| I had moved out from Gatsby to Astro on my blog/site
| (username.com), mostly because the enormous dependency hell
| full of security issues, I know it's just things to generate
| static files, but it was causing a lot of headaches to upgrade
| and remove the issues. With Astro, I receive a lot less issues
| and the maintenance is easier! From my perspective if
| Cloudflare keep it that way, it'll be a win.
| nozzlegear wrote:
| > 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.
| jakubmazanec wrote:
| 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
| nozzlegear wrote:
| 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.
| Imustaskforhelp wrote:
| 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)
| Otterlord wrote:
| Yep, Astro is and will always be platform-agnostic!
| ndsipa_pomu wrote:
| Did they just break Cloudflare?
| jasona123 wrote:
| 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.
| cdrnsf wrote:
| I don't want a framework that's coupled to a hosting provider.
| pier25 wrote:
| 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
| cdrnsf wrote:
| 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.
| pier25 wrote:
| Astro runs on many JS runtimes. It can be deployed
| anywhere.
| hexbin010 wrote:
| I knew it was too good to last hah
|
| Congratulations!
| Havoc wrote:
| 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.
| victorbjorklund wrote:
| 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.
| sp4cec0wb0y wrote:
| 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?
| victorbjorklund wrote:
| 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.
| dvtkrlbs wrote:
| 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.
| victorbjorklund wrote:
| Let's hope you are being right. Note that I am not
| talking about Astro today but rather Astro in 5 years.
| etchalon wrote:
| Vercel buys frameworks. Cloudflare does the same.
|
| We all lose while they all tell us we're winning.
| ramesh31 wrote:
| Vercel 2.0
| arjie wrote:
| Very nice to see these dev tools get an exit. e.g. I love `uv`
| and friends but did consider that perhaps dev tools are just a
| bad business and then no one will go into making that kind of
| stuff. Good exits means more of these tools.
|
| I have only used Astro for toy stuff but it seemed neat. Congrats
| to the team.
|
| EDIT: To put paid to the sidebar discussion below, yes I meant
| "for instance, consider `uv`; they might do these nice things and
| go nowhere but now that companies like Bun and Astro have gotten
| acquired, it demonstrates a future for others; therefore we will
| get more things like Astral's `uv` and so on". Hope that
| clarifies.
| woodruffw wrote:
| This is Astro, not Astral. uv is Astral :-)
|
| Edit: OP clarified what they meant, I'm sorry for the
| misunderstanding on my part!
| satvikpendem wrote:
| They know, hence why they used e.g., i.e. _exempli gratia_
| woodruffw wrote:
| 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.
| 0xFF0123 wrote:
| cf. would invite a fair bit of confusion on an article
| about cloudflare
| woodruffw wrote:
| 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.)
| arjie wrote:
| 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.
| rdiddly wrote:
| "e.g." IS correct because uv is an example or instance of
| a dev tool.
| scoot wrote:
| "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.
| 725686 wrote:
| For the perplex:
|
| e.g. is latin for "exempli gratia" = for example i.e. is
| latin for "id est" = that is
| huhkerrf wrote:
| A good way to remember it is to use a backronym:
|
| e.g. - example given
|
| i.e. - in effect
| programjames wrote:
| i.e. - in eother (words)
| istjohn wrote:
| in explanation
| spondyl wrote:
| 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
| thayne wrote:
| 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.
| Jenk wrote:
| Frameworks are a category of development tool. Things
| that developers utilitise to be productive.
| badeeya wrote:
| Like coffee?
| thayne wrote:
| 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.
| dvfjsdhgfv wrote:
| 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.).
| css_apologist wrote:
| 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
| JavierFlores09 wrote:
| 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
| stephenr wrote:
| GitHub is without question worse for users now.
| catlifeonmars wrote:
| 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.
| Joeri wrote:
| Realistically to maintain a modern web framework to even a
| minimal standard you need a few people working fulltime on
| it, and more than a few if you want to take it places. There
| needs to be some kind of long term sustainable vehicle for
| funding those developers, either a corporate sponsor or a
| foundation.
|
| So all those frameworks have to end up somewhere, and I'd
| rather it be somewhere else than vercel, as they already own
| way too much of the web frontend space.
| mb2100 wrote:
| that very much depends on your definition of "modern web
| framework".
| re-thc wrote:
| > 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.
| pembrook wrote:
| 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.
| umpalumpaaa wrote:
| I think DevTools can be a very good money maker... I wrote two
| apps that were basically dev tools and they were the biggest of
| my money makers. I think it's easier to make money from dev
| tools that are "apps" than dev tools that are "fundamental
| technologies" though so it probably heavily depends on the type
| of dev tools...
| mikepurvis wrote:
| It's probably also easier to make cottage-industry money from
| a single useful tool and some associated services/consulting
| than it is to turn the whole thing into a big company
| expected to do the hockey stick curve thing (eg Docker).
|
| It'll be interesting to see where Astral ends up landing on
| that; afaik they have a small team and have only raised seed
| money, but who knows.
| CamouflagedKiwi wrote:
| 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 :)
| wbl wrote:
| Docker was not gonna make it as a small individual tool
| as something podman like would get traction in that
| market.
| mikepurvis wrote:
| 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.
| alephnerd wrote:
| > Very nice to see these dev tools get an exit...
|
| You'll see a _lot_ more in the next 12 months ;)
| stephenr wrote:
| > 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.
| twelvedogs wrote:
| yeah the thing about dev tools is that devs love writing them
| and your market is just devs
| reactordev wrote:
| 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.
| stefanos82 wrote:
| I hope they've got rewarded astro...nomically well lol!
|
| My apologies friends, I could not resist!
|
| Congrats Astro team!
| mattgreenrocks wrote:
| 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.
| bigblind wrote:
| 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;
| kylecazar wrote:
| 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.
| wiether wrote:
| 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.
| 1718627440 wrote:
| Availability in Debian, is the measure I personally use.
| shimman wrote:
| 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.
| slfreference wrote:
| 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.
| endorphine wrote:
| > 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?
| endorphine wrote:
| 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?
| yusufnb wrote:
| 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/
| gulugawa wrote:
| This is making me even less interested in trying Astro.
|
| Websites should not be vibe coded.
| Firehawke wrote:
| 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.
| yusufnb wrote:
| The code is vibe-coded. Not the content. Which I think is
| more important for a blog site.
| naiv wrote:
| Love Astro and it is exactly my stack with Cloudflare but wow,
| the "Forward-Looking Statements" disclaimer is longer than the
| press release itself
| bilater wrote:
| Astro to Cloudflare, Bun to Anthropic. Good trend seeing people
| toiling away at OS financially rewarded.
| itsafarqueue wrote:
| Two whole projects. A stampede.
| bilater wrote:
| big beloved projects
| TiredOfLife wrote:
| Big difference is that Anthropic blocks competitors from using
| its products (they literally cut direct api access. Or even
| through 3rd party like Cursor).
| sidcool wrote:
| Cloudflare is getting into static site hosting game, like Vercel.
| mb2100 wrote:
| 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/
| pantulis wrote:
| 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.
| bastawhiz wrote:
| 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!
| mmarian wrote:
| Makes perfect sense. I use Astro with Cloudflare for all my
| frontend projects.
| MaintenanceMode wrote:
| 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.
| 8cvor6j844qw_d6 wrote:
| 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.
| supernes wrote:
| I'm not jumping off Astro yet, but if I did I would probably go
| to Vike (https://vike.dev/)
| isodev wrote:
| Oh wow, Cloudflare enschitification is practically in real time
| right now.
| BenGosub wrote:
| 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.
| Strongbad536 wrote:
| 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.
| chrisweekly wrote:
| Crossing fingers (but not holding breath) this doesn't lead to
| vendor lock-in or otherwise wreck Astro.
| kylehotchkiss wrote:
| 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.
| w10-1 wrote:
| 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?
| re-thc wrote:
| > 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.
| sixo wrote:
| > So why acquire it instead of supporting it?
|
| Lots of reasons, but above all, control.
| frivx wrote:
| is astro any good ? havent tried it yet
| efilife wrote:
| 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
| gulugawa wrote:
| 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.
| Otterlord wrote:
| 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!
| gulugawa wrote:
| 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.
| Otterlord wrote:
| 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.
| 85392_school wrote:
| What are you doing about repeated content?
| promiseofbeans wrote:
| I've been expecting this for a while - their last few releases
| have all had big features included for their cloudflare adapter
| skeptrune wrote:
| This news made my morning. I can't wait to see how they improve
| Astro build times and hosting on Cloudflare.
| GutenYe wrote:
| Congrats! I love Astro and published an i18next plugin
| https://github.com/gutenye/astro-i18next
| rimmontrieu wrote:
| 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
| mmooss wrote:
| 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.
| tonyhart7 wrote:
| 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
| mikodin wrote:
| 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.
| willtemperley wrote:
| 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.
| alexjurkiewicz wrote:
| Developer goodwill. And it probably cost a song.
| some1else wrote:
| 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.
| NicoJuicy wrote:
| 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.
| twelvedogs wrote:
| 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
| jimmyl02 wrote:
| 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.
| bot_user_7a2b99 wrote:
| This is great news for the Astro team. Cloudflare has been doing
| a lot of good things for the open source community lately.
| KetanKhairnar wrote:
| 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.
| alexpadula wrote:
| Awesome!
| kjgkjhfkjf wrote:
| 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.
| dzogchen wrote:
| 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.
| guihubie wrote:
| Astro is life!
| jimmyl02 wrote:
| 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!
| dvcoolarun wrote:
| Open source alone can't sustain companies long-term. Eventually
| everyone needs a bigger, safer home.
___________________________________________________________________
(page generated 2026-01-17 23:01 UTC)