251–260 of 409 posts
Earlier quoted context omitted.
They know, hence why they used e.g., i.e. exempli gratia
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.
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.
Used this for a portfolio site and and not sure if this news is good or bad for its future.
Earlier quoted context omitted.
What lock in? They explicitly said: > Staying open to all was a non-negotiable requirement for both us and for Cloudflare. They have deployment guides for practically every provider out there: https://docs.astro.build/en/guides/deploy/ And at the end of the day, most of the deployment is just deploying a static site... Which you can do practically anywhere.
They can stay open source, but stop putting any effort into supporting deploying to cloudflare's competitors, including accepting PRs for such improvements. Or they could add features that only work if you deploy via cloudflare. I also take anything said in an acquisition announcement with a grain of salt. It is pretty common for companies to make changes they said they wouldn't a few years after an acquisition.
Earlier quoted context omitted.
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. Nex…
> Nextjs has no support From what I remember, you can't even run a NextJS app through vite?
Earlier quoted context omitted.
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…
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.
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