Rauchg

The gist is (which the support engineer referred to as the internal RFC): instead of stripping `cache-control` `s-maxage` / `stale-while-revalidate` values, we should support Targeted HTTP Cache Control[1] (i.e.: `cdn-cache-control` and `vercel-cache-control`).

Vercel strips them because (1) at the time this RFC didn't exist and (2) most of the time you we found customers don't want to cache on the browser side or proxying CDNs, which makes purging and reasoning about cache staleness very difficult.

Another example there is the default `cache-control: public, max-age=0, must-revalidate`. Without that, browsers have very unintuitive caching behavior for dynamic pages.

Customers want to deploy and see their changes instantly. They want to their customers "go to our blog to see the news" and not have to second guess or fear the latest content will be there.

I appreciate Max's feedback and we'll continue to improve the platform.

[1] https://httpwg.org/specs/rfc9213.html

We'll definitely be looking into usage limits after the fix rolls out.

Re-posting my Twitter update[1] here:

We've concluded our analysis.

1. We're refunding the overages

2. We identified the root cause

The root cause is that the Astro bundle handed to the deployment process is monolithic. There was a top-level `await` for an RSS endpoint which called an API with `fetch`. The issue is that these two (and the rest of the app) were bundled together!

Therefore, any time the function was invoked, that top-level `await` was running for all endpoints. It never yielded. And it's fully autonomous, which means it'd keep running regardless of even a browser being open once the chain reaction started.

This is a Swiss Cheese[2] kind of failure. It required the top level await, the monolithic bundle, and the RSS function using `fetch` (i.e.: over the network) rather than `import`-ing the data layer API directly.

Most importantly, what we're doing: we are going to deploy a fix to ensure this doesn't happen again, across frameworks. I really appreciate Mike raising this and hopping on a zoom call with me while our team investigated.

As an addendum for HN: we're continuing to refine the tools and patterns to best "harness" the practically-infinite ability for Serverless and Edge functions to scale horizontally. It's an awesome property, but it's taught us valuable lessons. We've come a long way in adding guardrails and alerts, and this will be another value-added protection that future customers will enjoy.

[1] https://twitter.com/rauchg/status/1644099739959590912

[2] https://en.wikipedia.org/wiki/Swiss_cheese_model

Interestingly, I have the exact opposite bet: “SPAs were a zero interest rate phenomenon”. Putting the burden of compute on clients, and shipping slower apps for the sake of DX and convenience. Customer-first wins.

Looking forward to see how this plays out.

I actually strongly advocate for: SSR and server is the absolute best default[1], and Next.js gives you tremendous flexibility on where to place your compute[2], including skipping SSR altogether[3], with the best-in-class static export that can actually at least put some content in your HTML instead of a blank page[4]

[1] https://rauchg.com/2014/7-principles-of-rich-web-application...

[2] https://twitter.com/rauchg/status/1637136013083684864

[3] https://twitter.com/timneutkens/status/1636693508223270912

[4] https://twitter.com/dan_abramov/status/1636827365677383700

To clarify: there's no "native" fetch to patch. Both Nuxt and Next have been adding it to the runtime to normalize it across Node.js versions and environments, and to add critical capabilities that the Web standard lacked (like being able to read the `set-cookie` header or customize `Host`).

Worth noting: we've been enabling SSR for React since 2016[1], and some of the largest websites on the internet SSR with Next.js: Twitch, Hulu, Nike, and even parts of Amazon[2]

[1] https://vercel.com/blog/next

[2] https://twitter.com/rauchg/status/1594779272945627136

Sorry about the bad experience, can you share what errors you ran into? Feel free to email: rauchg@vercel.com

We’ll try to debug by running the demo ourselves in the mean time!

Nice references, thanks for sharing!

Very excited to see the Rust-ification of Python tooling, similar to what we’re seeing in the JavaScript[1] tooling ecosystem.

[1] https://leerob.io/blog/rust

As another commenter mentions, you can also certainly combine the two technologies, if you don't opt to go full stack with Next.js (e.g.: with Prisma or Kysely, combined with Planetscale)

I'm biased (having started Next.js), but I found a comment on the recent HN thread "The Market for Lemons"[1] thread quite insightful.

Basically, @christophilus makes the case that projects they'd work with always end up "accreting interactivity to the point that I’d wished we had started with a single, unified, well-structured way for managing the UI that handled interactivity well."

I think that's the core argument for Next.js vs Rails. For Next.js, interactivity, fast page loads and transitions, client-side statefulness are priorities. You can import rich UI components from libraries like https://www.tremor.so/ or https://ui.shadcn.com/ or the dozens of others in seconds.

For Rails, the rich, JS-based interactivity model was not a priority. The reason you probably miss `ActiveRecord` is that we certainly didn't start there, and given it was a focus for Rails, it's probably amazing. The Next.js ecosystem is strengthening a lot in that area, so I'm very optimistic we'll get there too.

In a nutshell, Next.js prioritizes the frontend experience. Rails prioritized the backend. Choose the tech that's best aligned to your goals.

With regards to hiring, there's a very active job market[2], and a very large community[3]. Let me know if you found this helpful!

[1] https://news.ycombinator.com/item?id=34666938

[2] https://twitter.com/rauchg/status/1621233983819509760

[3] https://twitter.com/nextjs/status/1620419717319258114

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

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.

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.

> 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-...

That's definitely what RSC accomplishes, which I mentioned in my comment.

> Both then STILL send the full data model to the UI (check the __NEXT_DATA__ on Walmart.com and __TGT_DATA__ on Target.com) because Next.js doesn't quite offer the right amount of control over what to send back (compare this to Astro.js, which does offer control over which data is needed for the client-side binding).

Those two particular customers use `getInitialProps` which allows them to respond which exactly the data they need to render those pages. Can you tell me more about what other capabilities you'd like to see there?

You'll also want to check out our work into React Server Components (https://nextjs.org/blog/next-13#server-components) which addresses both data payload size and bundle size.

> Next.js handling of images is ugly. It creates tag soup for responsive images instead of using native HTML and CSS capabilities (again, compare it to Astro.js and it's night and day).

Have you seen our updated image component? It's just an `<img>` tag, it uses all the native browser capabilities, and doesn't depend on React hydration (it even works with JS off!). Here's a demo[1] and here are the details[2].

> Their stunt and exaggerated numbers with Turbopack further contributes to fracturing the front-end community and introduces Yet Another Tool instead of plugging into Vite.

We've been working really closely with Evan You from Vite to present the data in the most clear way possible. Next time we'll make sure that any project we reference has a chance to submit feedback before we publish. We also contribute to SWC which Vite 4 has shipped plugins for[3]. We're quite confident Turbopack will continue to have a positive impact in the ecosystem.

[1] https://image-component.nextjs.gallery/placeholder

[2] https://nextjs.org/blog/next-13#nextimage

[3] https://vitejs.dev/blog/announcing-vite4.html#new-react-plug...

This is excellent. I've already found it valuable in a few searches, and I've only had it installed for 20 minutes.

We're super excited about partnering with TiDB. This is the first truly serverless HTAP db in the market, which means the average app developer will never have to worry about complex data sync jobs or having entire categories of really slow or expensive queries (…or even worse, limit what their product can do due to insufficient db infrastructure!)

Both things can be true. We continuously improve Next.js _and_ Vercel, and we invest in other frameworks as well (like Svelte[Kit]). Happy to hear any feedback you have about how we can make Next.js even better!

Broadly in agreement, except support is not “random”. It’s deterministic, easily versioned and well tested.

We are improving the DX further so that the feedback loop of what features are supported is nicer, with advice on what to do when some CSS property is unimplemented.

JSX is optional. It’s just a way of representing the nested object hierarchy that happens to be convenient and widely supported (TypeScript has built-in support)

Congrats! Exciting news for YC

Hey jokethrowaway. I'd love to get more color on your experience upgrading your Next.js sites: feel free to email rauchg@vercel.com.

- On local: `npm i && next dev` is guaranteed to be stable.

- On remote: your pipeline is guaranteed to be stable.

If you have an example where this is not the case, please let me know.

Since the post mentions Next.js, it's worth calling out two streams of ongoing work that solve major painpoints of SSR:

1. A filesystem convention (`*.server.ts`) for more cleanly separating client and server component trees

2. The introduction of a Web standards runtime[1] for SSR.

If anything, we're entering the best generation of SSR ever. We'll see new generations of apps shipping less JS to the client, rendering and personalizing at the Edge, closer to the user, and the infrastructure to support this will be serverless and economically every efficient.

[1] https://nextjs.org/docs/api-reference/edge-runtime

I think I misunderstood his comment. I focused on the `index.html` example, but I think he was talking about servers (thanks for pointing that out). That said, the transition was good for servers too depending on what you were using. For example, `package.json` with Next.js was completely seamless!

That never stopped working. Neither on the edge side (as your live site indicates, which has been edge cached for 109 days in San Francisco), or on the deployment site, as the example below shows:

Try it out: https://hi-there.vercel.app

  ▲  /tmp/ mkdir hi-there
  ▲  /tmp/ cd hi-there
  ▲  hi-there/ echo '<h1>hi sillysaurusx</h1>' > index.html
  ▲  hi-there/ vc
  […]
  Inspect: https://vercel.com/rauchg/hi-there [690ms]
  Production: https://hi-there.vercel.app [copied to clipboard] [9s]

In under 10s which includes the project setup and linking prompts. The main difference is that `now` got shorter to `vc`

Happy to hear more feedback on pricing. Please reach out to rauchg@vercel.com

You absolutely can! The data loader concept in Remix is semantically equivalent to `getServerSideProps`

We are making sure both Remix and Next.js work excellently at the edge by compiling down to our Edge Functions primitive (https://vercel.com/edge)

On a high level: if Svelte succeeds, the Web succeeds and Vercel succeeds.

More concretely: we want Rich to help shape Vercel's support for frameworks as an open platform. We want to hear how, as a framework creator, the platform can best serve him. We project this work will have ripple effects like making Astro or Remix better on Vercel, or the next framework you invent. You'll hear about this work soon.

We want to hear what edge infrastructure would make Svelte the fastest for developers and visitors. We want to also help him build a better Svelte by connecting him with customers who are betting on it in production. We want to learn from his DX expertise so that we can make better products.

We are very excited about this and we think betting on Open Source for the SDK together with an Open Platform for infrastructure is the only way to succeed in our space.

Absolutely. A core goal for us is to Lower the Barrier of Entry[1] to building for the Web.

Building a beautiful and fast Web experience needs to feel myspace-code-easy (or as Rich Harris puts it: it has to be fun!). I think ultimately that's what makes the Web win long term. It's open and accessible.

The best way to contribute to this mission is to come in with a fresh mindset, passion and big ambitions. Please reach out: https://vercel.com/careers

[1] https://rauchg.com/2021/making-the-web-faster#realtime