The survey is a reflection of what our community responded.
Next is the largest framework in usage and is really will liked by it's users. This is clearly visible in the charts of the survey.
But for the first time we’ve run this survey, Next decreased in usage year over year (from 47% to 46%).
Astro jumped all the way from 11% to 18% with 87% responding they want to use it more.
Eleventy dropped in usage from our respondents from 19% last year to 16% this year.
None of this is an attack on anyone, it’s just data from our survey. The rise of Astro is one of the most newsworthy bits of data from the survey and reflects genuine excitement in the community we’re part of.
We changed the title to better reflect that the survey asks plenty of questions not directly related to jamstack (like usage of AI tools for web development etc).
Nothing changed in the methodology since last year and as always the survey was run by our data team.
If you scroll past the editorial part of what our team found newsworthy in the data and down to the actual survey data, you'll see clear charts of absolute framework usage and detailed breakdowns on satisfaction for each framework.
But the percentage changes are correct, aren't they? I don't think readers will think that the graphs represents absolute popularity, also (IMO) any survey taken by a company will be used for marketing purposes and should be consumed as such. (It's just some text on the internet, nobody is going to take it as gospel.)
It would be nice if the visualization reflected the information you've shared here (including both the absolutes and the amount of change). Then it wouldn't feel misleading and you would not need to write explainer comments on HN.
The absolutes are in a bar chart in the framework part of the survey that makes the absolute usage from the responses very clear. The chart Zack took issue with is from the editorial part of the survey where we found the biggest news in the framework section to be the growth and satisfaction for Astro.
This comes off as a disingenuous response, by typing out a large block of text while neglecting to address any of the individual concerns written in the article. "it’s just data from our survey" is a cop out -- the presentation of data is just as important as the data itself, and the concerns of underlying bias via communication model presented by Zach all seem reasonable to myself.
It's fine to not be an expert in Data Analysis, and if it's true that the company no longer employs someone with those skills, there should be a greater willingness to make adjustments and corrections when problems are raised with publicized analysis.
I would actually argue that Jamstack has won to the point of basically just being "Modern Web Development" by now.
In the 7 years since I first presented the term at Smashing Conference in San Francisco, I can't think of a single new successful commercial CMS that hasn't been headless or API first. I can't think of a single new successful commerce platform that's launched in that period, that hasn't been headless or API driven.
On the contrary, big existing players have mostly changed their strategy. Shopify is more and more embracing a decoupled approach of building globally distributed shop UI's with Remix (running either on their own platform or places like Netlify or Cloudflare) pulling in products, pricing and check out flows from their API layer. Most existing CMS companies have started integrating API first approaches into their strategy and in the data space we've seen an explosion of "Database as API" from Neon, to Supabase, to Xata or Converx, etc...
Part of the confusion has always been the conflation of Jamstack with "static" when even my first presentation on Jamstack back in 2016 had a big slide with the word static crossed out to underline that I personally didn't intend to conflate the two. The real game changer for treating the web UI as it's own decoupled application, and the backend as a set of API and services where some are your own running your core business logic, but a lot of them are provided by external providers.
At Netlify we're now focusing less on evangelizing the Jamstack approach of treating the web UI as it's own decoupled, independent layer, running on top of API's rather than stuffed into your backend systems - and more on helping really large companies adopt this at scale for their core web architectures (Composable Architectures). But not because we're any less bullish on the first part, on the contrary - because we don't really have to anymore!
And the article's conclusion that we somehow failed is absurd. Sites and apps on Netlify are visited by more than a billion unique visitors a month, we delivered more than 10 Petabyte of
data out of our network in December alone, have onboarded more than 4 million developers to our platform, and continue to prove that we can scale this architecture to some of the largest and most complex companies in the world, running big complex projects with faster time to market, higher productivity and higher conversions and revenue.
JAMStack isn't modern web development. 80% of the internet still runs on PHP on traditional servers. Netlify is needless complexity (nevermind the vendor lock-in) 99% of developers will never need.
You also don't address the OP's points where Netlify has suffered the same fate of "enshitification" where features slowly get stripped out and moved into pay to use buckets, likely at the behest of needing to payback 100+ million dollars in VC funding.
Your comment doesn’t refute the idea that JAMStack isn’t modern web development. All you did was pull up the over-used statistic of “80% of the web is PHP” which I’ve heard for well over a decade. It may have been true at one point, but I highly doubt it is now. (Citation needed)
Netlify has done nothing but innovate and push the needle forward for front-end devs. I’ll be there until there’s a VERY strong reason not to be.
PHP is know for being very leaky about being PHP (and since PHP + ecosystem have a bad history of CVEs, being leaky about being PHP is not cool).
Java/Kotlin/Go/Rust/Ruby/Python/JS/TS are a lot less leaky about what language the server-side is written in. Usually the webserver used advertises itself name and in a server string, but it is considered bad practice and thus often switched off.
Reading "php" extensions in paths is a clear giveaway, so are "htm" extensions for microsoft products. Tools usually guess the language/framework based on some of these giveaways and the better the tools the less this is evident.
I jut checked some web apps I worked on, and only the one I last touched 10+ years ago is detected with buildwith.com; it's a Rails site.
All the Java/Kotlin/Rust/Hasura+Elm apps I worked on since are now shown as "Nginx" (the rev proxy in front of it).
I just checked the day gig site... builtwith claims it's using Webflow and Apollo GraphQL (Neither of which it is) and doesn't mention at all the language it's actually implemented in (Python), although that's not surprising since it's an in house framework.
> How is being “leaky” in any way bad or even good?
Information-gathering is a common early step in any attack against a system; knowing the language & libraries involved (especially their versions) allows you to search for any existing CVEs that apply.
> Are you advocating “security by obscurity”?
I don't think OP was implying that security by obscurity alone is sufficient, just that it's unwise to advertise information that's not relevant to end users, that could help would-be attackers.
While it kind of is security by obscurity, it's a very basic piece of server hardening to stop telling potential attackers what software you're using (within reason).
Back in the day (!), server software used to honestly respond with things like the software name and exact version number it was running.
Naturally, that meant scanning for vulnerabilities was a lot easier than it needed to be.
Not true. There are some real cryptographic realities that are based in "open" math principles.
There's also the way of most using runtimes/libraries that (constantly) have CVEs in them; and understanding why it is that these languages have CVEs in the first place (see my comment on "eval()").
If you languages has "eval()" or something similar, it is a lot easier to attack. Same for when it allow you "upload a file in some place where it gets executed".
These things are not so easy, say, with a C++/Rust/Go app. Or even in most JVM configurations. JS has similar issues, that Deno is trying to mitigate to some extend.
obviously being properly secure is better. but if you leave your unlocked, it's better to not also hang a sign above it saying "this door is unlocked".
obscurity is absolutely part of good security practice, as long as it's not all you're relying on.
If people are picking up non-JAMstack solutions for greenfield web development, then that means JAMstack is just one of many options for "modern web development". (Along with Laravel, Rails, Django, and even/especially Wordpress, depending on how we gatekeep what we mean by "web development")
Objectively speaking our free tier today have far more features, higher limits and more capabilities than it's ever had before.
We are also building a real, longterm sustainable enterprise business. We're not a non-profit and we're here to create a big lasting company that can keep investing into the future of the web.
Almost every feature you charge for is something you can achieve for free inside of a basic VPS. I understand you have the classic SV "Hotel California" model where you can check in but you can never leave. But frankly this makes the internet worse in every way possible and part of the point of the original article.
I gotta say, this comment really comes across as being written by someone who has quite literally never tried Netlify, or doesn’t understand the value prop at all.
Seriously, it is orders of magnitude faster to deploy a static website on Netlify - simply drag and drop a folder from desktop - than it is to spin up just a single VPS on Vultr… and by the time you’ve configured that VPS, I could have done a dozen revisions to the website, and it would still be more difficult to deploy updates to the VPS than to Vultr. Don’t even get me started on the complexity of a global CDN.
Do I wish all of Netlify was free? Sure, yes I do. Does this mean it’s not valuable? Of course not.
The irony of this is that you seem to be saying that (a) Netlify locks the customer in with useless features, and (b) it can be trivially reimplemented in an entirely custom but otherwise “free” VPS.
The real question is, which “free” VPS are you going to use that will serve the same capacity as Netlify’s paid plans? AWS? Do you think you can avoid lock-in using AWS - of all things?!
No, you asked for a free comparison. If you want to go to paid features netlify loses by a mile. You can search all of this yourself with all of one google query.
I didn't ask for anything. I am just responding to your comment. You said:
> Almost every feature you charge for is something you can achieve for free inside of a basic VPS
I have plenty of experience with both Netlify and VMs, and I don't think they are even remotely comparable.
> You can search all of this yourself with all of one google query.
You're the one making the claims - I'm not even sure what I would be searching for since the parameters of a VM are vastly different to those for Netlify. How could I even find TTFB for a free Oracle VM? In fact, my personal experience with Oracle VMs (granted it's from before 2018) is that the jitter would be very high, such that any TTFB would probably be meaningless. And it would depend on the deployment region, too. Not to mention the HTTP server being used.
Words are cheap. Unless you're willing to substantiate your claims with some actual facts, nobody learns anything.
You are definitely getting much much more with a free VPS than with netlify. Netlify's value is in being easy, not cheap. If your argument is for being cheap then you will lose that argument all day, every day.
You really need to explain this. Honestly. Actual numbers.
Netlify’s free plan is awesome. You might get more bandwidth with a VPS. But you won’t get a CDN and you won’t get atomic deployments without a bunch of work. You’ll use half your VPS storage on the operating system. You’ll need to keep updating your software and maintaining backups. You’ll spend hours or weeks a year maintaining this thing, versus zero for Netlify.
It’s not just about the cost of bandwidth or storage. You gotta compare like with like.
You can't compare like with like. How will netlify compare with the below?
1. Full server control (install any package)
2. Host any kind of server - Django, Rails, etc. etc.
3. Run database servers: MySQL, PostgreSQL, MongoDB, etc.
4. Background processes (cron or systemd)
5. Run VPNs and proxy servers for personal use at the same time.
6. Host email servers
7. Multi-purpose usage (Use for remote dev environments, cloud storage, AI/ML platforms, etc.)
You know you have to secure, patch, and monitor a VPS right? Why pay for a VPS at all? You can get more compute, memory, and storage with a dedicated server for the same price and even setup multiple VMs on that server, each with all the features of a VPS “for free”.
The difference is I'm not out touting using a VPS as "The next generation of web development" and having payola articles written that if you don't use a VPS then your career is going to get left behind.
Setting up a VPS is pretty easy. Ensuring your VPS is configured to restart your app when the server restarts, maintaining OS and library updates, maintaining security, updating the app itself with simple-enough conventions, and configuring monitoring is not so necessarily easy. That’s not including documenting (even if only for your own future reference) how things are configured.
Digital Ocean in particular has great guides to get you from the starting line to something that in most cases will work okay, but as a long-term solution to “I have an app I want to run on some infrastructure”, I agree that there’s a non-zero cost to managing a server that, like you, I’d much rather not deal with.
>80% of the internet still runs on PHP on traditional servers.
Do they? Or do they just use Wordpress? This is important to differentiate because people's idea of PHP on traditional servers ITT is a far cry from setting up wordpress.
Netlify worked for me when all we did was basic static hosting for about $500 a year. Then they wanted to up us to about 10k a year and suddenly the cost was significantly worse. The only reason we didn't dump it is because we didn't have enough engineers to swap it to something else because we had projects that needed to be done, but it was our top optional priority.
Unfortunately netlify went from loved to hated overnight.
what vendor lock in? Netlify at its core is still quite simple: pull stuff in from GitHub/Lab, run the build commands in an Ubuntu VM and publish the results.
Sure, there are some plugins that you can use to transmute the result builds and there's Edge functions, but nothing is hard to move to another provider.
> I would actually argue that Jamstack has won to the point of basically just being "Modern Web Development" by now.
Don't you think there might be just a little bit of hubris creeping in here? JAMSTACK is such a niche/fringe it's not worth talking about. I'm a solo dev and network with many others. I don't think I've ever heard JAMSTACK mentioned let alone adopted. You're living in a self-generated bubble.
I've been doing web development since 1997, but posts like these let me know how far out of the loop I have become. I have no idea what Jamstack, Netlify, Headless CMS, etc. even are. I'm still in the: here is a webpage (html, css, js) that makes an ajax/fetch call to a webservice that SQL queries a Postgres database and returns the results as a JSON string.
Honestly, I've just finished 5 years as CTO with an e-com company with our CMS built on Elixir and I can't tell you how wrong you are. Jamstack, headless CMS and SPA frontends etc are just a massive waste of time. There's no joy in having separate code for your API and frontend.
I worked at an ecom that used Elixir instead of an spa, with the backend being the older legacy app, and elixir rendering pages based off API data from the backend. This was well before live view
It worked amazingly fast. Some things were painful, and would have been better served with some progressive enhancement via a dollop of frontend js, but they were rather small exceptions
When I left a few years back they'd undergone some leadership turnover and the new wanted to migrate to some messy jamstack thing. They had millions of SKUs. Last I heard they migration hadn't gone anywhere
Tale as old as time lol. Elixir is uniquely great at content sites due to the fast template rendering - but it’s really not about Ex at all. Just don’t drown in unnecessary moving parts and build tools. It’s just a website.
LiveView wasn’t ready yet when I started our startup (react on front, Elixir and Hasura on back).
But man, I wish it had been. React is nice enough but the idea of not having to redefine my types at several different layers and fight with npm sounds like a dream.
We were in a similar position. CMS ran on dead views with a bit of progressive enhancement first, and then we had a couple of react apps around for interactive parts. When liveview was released we tried it out and it basically “just worked” as much as a software lib can, so set about getting rid of the react.
Sure: key idea is pages are documents. Each page contains a JSON blob which specifies the blocks it's made up of and the content for each block. Each block is just a module with a schema specifying the data it takes and an associated template and a render function. Rendering a page is a URL resolution -> Controller -> DB lookup for the page -> pass the block list to a master render function and done.
The thing some people don't realise is EEx is compiled to a function call, which means no string interpolation, regex whatever. Getting a bunch of HTML is just a function call.
Jamstack is "Modern Web Development"? Are we back to that point in the webdev rollercoaster where everyone pretends like embedding business logic in a client using javascript is a good idea?
The author never actually articulated what his beef was with Netlify. So yeah I think you're just as confused as the rest of us. Apparently Netlify was supposed to become Heroku, but Heroku is bad, but Render (which is... Heroku with a fresh coat of paint) isn't? I dunno.
Render seems to have autoscaling with a reasonable round-robin load balancer [1], whereas Heroku only has autoscaling in (expensive) Private Spaces [2] with a dumb load balancer [3].
Yo. Thanks for Netlify. It’s legit and I, for one, welcome our new overlords.
All jesting aside it’s easily one of the most pleasant developer experiences you can have as a modern web dev in 2023. Everything just works and failures are loud, obvious, and usually dead simple to fix.
FWIW, I love you, Netlify CEO. I've got a bunch of different static-ish websites hosted with you---my personal site, the sites for three different books, etc., etc. Everything is build using the CI, with a different frameworks and/or build processes (essentially whatever I felt like playing with at the time), and it makes it incredibly easy and cheap. So don't listen to the haters.
I don’t really understand the concept of Jamstack or why it’s new. Isn’t it just HTML+JS (whether built with a framework such as Angular, React, Svelte, Gatsby, etc) that uses a backend api? What exactly are we discovering? What is the innovation here? Markdown?
So far Netlify Edge Functions runs before the cache layer, so you can actually use a minimal function to rewrite the URL to remove all unique params, etc, and then let it pass through our system to a Netlify Function which runs behind our caching layer.
For anything you can do at build time as a static HTML pages we already strip query parameters from cache keys.
Interesting, thanks... do you have any docs on how we might achieve this with Next.js? Am I right in thinking we would have essentially a custom Edge Function first that handles query params, and then a second Edge Function that renders the Next app?
I work at Netlify on framework integrations. Next has beta support for running the whole app at the edge, and Netlify supports that. If you create you own custom edge functions they will run first, so you can do just that. You can also run Next "normally" (i.e. in the node-based Netlify Functions) and run your own edge functions in front of that. In those you can modify the Request in any way you'd like, before passing it on to the origin.
One of the big reasons for going with Deno is that it's an open runtime closely based on web standards. You can download the open source Deno Cli and all code written for our edge layer will run exactly the same there.
As more and more front-end frameworks starts leaning in on running part of their code at the edge, we felt it was important to champion and open, portable runtime for this layer vs a proprietary runtime tied to a specific platform.
Netlify CEO here. I'll try to answer the questions from the thread so far:
Some of our customers are affected by an outage of Googles Load Balancer.
These customers are not taking advantage of our DNS management, or they are not using a DNS provider that supports CNAME flattening and are using their root domain name for their website (ie, no www prefix).
While we don't recommend the setup, we do provide a single IP address to bind an A records for customers that want it.
In general we run our edge infrastructure as a large multicloud setup spanning several different network providers, and offer two separate networks, one for free/self-serve customers that will get newer features faster and one for enterprise customers running mission critical projects where we guarantee very high uptime and reliability through formal SLAs.
The single IP mentioned above however corresponds to a Google Load Balancer, and they are unfortunately currently having an outage for all load balancers in the relevant region. Read more on https://status.cloud.google.com/
Again, while we generally don't recommend using the A name setup for anything mission critical, we are currently doing everything we possible can helping enterprise customers that have chosen this setup to change their configuration.
Really sorry for all the trouble this are causing for our users, full RCA will be forthcoming.
> These customers are not taking advantage of our DNS management
I think I understand the point you are trying to make, that customers who are utilizing Netlify DNS Management are unaffected because reasons, but this is phrased in a way that implies that it is your users fault for this downtime because they didn't chose to use your related service.
Full RCA with the steps the team has taken to improve this setup will be coming soon. The main issue with AWS's DNS solution, in this context, is that they don't support ALIAS records or similar techniques (CNAME flattening, etc) for A records pointing to any external provider. That limits our options a lot in terms of what we can do, since anyone using this setup need to point all their traffic to one or more fixed IP addresses.
Our current solution for the free/self-serve tier of Netlify has been to rely on Google's load balancer product to give people a stable IP pointing to a highly available solution. In light of recent issues, our team has setup a new permanent IP for A records (75.2.60.5) backed by a different solution, but due to the way DNS providers with no ALIAS record support work, it does require our customers to manually change their A records.
I totally get that moving DNS providers is a big deal and we want to give the best experience we can regardless of what provider you're on, but we have to work within the technical limitations of those providers and it's the nature of things that we do have more options to deliver a completely seemless experience when we operate both the DNS and the edge layer for customers.
Route 53 General Manager here. Flattening of external provider CNAMEs has a number of availability and accuracy risks. Route 53 offers a 100% availability SLA, and we really mean it. We’ve heard over and over from customers that reliability is our most valuable feature. We can’t provide that same reliability when external queries are in the mix; if we query asynchronously then features such as geo-based routing don’t work as expected for customers. If we query synchronously, then latency and availability are impacted directly.
We do offer ALIAS records between Route 53 hosted zones, and this capability is open to providers such as Netlify. We’d be happy to have customers ALIAS to a hosted zone managed and updated by Netlify. It sounds like your IP addresses are relatively stable, keeping these in sync doesn’t sound like it would be a big deal, and would give you a lever you could pull to change your customer DNS quickly in an event such as this. You could also configure health checks on your own DNS records, which any customer ALIAS records that point to your DNS records in Route 53 would inherit.
If you’re interested in going this route, please contact me at alecpete <at> amazon <dot> com.
If each Route 53 POP is already close to the querying DNS client, then things like geo routing with cached answers might just work well enough in most cases? With each POP having its own cache.
Auto-refreshing the popular records in the background before the TTL expires to help smooth over any temporary issues?
Other big name DNS providers have ALIAS type records. I imagine according to the SLA, AWS Route 53 is still "available", even if it can't resolve a "target address record" (as the ANAME draft calls them) but Route 53 is still able to respond.
Phrasing can always be better but the point is that there's a way to map your DNS to Netlify which is risky and Netlify hasn't made the aggressive decision of blocking it. They outline in their docs all the reasons why you shouldn't do it, provide instructions for how to avoid it and also offer (but do not require) a hosted DNS setup which avoids this pitfall by design.
Some folks still choose to use this way, some have no other choice for various reasons and some don't care/comprehend the potential pitfalls. I do believe most users avoid using a root domain name for their website.
As someone who is a little clueless about network infrastructure: if I own "dwrodri.com", and I'm not running a bunch of other services which need to point to this domain, is there any reason why I wouldn't have my root domain pointed to my personal website?
I would personally imagine that any individual or SOHO business hosting their website on GitHub/GitLab would just buy "MomAndPopShop.com" and point it there. I guess I don't know off the top of my head how many of those sorts of places on the web still exist...
The problem is not that they're pointing their apex domain to a personal website; the problem is that they have a CNAME record in place for their apex domain, which is not actually allowed per the DNS standards
This should not be the case; if you'd like, Netlify's Support team will be happy to review your settings to help discover why it didn't help you out (start from https://netlify.com/support) and ensure that you are "futureproofed"!
I switched to using your DNS to resolve this issue, but https://js.la is still busted and because I'm using your DNS, I can't manually set the A record to go to the workaround IP address.
"These customers are not taking advantage of our DNS management"
You're right. I'm using Cloudflare's DNS. I trust them more than I trust Netlify and that's just a function of their size vs Netlify's size. This response needed better wording.
Depending on your config, another DNS related issue with Netlify is the way NS1.com (their vendor) handles domain names. A domain can only be added to one NS1 account. So if Netlify adds to their account internally, you can't use NS1 and vice versa.
Honestly, "not taking advantage of our DNS management" is a garbage response. We use AWS for our DNS management. If you offer a configuration, you should support it fully.
Our sites have been down for 3 hours now, and you're blaming someone else? We have 5 properties on Netlify now and will have 0 this time next week.
Yes, it is our fault for believing Netlify had contingency plans as hosting is their core business. We're fixing this mistake now so that our customers don't have the same experience.
Nobody is telling parent's customers how to feel. But the OP suggests that Netlify customers should be faulted for choosing the the wrong setup. Broken trust goes all the way down the chain, which is why the middle links have every reason to get ticked off.
The difference is that Netlify communicated the risks to its customers, something other parts of the chain apparently did not do, in addition to not evaluating the risks presented to them by Netlify.
Did you read the docs [1] before writing this? Putting a "(recommended)" on one branch of configuration instructions isn't the same as saying that the other option has a single point of failure. Also, people on both sides of a service don't have the same responsibilities - that's the whole point of the service.
Communicating about risks OR outages are both hard, and every company has both. I'm actually a happy (though impacted) Netlify customer. But it's completely bizarre to me to try to invalidate this customer's complaint.
Yes, I’ve visited that page before today. I admit my familiarity with these DNS setups may have made the tradeoff jump out at me. No problem invalidating the complaint.
I'm not sure your organization's setup with Netlify but isn't the whole point of Serverless to be... "serverless"? I could migrate twice the amount of properties you have to another provider in less than 3 hours...
I get your frustration but maybe cut some slack. If anything is mission critical, you should have had a backup plan if Netlify, Vercel, Cloudflare, or something else.
We use(d) Netlify for the frontend. I agree, our mistake was believing Netlify could be used for more than toy websites and took care of backup plans for us. Clearly they do not.
It's not just migrating the front-end if they're also using other functionalities like Netlify functions, forms, authentications etc. Netlify is not just static file hosting.
Whereas on Zeit Now the root of the website can be a web server written in multiple languages, and offer the ability to make your own "Lambda Builder" if necessary https://zeit.co/docs/v2/deployments/builders/overview
You can rewrite URLs to serve the main website as well. We're generally bullish on but DJing server side rendering, but a rule like this totally works:
Yeah, we integrate pretty deeply already. We do have some new flows that could potentially make the story around publishing to Netlify from GitLab cloud seamless from an authentication standpoint, would be happy to brainstorm!
The one thing I've experienced on this front that was clunky was integration between netlify and self-hosted Gitlab. If y'all could come up for a solution for that (which is prettier than "manual" deploy using webhook), I'd love both of your companies even more than I already do.
I just built a test site with Netlify + GitLab. Why must I give it full access to all of my GitLab repositories? I just want to deploy 1 repo. Seems like that opens up unnecessary possibilities for a security breach.
It's the only option with the current OAuth model, however, we only use the token generated in your web browser, and talk directly to GitLab's API from there. We use the token to add a deploy key and a webhook to the specific repository we're linking to, and after that it's discarded. That way there's no long lived token stored on our end that has access to your whole account.
We started out bootstrapping and were profitable before our first round of funding. However, we always strongly believed that the larger vision of what we wanted to build would be impossible to achieve without outside funding.
How did you decide when it was time to stop bootstrapping and raise a round? Was there a magic number traction-wise (total users, MRR, etc) or was it motivated by the desire to staff up a team and execute on your product vision?
The survey is a reflection of what our community responded.
Next is the largest framework in usage and is really will liked by it's users. This is clearly visible in the charts of the survey.
But for the first time we’ve run this survey, Next decreased in usage year over year (from 47% to 46%).
Astro jumped all the way from 11% to 18% with 87% responding they want to use it more.
Eleventy dropped in usage from our respondents from 19% last year to 16% this year.
None of this is an attack on anyone, it’s just data from our survey. The rise of Astro is one of the most newsworthy bits of data from the survey and reflects genuine excitement in the community we’re part of.