bobfunk

I guess I really need a HN for Agents to submit it to, though :)

Thanks!

Netlify CEO here.

Celebrating by letting everyone in our community join a virtual constellation in Netlispace.

Been incredible seeing the waves of new developers coming onboard during the last year as coding agents transform how people build on the web and opens up real web development for a much wider audience.

Thanks for being part of this.

Yeah interestingly API's in their current form are rarely very good for agents. In many cases tools like Operator using a virtual browser and screenshotting are better for agent interactions than API specs.

This shows we need to build better approaches to agent interactions that are not at the level of "run a virtual browser", but that encodes much more of the workflows available than raw API's do today.

Yeah interestingly API's in their current form are rarely very good for agents. In many cases tools like Operator using a virtual browser and screenshotting are better for agent interactions than API specs.

This shows we need to build better approaches to agent interactions that are not at the level of "run a virtual browser", but that encodes much more of the workflows available than raw API's do today.

No, we're moving starter teams with no credit card on file to the free plan. Wan't to stay on starter plan and get billed for overages instead? Just add a credit card.

You choose the behavior that fits your usecase:

Free plan: no accidental bills, but your site may be suspended if you go over the limits. Starter plan: free as long as you stay under the limits, but you'll get billed for overages.

For what it's worth our head of marketing was the one asking for a speedrun mode, but it just couldn't make the cut in terms of scope :)

Netlify CEO here.

I spotted Little Workshop when I saw https://equinox.space/ on Hacker News and noticed it was running on Netlify. Loved the fluidness, speed and art direction of a game running directly in the browser and working smoothly on my phone.

Immediately thought of them when we started thinking about a 5 million developer celebration and reached out. Love the result :)

Netlify CEO here.

We've had a few open source plan since the early days and it's not going anywhere.

https://www.netlify.com/legal/open-source-policy/

1. Yes. We've forgiven lots and lots of bills over the last 9 years and they haven't gone viral

2. While I've always favored erring towards keeping people's sites up we are currently working on changing the default behavior to never let free sites incur overages

Netlify CEO here.

Our support team has reached out to the user from the thread to let them know they're not getting charged for this.

It's currently our policy to not shut down free sites during traffic spikes that doesn't match attack patterns, but instead forgiving any bills from legitimate mistakes after the fact.

Apologies that this didn't come through in the initial support reply.

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.

No that's obviously not true, we have a data team and the survey is run by our data team as it's been every year.

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.

Netlify founder here.

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.

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.

Netlify CEO and coiner of terms here :)

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.

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.

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.

Cloudflare DNS supports CNAME flattening and you won't be needing the fixed IP address if setting up DNS with them.

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.

Thanks! Appreciate the kind words!

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.

mmm, no? You can just CNAME a any subdomain, etc?

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:

/* /.netlify/functions/app/:splat 200!

You can do the same with Netlify functions. Here's an example:

https://github.com/netlify-labs/netlify-functions-express

Docs are still a bit rough, but the README here should help:

https://github.com/netlify/netlify-dev-plugin#project-detect...

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.

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!

Lots of people use Netlify with GitLab as well. Some using our connection to GitLab and some pushing from GitLab's CI to Netlify via CLI.