Netlify lost my trust a year ago when they tried to increase our company's pricing more than 10x. (We were paying ~$200/mo, then they tried to force us into a $2,500+ plan because we were 1 seat over their self-serve threshold.)
From my perspective, they were adding features just to find ways to grow revenue. (I get it, you don't have a huge moat by simply hosting static sites.) But their features seemed very out of touch with our needs, and I can't imagine we were the only ones.
As a Gatsby user on a large-scale website, I'm disappointed to see this acquisition because I'll now constantly be worried they'll try to pull a similar stunt with Gatsby.
Since then, I've been using Next.js + Vercel on side projects, and now with this acquisition, I don't see that changing going forward.
Trust and loyalty is everything in the developer community. It's hard to gain and easy to break. Hopefully other developer-focused alternatives will keep this first and foremost in their head so we don't end up in this situation with other platforms down the road.
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.
> 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:
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.
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.
… 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.
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.
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.
They did this to us as well. And not only this, but they blocked our ability to push new releases until we opted into the new plan. And this literally happened on the day of a major release for our biggest client. It felt like we were being held at gunpoint.
We called them and begged them to give us an extension so we could perform the release, and their sales rep treated us like we were the irresponsible ones for not reading the emails they had sent us carefully enough.
We've since moved to Vercel and will never use Netlify again because of the way they managed this.
IIRC they had recently added a user cap on self-serve customers which was new and led to this. The new pricing deck they sent was "It will be $3,500/mo, but until the end of the month, you can get it for only $2,500!" (Pricing approx.)
But it's not to host a static site, it's one click CD, multiple environments, global CDN, and a few more things. I'm not going to say how mu h it is worth, but if you just want a static site with a domain you can do it for free/sub $10 on many many providers.
Sounds like the OP didn't ask for or want those things. I think it's reasonable to be annoyed that a cheap tier that provides exactly what you want and nothing more has been taken away.
SSO is probably the only thing. Other than that, no idea. Netlify pulled the same stunt with us and we left. They must have burned many bridges by now.
That's not a fair comparison. Looki at Netlify[0] and Vercel's [1] pricing sites, the per-user pricing for the "pro" tiers is the same and Vercel gates the features that are in the Netlify "business" tier behind an enterprise contact-us paywall.
I suspect that if you're using these "as expected", your bill on both sites would be the same.
Digital Ocean's App Platform looks to still do basic static sites at a reasonable rate (free for up to 3 sites). I've been a very happy App Platform customer, although not using static sites.
From my perspective, they were adding features just to find ways to grow revenue. (I get it, you don't have a huge moat by simply hosting static sites.) But their features seemed very out of touch with our needs, and I can't imagine we were the only ones.
As a Gatsby user on a large-scale website, I'm disappointed to see this acquisition because I'll now constantly be worried they'll try to pull a similar stunt with Gatsby.
Since then, I've been using Next.js + Vercel on side projects, and now with this acquisition, I don't see that changing going forward.
Trust and loyalty is everything in the developer community. It's hard to gain and easy to break. Hopefully other developer-focused alternatives will keep this first and foremost in their head so we don't end up in this situation with other platforms down the road.