Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We Need To Talk About Vercel

maxcountryman.com

Post reply on HN
Print view View original

51–60 of 161 posts

Re: We Need To Talk About Vercel

#51

Post by flimsypremise »

leerob wrote: post #30
flimsypremise wrote: post #28

My sense of Vercel (mostly from working with NextJS) is that they are more interested in appearing to support an open source framework while making their product as difficult to interoperate with other technologies as possible in an attempt to lock users into their platform and hopefully pay for it.

Hey, I'm on the team at Vercel. What could we do better? Open to your feedback. Our platform integrates with 30+ frameworks ( https://vercel.com/docs/frameworks ), we directly fund the development of Next.js and Svelte, and we sponsor Nuxt, Astro, Solid, and more.

I'd say one of the big annoyances I've encountered while building applications with the last few versions of NextJS is the increasingly tight integration with the built-in server. The world of Node servers is pretty well-established, with documented interfaces that the major server platforms all implement and support. Simple stuff like res and req in the context and what those objects contain. With each release NextJS breaks a bit more of those interfaces and replaces them with approaches that are very specific to NextJS and pretty unintuitive to anyone who is used to building servers in Node. I'm talking about stuff like handling response codes (the notFound parameter you need to return to get a 404 from getServerSideProps is a particularly egregious example) or redirects. You are presented with what looks like a standard interface, but doesn't fundamentally actually work anything that interface.

Decades of working in this industry have taught me to value interoperability, modularity and standardization. I love the idea of a framework that makes SSR easy, and the idea of static site generation, and a router that uses the pages approach where each file is a route is handy in some cases (though very clumsy in others), but all of those a different things and aren't really something I need a single monolithic framework for. I may want one or some or none of those things based on what project I'm working on. If NextJS makes it harder to pick and choose what I want to use, or makes some features contingent on using other features I don't really care about, I'm going to start looking really hard for an option that gives me more choices.

Re: We Need To Talk About Vercel

#52

Post by tipiirai »

leerob wrote: post #3

[Lee from Vercel] Max reached out to me today (Sunday) after this experience, and I worked with him this evening get to a resolution for his site on the Vercel free tier. I'm really sorry we weren't able to get to a resolution faster. I've concluded it's not an issue with the Vercel Edge Network based on the reproduction he provided and pushed documentation and example updates (see below). I know Max spent a lot of t…

Please note that the above comment is super carefully written, because Vercel puts tremendous efforts into their public image and marketing. However, their real support is terrible, as pointed out in the article.

Re: We Need To Talk About Vercel

#53

Post by Atlas22 »

jacooper wrote: post #25
ilrwbwrkhv wrote: post #8

If anyone needs a CDN, please use BunnyCDN. I have tried almost every other major CDN and it just blows everything else out of the water. Regarding Vercel, they do have quite poor support so it doesn't feel rock solid and dependable. They are a great start though, but then ideally you should just switch to bare metal on Hetzner or something when you are earning serious money from your business.

Honestly nothing compares to bandwidth free expenses with cloudflare especially with cloudflare R2. Also having different pricing for every region is very annoying.

The free version of cloudflare is essentially a "fair-use" offering, meaning that it is free until they decide its no longer free for you at their sole discretion [0]. Their terms of service prohibits distribution of any "disproportionate percentage" of non-HTML content [1]. That includes most of what you would want a CDN for: video, images, audio, binaries.

They have exercised this discretion repeatedly for significant bandwidth users, usually in the form of "You need to upgrade to the enterprise plan or we will terminate services for your site." One of my sites got the enterprise "offer" after serving single digit TB in a month. Running on a real CDN from the start would have been cheaper than inevitably getting extorted to a large price for or terminated with little to no time to migrate things.

[0] Section 2.6 https://www.cloudflare.com/terms/ [1] Section 2.8 https://www.cloudflare.com/terms/

Re: We Need To Talk About Vercel

#54

Post by comex »

HeavyFeather wrote: post #26
klabb3 wrote: post #20

Earlier quoted context omitted.

A cdn is largely a value prop to reduce latency for static web pages, so that someone coming from a link get a page load asap. Once you have a dynamic or hybrid app, the value diminishes rather quickly, I assume. Potentially it could become negative if you have different points of failures and cache inconsistencies.

> Potentially Unless CloudFlare cables are somehow shinier than the rest of the internet’s, adding one hop almost certainly adds latency. More hops more time. In some instances where the original server was closer than CF’s edge, I measured increased time even for cached content, effectively making CF slower for every request by that specific user.

If the site is both static and busy enough, then the majority of users never need to do a roundtrip to the original server.

If the site isn’t busy enough… well, I think more CDNs ought to support pre-caching. Supposedly Vercel does?

Re: We Need To Talk About Vercel

#55

Post by theobr »

llambda wrote: post #10
leerob wrote: post #3

[Lee from Vercel] Max reached out to me today (Sunday) after this experience, and I worked with him this evening get to a resolution for his site on the Vercel free tier. I'm really sorry we weren't able to get to a resolution faster. I've concluded it's not an issue with the Vercel Edge Network based on the reproduction he provided and pushed documentation and example updates (see below). I know Max spent a lot of t…

Actually I reached out to you asking for a comment which I could add to the article, not for your technical support. I was surprised and I have to admit a bit dismayed to watch you throw yourself into the fray on a Sunday. The technical issues, which in fact persist, are at this point an aside to the way Vercel has handled this issue.

It’s pretty clear these issues were beyond what traditional support was capable of. If you had reached out to someone like Lee earlier it’s likely your experience would have been much better

Vercel’s definitely in a weird place, trying to be the home for innovation while also offering more traditional support. While the support experience you had was less than ideal, you’re also failing to recognize that you are bleeding edge a bit here.

Your reply here makes it really hard to take any of what you’ve done in good faith. Lee has been incredible to work with and I commend his efforts here

Re: We Need To Talk About Vercel

#56

Post by no_wizard »

preommr wrote: post #14

Vercel scares the hell out of me - their previous handling of that runaway bill of 6k was atrociuos. They basically blamed the user and only handled it after it gained traction on social media. Beyond that, they do a lot of things with web, while having very little moat as a company. By that I mean they're involved in a lot of front-end libraries, articles, projects, etc. a lot of which they incorporate into their pl…

Their moat may be from a technical perspective thin, however with that said, if you do deploy Next.js on Vercel with all the nice things that comes with out of the box, it’s hard to beat. And GCP, AWS nor Azure make it as out of the box seamless and keeps it that way as things scale.

The big cloud providers “solutions” around this all fall short introducing mindless complexity to upsell you more services often with half baked integration

Re: We Need To Talk About Vercel

#57

Post by oefrha »

comex wrote: post #49
oefrha wrote: post #13

Slightly related: Netlify has/had an even bigger problem around caching, and not just caching. I set `cache-control: public,max-age=2592000,immutable` on my SPAs' assets as they're hashed and should be immutable. But Netlify somehow doesn't atomically swap in a new version: say my index.html referenced /assets/index.12345678.js before and is updated to reference /assets/index.87654321.js instead, there's a split seco…

Is the JS file somehow being embedded into index.html on the server side? If not, how do you expect this to be atomic when the user’s browser is making two separate requests (with an arbitrary delay between them)?

The atomicity is for the site update.

If I'm deploying to my server, the structure would look like:

  /srv/example.com/prod -> /srv/example.com/versions/1
  /srv/example.com/versions/1/index.html
  /srv/example.com/versions/1/assets/index.12345678.js
  /srv/example.com/versions/2/index.html
  /srv/example.com/versions/2/assets/index.87654321.js
A new version is atomically swapped in by changing the prod link from versions/1 to versions/2. If you request index.html and get the updated version, there's no scenario where assets/index.87654321.js could 404. Serving an updated index.html but 404 for a later request for assets/index.87654321.js is not reasonable. Of course distributed systems are harder but it's their problem to solve.

Note that with a naive web server and the layout above, one could get an old index.html but no assets/index.12345678.js by the time the .js file is requested, but that's less problematic and could be covered by some lingering cache. Or I could simply include the last build's assets as there's no conflict potential.

Re: We Need To Talk About Vercel

#58

Post by lolinder »

stevebmark wrote: post #48
Kevcmk wrote: post #38

Vercel is deceitful. The Image/img fiasco really pulled the covers off for vercel for me. I have migrated all my work off of the platform. NextJS’ lint strategically dissuades you from using the img tag in favor of the NextJS Image component. If you make the mistake of heeding this advice and migrating to it, you can’t use static site generation—which means you are stuck using their hosting. Here’s one of the most PR…

[flagged]

I think you must have missed that the first post is a replacement of the actual feature request that someone submitted. I have no dog in this fight, but it's pretty slimy to respond to someone's request by overwriting it with your explanation. They effectively hijacked the requester's name, profile picture, and who knows how many upvotes to push their own message instead of letting them have their say and, you know, replying.

Re: We Need To Talk About Vercel

#59

Post by swyx »

preommr wrote: post #14

Vercel scares the hell out of me - their previous handling of that runaway bill of 6k was atrociuos. They basically blamed the user and only handled it after it gained traction on social media. Beyond that, they do a lot of things with web, while having very little moat as a company. By that I mean they're involved in a lot of front-end libraries, articles, projects, etc. a lot of which they incorporate into their pl…

> while having very little moat as a company

they have effectively acquihired React (Zuck's mistake). no moat?

(not to mention some genuinely great cloud DX and other platform features eg with their Edge Streaming)

Re: We Need To Talk About Vercel

#60

Post by Kevcmk »

stevebmark wrote: post #48
Kevcmk wrote: post #38

Vercel is deceitful. The Image/img fiasco really pulled the covers off for vercel for me. I have migrated all my work off of the platform. NextJS’ lint strategically dissuades you from using the img tag in favor of the NextJS Image component. If you make the mistake of heeding this advice and migrating to it, you can’t use static site generation—which means you are stuck using their hosting. Here’s one of the most PR…

[flagged]

Which one, the go ahead and "define your own custom loader"? You mean re-implement the image export that is sitting right there in their express server... from scratch? Hah.

NextJS won't let you export their optimized images in a static site export because they want _everything_ running through their Express server.

Why's that great for them? Because they get to charge you for image bandwidth and image optimization. This is called vendor lock in.

Sources:

In vivo (v13.3.0):

  > npx next export
  
  error - Image Optimization using the default loader is not compatible with export.
    Possible solutions:
      - Use `next start` to run a server, which includes the Image Optimization API.
      - Configure `images.unoptimized = true` in `next.config.js` to disable the Image Optimization API.
    Read more: https://nextjs.org/docs/messages/export-image-api
and https://vercel.com/changelog/changes-to-vercel-image-optimiz...
Post reply on HN