[Rauchg]

> They advertised open standards and then did a bait-and-switch to proprietary systems

I'd love more detail on this. We have made major investments in open source and ensuring Vercel is an open platform.

◆ The Vercel Build Output API exposes all the underlying primitives of the platform for every framework to take advantage of (https://vercel.com/blog/build-output-api)

◆ We've diligently invested in standard-compliant API signatures. Serverless Functions adopted the Node.js request / response standard (as opposed to e.g.: AWS Lambda inventing a new one) and Edge Functions adopt the Web standard. We've joined WinterCG to foster this standardization effort (https://wintercg.org/)

◆ We've always invested in API compatibility between local development, self hosting and Vercel infrastructure (e.g.: `vc dev` is open source https://github.com/vercel/vercel).

◆ We're continuing to invest here. Next.js and Vercel build outputs are always getting more detailed, we're exploring support for running build outputs locally (`vc start`) as an open source offering, etc.

> they don’t seem to care much about security

We added support for your feature request, and security remains the top priority of the company. Some recent ships:

◆ https://vercel.com/changelog/access-tokens-can-now-be-scoped...

◆ https://vercel.com/changelog/share-environment-variables-acr...

◆ https://vercel.com/changelog/expiration-dates-now-available-...

◆ https://vercel.com/changelog/protected-preview-deployments-a...

◆ https://vercel.com/changelog/increased-security-with-view-on...

◆ https://vercel.com/changelog/enhanced-security-with-new-api-...

[satvikpendem]

Thank you Guillermo. One thing I am still curious about is, is there still a difference between serverside rendering and static site generation for things such as next/image, next/font, etc? Last time I tried SSG, next/image was not supported, but I could use a third party tool to optimize my images correctly, so I didn't understand why next/image couldn't do the same optimization at build time without relying on a CDN as in the case of SSR.

[Rauchg]

One fascinating thing (especially in view of this topic) about `next/image` is that the primary reason we decided not to optimize upon `next build` or `next export` is that we'd have all these customers migrating from Gatsby telling us their build performance was holding them back, and a big chunk of that was `sharp` optimization and overly eager static generation. Image optimization fits a "dynamic" model much better.

In fact, look at this example I tweeted today: https://twitter.com/rauchg/status/1620821476499947523

… it shows how Vercel lazily optimizes _specifically_ (1) for the images in viewport and (2) for the devices requesting those images. And new pages and images can be added without redeploying.

I think we could still put image optimization behind a flag with a durable cache at build time (think: `next export --optimize-images`), but it's always been hard to prioritize it as the world moves further away from pure-static solutions

As a userspace alternative, I don't think it'd be too hard to do a post-build script that runs `sharp` on a `source-images` folder, outputs it to `public/static-images` with content-addressable checksums, and sets `cache-control` in `next.config.js` `headers` to `public, max-age=31536000, immutable`. Oh, and you could first check if there work has already been done in `.next/images-cache` or something that the CI provider would cache across builds, to make it a bit faster.

[parttime-hire]

Nextjs edge middlewares broke compatibility with workers by adopting async local storage API.

[Rauchg]

The way to think about our edge runtime is (which is something you're seeing across the board in the industry) is that there's a pure subset of WinterCG APIs, plus Next.js enabling a compatibility layer on top to play nicely with the _vast_ npm ecosystem.

Everything about the feature you're referring to is open source. We're expanding our documentation to better present this compatibility layer.

[ascorbic]

There's no compatibility layer for AsyncLocalStorage though, and it's not something that can be polyfilled without runtime support. Requiring it in Next.js has forced all the other edge runtimes to implement it in its un-standardised form if they want to support Next.js. Putting it on globalThis is particularly egregious in a runtime that's meant to be standards-compliant and championing the AsyncContext standard. And what about Headers.prototype.getAll()? That's a non-standard method on a standard object that is only implemented by Cloudflare, yet Next.js started using it in a patch release. I get it: you have no incentive to make life easier for other runtimes as used by competitors and AsyncLocalStorage is a really useful API, but people should be under no illusion that you're being a good citizen with the standards here.

[Rauchg]

You'll also be happy to hear this :) https://twitter.com/robpalmer2/status/1620869647322189824

> ECMAScript excitement

> Congrats to Justin Ridgewell @vercel & @legendecas on advancing the "Async Context" proposal to Stage 1 at @TC39 today