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

151–160 of 161 posts

Re: We Need To Talk About Vercel

#151

Post by re-thc »

andrewingram wrote: post #86
re-thc wrote: post #79

Earlier quoted context omitted.

There is some merit to it. Maybe not that comment but on Vercel React in general. Even React new docs are promoting NextJs vs something neutral.

The vast majority of React’s core team still works for Meta, and I think the sentiment that a small handful of “famous” hires amounts to acqui-hiring the team is frankly a little insulting to the rest of them.

That's not the sentiment. At least not for me. As I mentioned it's not really where the employees are but the direction and perspective we as "outsiders" get from the team.

E.g. - React Server Components currently only available in NextJs. - The official docs recommend NextJs and Remix. - Create React App is deprecated. Vite is not promoted.

It's already not vendor neutral nor Meta focused. More people ask about NextJs than React nowadays. Perhaps these "famous" hires you mention do more promoting and it's about the perception (that works both ways). Perhaps there's the aspect of choosing the frameworks was the best technical solution but what perception did this bring to the community? People ask if you can use React with NextJs :(

Re: We Need To Talk About Vercel

#153

Post by gitgud »

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…

Yeah the "next/image" has always bothered me, I suspect it's a huge revenue stream for them

My advice is to just turn off the linting errors by adding this rule to ".eslintrc.json", like this:

    {
      "rules": {
        // Other rules
        "@next/next/no-img-element": "off"
      }
    }

Re: We Need To Talk About Vercel

#154

Post by danjac »

pauliescanlon wrote: post #121

Feel like this Tweet could use some social support too. https://twitter.com/ms_nieder/status/1626995266619420675?s=4...

This right here is why I never, ever use cloud services for my side projects, and only use them on the client's or employer's dime. I always use Digital Ocean, Hetzner, or some other provider where I pay a fixed amount per month.

Which is a shame as it makes it harder to learn things like AWS and Google Cloud (or for that matter, Vercel) in my spare time, and perhaps they might even work out cheaper for low-traffic hobby projects, but ultimately the risk is too great.

Re: We Need To Talk About Vercel

#155

Post by re-thc »

adoxyz wrote: post #6

Personally, I love how approachable Vercel is and for most small things I've used Vercel for, it has been an absolute delight. My issue with using Vercel for "real workloads" is the pricing though. 100GB of Bandwidth for $40 is a blocker. I love how easy the experience is to throw up an app and test it in the real world, the dashboard is great, build times are excellent, but I can't see myself paying that high of a p…

Also $20 per user. A lot of teams don't use a lot of bandwidth but have a lot of developers.

Re: We Need To Talk About Vercel

#156

Post by incrudible »

adrr wrote: post #116
incrudible wrote: post #106

Earlier quoted context omitted.

Why would it?

Speed? Primary reason for CDNs.

I don't buy that, at least not in the general case. A CDN adds an additional indirection between the site you serve and the content that you reference on the CDN.

Re: We Need To Talk About Vercel

#157

Post by locustous »

ranguna wrote: post #152
robjan wrote: post #109

Earlier quoted context omitted.

They don't

Ah so the OP lied, great.

I'm only describing egress pricing for serving content, not CDN.

If you're in the same region, another DNS lookup is going to be more costly than a CDN will be worth in proximity.

Re: We Need To Talk About Vercel

#158

Post by kevincox »

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…

This is a fundamental flaw with the whole "atomic deploy" model. The web is a distributed system and you can't just pretend that it isn't.

https://kevincox.ca/2021/08/24/atomic-deploys/

In this case it is possible that Netlify could have avoided the issue where the new HTML loads the old asset but this will just make the problem where the old HTML gets a 404 because the new asset has been swapped worse.

At the end of the day hashed assets is a great idea but you need to keep multiple versions around.

Re: We Need To Talk About Vercel

#159

Post by re-thc »

locustous wrote: post #157
ranguna wrote: post #152

Earlier quoted context omitted.

Ah so the OP lied, great.

I'm only describing egress pricing for serving content, not CDN. If you're in the same region, another DNS lookup is going to be more costly than a CDN will be worth in proximity.

Depends. Some CDN are more than worth it. Hetzner has weak DDoS protection for example. Some CDN have caches inside the ISP network. It doesn't even get out. There are also cases where the local ISP may not peer with you even if you are in the same region. OVH was famous for this in Asia. It's not enough to be in the same region.

Re: We Need To Talk About Vercel

#160

Post by eric-burel »

brillout wrote: post #92

Open alternative to Next.js: https://vite-plugin-ssr.com/ (I'm its author). Open: - Choose any UI framework you want (React/Vue/Solid/...) - A lot more flexible than Next.js (e.g. i18n and base assets configuration are fundamentally more flexible) - Keep architectural control (vite-plugin-ssr is more like a library and doesn't put itself in the middle of your stack) - Use your favorite tools. And manually integrate t…

Next.js pseudo-alternatives are usually subpar, because they misunderstand Next.js approach and implement a very simplified vision of it (eg they can't even tell the difference between client-side rendered SPA and HTML export). This one doesn't seem to fall in this trap, from the documentation it seems a very well thought library. Great work!
Post reply on HN