4 ms·

Vercel has betrayed my trust and expectations perhaps more than any other provider. They advertised open standards and then did a bait-and-switch to proprietary

Vercel has betrayed my trust and expectations perhaps more than any other provider. They advertised open standards and then did a bait-and-switch to proprietary systems. They also broke our automated deployment pipeline out of the blue and called it a feature, not a bug. They don’t seem to care much about security, either. [1] If you want “old reliable” that works how you expect it to, with the ease of use of a modern platform, and one that won’t break the bank, my pick would be Cloudflare or Render. 1. https://github.com/vercel/vercel/issues/856 https://github.com/vercel/vercel/issues/856

Rauchg 4y ago
> 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 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/ 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 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-to-teams https://vercel.com/changelog/access-tokens-can-now-be-scoped... ◆ https://vercel.com/changelog/share-environment-variables-across-your-team-and-projects https://vercel.com/changelog/share-environment-variables-acr... ◆ https://vercel.com/changelog/expiration-dates-now-available-for-access-tokens https://vercel.com/changelog/expiration-dates-now-available-... ◆ https://vercel.com/changelog/protected-preview-deployments-available-on-all-plans https://vercel.com/changelog/protected-preview-deployments-a... ◆ https://vercel.com/changelog/increased-security-with-view-only-permissions https://vercel.com/changelog/increased-security-with-view-on... ◆ https://vercel.com/changelog/enhanced-security-with-new-api-scopes-for-integrations https://vercel.com/changelog/enhanced-security-with-new-api-...
- satvikpendem 4y ago
  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 4y ago
    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 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 4y ago
  Nextjs edge middlewares broke compatibility with workers by adopting async local storage API.
  - Rauchg 4y ago

Rauchg 4y ago

> 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 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/ 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 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-to-teams https://vercel.com/changelog/access-tokens-can-now-be-scoped... ◆ https://vercel.com/changelog/share-environment-variables-across-your-team-and-projects https://vercel.com/changelog/share-environment-variables-acr... ◆ https://vercel.com/changelog/expiration-dates-now-available-for-access-tokens https://vercel.com/changelog/expiration-dates-now-available-... ◆ https://vercel.com/changelog/protected-preview-deployments-available-on-all-plans https://vercel.com/changelog/protected-preview-deployments-a... ◆ https://vercel.com/changelog/increased-security-with-view-only-permissions https://vercel.com/changelog/increased-security-with-view-on... ◆ https://vercel.com/changelog/enhanced-security-with-new-api-scopes-for-integrations https://vercel.com/changelog/enhanced-security-with-new-api-...

satvikpendem 4y ago
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 4y ago
  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 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 4y ago
Nextjs edge middlewares broke compatibility with workers by adopting async local storage API.
- Rauchg 4y ago