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.
Vercel has Next.js, Shopify just acquired Remix, now Netlify Gatsby.
This is bad news for full stack JavaScript applications and ecosystem. This is gonna cause vendor lock-in, it's already showing in some of them. Open source is losing and something needs to change.
I am seeing a future where you have to rewrite your whole app in a different framework just to change hosts.
I recognize that fear. And have made similar observations of the current landscape.
Our hope in this instance is actually that the opposite is true.
The goal of this acquisition is not to OWN a JavaScript framework. Gatsby Inc is far bigger than Gatsby.js
The Gatsby.js project will join the Solid.js and Eleventy open source projects that Netlify already support through full time employment but who's roadmaps and operations are their own. Using those tools is not a means for Netlify to funnel developers into our platform, nor a means to attempt to lock users in. Our philosophy is that an abundance and variety of such tools is good for the web (and as a result good for us). Also that more tools will come in future and that we'd like to try to provide the best experience and support for whatever those might be down the line. We can't own it all. We'd prefer to support it.
Meanwhile, Gatsby Inc have created very powerful build and content orchestration tooling which is currently only available to Gatsby.js users. This acquisition will result in those capabilities being made available to any frameworks further helping all comers to the frameworks landscape.
> Meanwhile, Gatsby Inc have created very powerful build and content orchestration tooling which is currently only available to Gatsby.js users. This acquisition will result in those capabilities being made available to any frameworks further helping all comers to the frameworks landscape.
This sounds ridiculous to me. The "powerful build and content orchestration tooling" of Gatsby Inc. is basically the same stuff that everyone else is doing in this space. This includes:
- The traditional Gatsby competitors (Vercel, GH Pages).
I don't quite agree. Gatsby Inc have been doing a ton of work in this area, and it is really impressive. It's one of the reasons that its platform has been such a draw to larger companies with more complex data and content sourcing needs.
Meanwhile, with so many people talking about the acquisition as if Netlify purely acquired the Gatsby.js framework, I find it helpful to frame it like this:
Gatsby Inc is to Gatsby.js
as
Vercel is to Next.js
I understand that you're a DX at Netlify and your job is to advocate for whatever tech happens to be on your backyard. You openly acknowledged it and I thank you for it.
However, there is still a line that, when crossed, turns you into a regular old spammer. You are walking _very_ close to that line.
The Valhalla platform was "launched" 2 months ago. Even today there's ZERO public technical documentation on it. You can only find a bunch of marketing slides, SEO-ridden blog posts etc. saying that it's great, plus a video showing a few queries against a regular GraphQL server.
Please stop pretending that this quasi-vaporware platform is the best thing since french fries. Thanks.
We plan to do the exact opposite. Right now there are features in Gatsby that were built to support only Gatsby Cloud. I know this all too well as I had to reverse engineer them to implement them on Netlify! We don't want that anymore. I am hoping that Gatsby will be like SvelteKit, Remix, Astro, Nuxt etc and will be platform agnostic again. Whether that's via an adapter pattern (my preference) or something else remains to be seen. This acquisition was not about controlling a framework, just as we don't attempt to control SolidJS or 11ty now.
Counter to this, there’s SvelteKit, for example, which provides „adapters“ for the different platforms, eg. Netlify, Vercel and Cloudflare. I hope that’s the way we’re going to oppose this movement as a whole.
Svelte creator and Vercel employee here. Vercel does indeed invest heavily in Svelte and SvelteKit, not least by employing me and Simon Holthausen (and potentially others in future), but there's no danger of lock-in — we're just two members of a much larger core team. Governance-wise, it's an independent project, and we'd be thrilled if other companies also chose to employ core team members! You can see pull requests like https://github.com/sveltejs/kit/pull/8740 as an example of how we approach the relationship between SvelteKit and Vercel — we're adding a new feature and Vercel will be the first adapter that gets to take advantage of it, but we're careful to design the feature in a platform-agnostic way (we even @'d a Netlify engineer to make sure that they're aware of the work in case they also want to take advantage of it).
Anyway, I'm sure this will be said elsewhere in the thread but it bears repeating — the Next team similarly works hard to make sure that your Next apps can be self-hosted and run on other platforms.
First, I appreciate your response (and overall your life work - we're Svelte.js users, about 60% of our source code is in Svelte, and we have a couple of non-critical-path SvelteKit apps).
While Vercel's intentions are good, and your personal intentions are beyond reproach, this strategy all but ensures eventual vendor lock-in without explicitly saying so. Vercel's compatibility will increase over time and other vendors will have best-effort implementations of certain features, but never the complete feature matrix. The industry (esp. medium/large companies) will quickly pick on the relation of "Vercel is needed for ease of mind when using SvelteKit in production", as I've heard from many companies considering/using Next.js. Do people use Next.js without Vercel? Yes. Do companies evaluating Next.js consider it vendor-locked? If they're experienced, yes.
The way adapters work in SvelteKit doesn't change very fast, in fact it's stable enough that community-created adapters for things like Google Cloud can keep up just with volunteer effort. I do not think what you're describing will happen.
As the Netlify engineer that Rich @'d, I can back him up on this. SvelteKit is still admirably platform agnostic. In fact I think it supported Netlify Edge Functions before it did Vercel's!
I disagree that this is a bad thing. If the frameworks start developing lock-in they can and will be forked. In the meantime, we have multiple competing full-stack JavaScript frameworks that are being actively funded.
Also, I think Netlify and company know that a framework that is locked in won't be adopted. The history of mainstream developer tooling over the last thirty years is a migration away from proprietary languages and frameworks, and it's going to take more than a few rogue JS fullstack frameworks to change that.
I think you’re missing the forest for the trees. Gatsbyjs is as good as dead, but this Valhalla thing has legs, and the Gatsby team (as much of it as they have hired) has deep experience tackling problems around ingesting data from a wide array of sources for efficient web delivery.
Every single fortune 1000 company has the problem Valhalla is trying to solve. Most have painted themselves into a multi-CMS corner and are closer to copy/paste solutions for getting content where it’s needed than the sort of GraphQL approach Gatsby (the company) is advocating.
The marketing-speak here is something like “all your content, no matter where it lives, delivered to your customers, no matter where they are.”
Future prediction: Vercel acquires Netlify.. Especially for the Netlify admin feature where a user can create pages in a WYSIWYG editor and save them in Git. Pretty much would make Wordpress obsolete at that point in my opinion.
These frameworks spit out a bunch of static files to serve, which you can host just about anywhere. They also all use React, which means if you did want to switch frameworks, the majority of your code should be usable either as-is or with a little elbow grease. The situation you describe is just not something I'm worried about
Likely was an acquihire because Gatsby has been dying for a while now. It was my first (post CRA) React framework so I used to have love for it and its been sad to see its decline.
Netfliy is still keeping up for the most part with Vercel though it is definitely behind. My biggest pet peeve with both companies is their pricing model on bandwidth. 1 TB free and then they charge 40-55 bucks for every additional 100GB! That just seems so lop sided to me.
And I can tell you from working at companies that use them that this usually compounds fairly quickly for medium to high traffic sites and you end up paying a lot. It's still worth it (especially if you compare against the dev time to keep things running smoothly) but wish it was cheaper.
In case Netlify folks are reading: I feel like this was written by someone who lives and breathes "composable web architectures" to the point that they forgot to mention what they are, why they're interesting, and how Netlify's support for them is unique.
I think it just means that you can use different stuff together, but I'm having a hard time piecing together how that's new, and why Netlify purchased Gatsby to do this.
Was scanning the page really quickly and though that Netflix had acquired the Gatsby franchise and we could look forward to "Great Gatsby 2 - The Vendetta", "The Greatest Gatsby", "Gatsby Strikes Back" and so on.
Didn't Netlify have layoffs recently? Wouldn't expect a non-public company that needed to layoff +10% of their workforce to have the kind of cash to buy out another company.
I host an old blog on netlify. I don't update it anymore, but a few months ago I started seeing a large uptick in subscribers. They were all subscribing through the netlify subscription form. It was around 8 to 10 new subscribers a day where before it was one every couple months. I emailed several of the new subscribers and got no response. After a few days I strongly suspected these were not real subscribers.
But why would someone waste their time adding a few subscribers to my old, non updated blog everyday? A couple weeks later I got an email from Netlify saying that I was being upgraded to a payment plan because of the amount of activity on my Netlify hosted form.
This kind of stuff is annoying. Netlify had no need to acquire this. They just want to increase their revenue.
As a Hugo user on Netlify, I hope this doesn't affect me negatively.
I would guess its a down-round type of acquisition at the urging of Gatsby's investors and founders. They raised 10M+, this allows their investors and founders to get some liquidity back and Netlify picks it up on the cheap.
Yeah I've seen this for a bunch of startups that weren't profitable and struggled to close a new funding round. They pay back the VCs, the employees get zeroed out, and the execs usually get a retention bonus in the 6 figure range.
As some people mentioned elsewhere, the acquisition is probably more focused on Gatsby Cloud than Gatsby itself (which remains open source), and Gatsby Cloud is a Netlify competitor.
Maybe the way to think about this isn't so much from the perspective of Netflifys leadership, but Gatsby and their founders/investors.
Had Gatsby found a scalable business model?
Maybe this is more of a saving-face/acquihire for Gatsby. Granted, there is potentially some strategic benefit for Netlify, but not enough to justify a large acquisition price (the price is not mentioned in the press-release).
They raised ~$47M and it's not clear how successful they've been. Assuming it's been a bit rocky and this was a soft landing, the my ball park guess is ~$75M.
That's likely a mixture of stock and cash. As it seems to be an acquihire, likely mostly stock in order to retain them.
Netlify Acquires Gatsby Inc. to Accelerate Adoption of Composable Web Architectures
Acquisition of new Valhalla Content Hub platform provides Enterprise developers increased flexibility when building composable web experiences with any modern web framework
Gatsby web framework to remain open source for all developers to use
you realize that organizations that develop open source software can sell support contracts, consulting, services, hosting, etc, all things that generate revenue.
I guess you could have said the same about RedHat, yet IBM acquired them for $34 billion. I wonder why they would pay that much for an open source company? Hmmmm... there must be a reason?
Please don’t take this the wrong way, but that is like saying that AWS EC2 is “just a wrapper” of Xen, or that AWS RDS for PostgreSQL is “just a wrapper” of PostgreSQL. There is an entire business around those with value add/sales/support/marketing as well as a strategy for growth.
The statement doesn't say how much Gatsby was acquired for. Hope that Gatsby equity holders weren't bought out at a steep discount, given the current macro situation.
I know this comment is a joke but in a big production environment, you eventually have to commit to a tech/stack. You can't just change everything every 2 years when a new hotness comes.
I do. I find it better to have the information that I want as static generated in a graphql environment so I can query it wherever I want in the application. Next.js has some "inflexible" rules for the static generated content gathering. For dynamic content both are good.
It's pretty tightly coupled to webpack and has a reputation for being extremely slow to rebuild a site. Fine for small sites but I've heard of painful multiple minute long rebuild cycles for large sites with a lot of content.
They give you really nice incremental builds out of the box, which are particularly easy to set up with gatsby cloud (the actual purchase here). Their abstractions are more opinionated, but a lot more "just works" off the shelf with configuration instead of coding.
This - what I wanted was the incremental builds. Also lots of nice starter templates. I have a custom framework I created for incrementally built docs sites for FastComments - but in the future I was looking into Gatsby for marketing/doc sites.
I am not really a NextJS fan. WordPress is an option but I like having the docs in version control.
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.