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.
On inter-island communication, I actually think less is more – I find a lot of the recent big features like this they have added unnecessarily constrain you to doing things a certain way, while the reason I liked Astro in the first place was the simplicity.
You can easily add any global store library to your project to communicate between islands from the very simple (nanostores) to more complex stuff (are people still using mobx, redux, etc?)
I actually would prefer if Astro kept the core more simple, I never understood the point of Astro components for example; always thought their game plan would be to build their own client-side framework like what remix v3 is doing, but currently their components are too limited to make them worth using over just doing everything in react, svelte, or whatever floats your boat.
Astro component is your page's entry point. It's similar to React server component. The typical flow is to fetch data in it, and pass the data to client component written in React or whatever. You can also have pages that are Astro only, without any front-end framework.
Yeah, I know, but since by default the front-end islands are server-rendered with no hydration the lines are blurred between what you would use an .astro component for, and just using for example react.
Personally I only ever use .astro components if I'm 100% sure I will never need any client side interactivity, otherwise it's just easier to ignore them.
I mean, you have to have an .astro file if you want your route to be picked up, and then import and use React components in that file. IIRC, you cannot just directly use React.
Oh right, yeah I get what you're saying now. Indeed I think .astro templates make sense at the page level say to define a layout, and I actually like the syntax of stuffing the server js into a frontmatter style block, it's pretty nice.
The key difference between islands and what we used to do back in the day (js on a static page) is that with an islands approach you architect your site with a components-driven approach where everything encapsulates the js/css/html it needs, then you mark it as an "interactive" island if you actually need client-side js to run – the code is the same, but it either runs only in the server (default) or in both server and client.
I know this sounds similar, but, compared to the more traditional approach, there is a certain simplicity to having everything just be javascript. You can often run the same libraries on both server and client depending on your needs, plus it fulfills the promise of web components in a way that is easier to work with (though WCs have also come a long way!)
I will also say encapsulating everything you just said in a single term, "islands," is a lot simpler and prettier to discuss. At least from my perspective, the naming also makes a lot of sense. Literal islands of interactivity surrounded by an ocean of static.
Islands is just a catchy name I guess. I always thought the markojs terms for it made sense, but are more technical / less catchy: they called it “full page hydration” -> everything needs to be delivered as js and “component level hydration” -> islands, only specific component sub-trees need to be hydrated.
Then “sub-component level hydration” would be resumability like in qwik where only events and their dependencies get serialised as client js.
Yeah. Well to their defense, it is probably to be understood as islands of interactivity lost in a sea of static elements.
The term is definitely more evocative.
You can do this with just about any programming language or scripting language that can render HTML on the server + plain HTML and JS. You could do this with PHP 30 years ago.
Yes and no, php didn’t give you any tools to manage this, most people writing php sites back in the day (including myself) were writing js that was coupled to a specific markup yet was maintained separately. This didn’t scale well.
Then along came libraries like mootools, knockout, etc all the precursors of react, then react changed the game around encapsulation of markup and code into one place, and straightforward data flow.
SPAs were inefficient so server side rendering of js became ubiquitous, islands are a further optimisation of ssr.
This hasn’t happened in a vacuum, if you look at modern php frameworks like inertia they have a lot more in common with Astro than they do the good old 90s php
Same reason vercel buys open source... it makes cloudflare always a great deployment option for all Astro sites, which in turn helps cloudflare's core business.
For example, Cloudflare released their vite plugin which makes it effortless for frameworks that use the vite env API to run inside workerd (meaning you get to use cloudflare service bindings in dev) back in April and only React Router had support for it. Nextjs has no support, the draft PR to add support for Sveltekit has been parked until the next major version, Astro only just added support in their beta 6.0 release 3 days ago
With this acquisition, Astro will probably be first to future updates that increase compatibility with cloudflare. It's smart, and was probably not very expensive (more of an acqui-hire)
So when folks say they want to see big companies invest in open source, this is what that looks like. CF could have kept coasting on what Astro was building, but instead they are paying for it. But in return they get a lot of control.
Well, hopefully more like Go's relationship with Google? The company that pays the bills is their first and most important customer, but as far as I can tell from the outside, the Go team makes its own plans and management doesn't pull rank.
> CF could have kept coasting on what Astro was building, but instead they are paying for it. But in return they get a lot of control.
Supabase pioneered the modern implementation of this model. Probably, RedHat before it? Google also tend to "acquihire" maintainers of popular FOSS projects, like Ben Goodger (Firefox), Scott Remnant (Upstart), Junio Hamano (Git), Guido von Rossum (Python).
So, cloudification: lock the customer into a complex cloud dependent solution they can't easily migrate to some other commodity infrastructure provider.
They can stay open source, but stop putting any effort into supporting deploying to cloudflare's competitors, including accepting PRs for such improvements.
Or they could add features that only work if you deploy via cloudflare.
I also take anything said in an acquisition announcement with a grain of salt. It is pretty common for companies to make changes they said they wouldn't a few years after an acquisition.
Vercel does not make Next.js hard to deploy elsewhere. Next.js runs fine on serverful platforms like Railway, Render, and Heroku. I have run a production Next.js SaaS on Railway for years with no issues.
What Vercel really did was make Next.js work well in serverless environments, which involves a lot of custom infrastructure [0]. Cloudflare wanted that same behavior on CF Workers, but Vercel never open-sourced how they do it, and that is not really their responsibility.
Next.js is not locked to Vercel. The friction shows up when trying to run it in a serverless model without building the same kind of platform Vercel has.
That's always been true. Perhaps even more so as Astro constantly faced an existential battle for a working business. Now they don't have to do that and Cloudflare makes their money on their infra business. Locking Astro up now or in the future gains them very little compared to how much they make with hosted upsell services. [edit: clarity]
It's a static site builder. It creates a static site. HTML, CSS, and JS. That you can then upload literally anywhere.
Once again, what lock in? There is literally nothing to lock in. Explain exactly how they are going to lock somebody in, moreso than the lazy "for now" which you seem to constantly repeat.
No? It's still the same Astro that you can move to any other provider that supports it - and it's just Javascript, so pretty much everyone supports it.
Yes, that's part of the problem, deploying nextjs to cloudflare in the first place used to be an absolute nightmare, let alone the dev experience (I think it's better now)
That doesn't sound too preposterous; I wouldn't assume you'd be able to run a React Router project on Turbopack or Webpack either, and Next.js I think has a way more intricate dependence on the bundler to power a significant chunk of its features.
Definitely irrational. There are lots of logical reasons to dislike Next (like the fact that they pile new shiny bit on top of new shiny bit without caring about the regular user experience) ... but being mad that it can't run on Vite is silly.
It's like being mad that Rails can't run on Python, or that React can't run on jQuery. Next already has its own build system, so of course it doesn't work with another build system.
Luckily DX is much better now with Turbopack as a bundler. First they improved the dev server, now with Turbo builds the production builds are faster as well. Still not fully stable in my opinion, but they will get there.
It's also wise to use monorepo orchestration with build caching like Turborepo.
They did well on the turbo stuff, no doubt about it.
The main bottleneck with big projects in my experience is Typescript. Looking forward to the Go rewrite. :)
I have a question. Why can't Whatsapp or Meta make a markdown INFO only website for small business owners (e.g. technicians, shopkeepers, handyman, etc) using their immense reach and clout. The method of using whatsapp groups to keep users updated of the latest updates is not scalable or open.
too big to deliver simple solutions? youre making way too much sense and this would die in committee or be replaced when someone new needs to justify themselves by launching a new product to supplant an existing one.
It does not read like marketing copy to me, what part of talking about draft PRs and framrworks sounds like marketing speak? They're right that CloudFlare having priority access to new Astro features is beneficial for them.
Not sure how to feel about this! I’ve been known to use em dashes every now and then, but I am indeed a fellow human.
I’m close to the vite plugin in particular and have contributed to multiple frameworks around cf integration (simply because I use cf), that’s why I chose it as an example (and it’s one of Astro 6’s biggest features)
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
This element has an autolocate attribute that will request permission automatically, plus it doesn't supersede the JS api, it simply provides a declarative alternative to it, so sites that follow this negative pattern will keep doing so.
At the same time, there is no reason to not implement this pattern today and require user intent prior to requesting the permission
According to the post, autolocate only does something after a user initiated permission has been granted.
So on the first vist you still need to click the button. On the second visit the callback will be triggered directly.
But, well, nothing prevents a big fat html modal on the page pointing to the button, now does it? If you want to annoy your product^H^H^H^H^H^H^Husers then you can always find ways to do so.
You can use a product and still be critical, especially when layoffs happen, truth is there are a lot of things we don't know about their finances – tailwind definitely is successful by any metrics, they have corporate sponsors that alone give them a healthy MRR (I count at least $100k/month from the sponsors page alone)
I sympathise that it sucks having to fire people, been there. But it sucks more to get fired.
I think a problem is that tailwind has no moat compared to most of those. If it never received any further updates today it would still be effectively feature-complete, save for the occasional new css features.
I don't disagree, but I think differentiating between Tailwind CSS (which is free) and Tailwind UI. Tailwind UI (Tailwind Plus) is a different story I think. It's extremely useful in its current form, but could benefit from more
Yeah, I was referring more to the fact that tailwind didn't have that many other ways to monetise compared to other OSS projects. Their paid templates and courses kinda fulfilled their goal in that way, they made the founders wealthy, but is there a sustainable business there?
Apparently they were 8+ people, in 2024 team size was 6 and were hiring 2 more [0] and in 2020 they had $2m+ ARR [1].
Honestly, while I feel bad for the people who lost their jobs the news aren't exactly surprising. Overhiring is a game for VC funded OSS like bun, not usually a good idea for bootstrapped companies.
You've got an extra "R" in there. In 2020 their only revenue from was non-recurring lifetime software purchases. Like SaaS if you had a 100% churn rate.
Very good point, and I imagine part of the issue here... everything they sell is one-time payment, more of a reason they should have been preparing for the music to stop
I believe you, I'm just going out of the figures they have published. If they had "several times more" annual revenue, then not having a warchest for situations like this is puzzling.
They use a lot of open source libraries, yes, but I think it's about how much of the end product depends on the OSS tool/library. Studios using unreal engine probably don't use that much critical OSS directly – their licensed software probably does. And the software vendors / big studios do donate to tools they depend on, for instance Epic Games donated $1.2m to Blender
AAA usually goes with AAA-tools and frameworks. So Unity, Unreal Engine or even their own engine. OSS might be used, but for smaller parts or as tools for producing their stuff (like browser, editor, etc.). So while they sometimes donate, there is not much reason to give a big sum to a single project. They might be even donating more overall, but separated on multiple different projects.
For example, here's all the code in the svelte integration: https://github.com/withastro/astro/tree/main/packages/integr...
reply