5 ms·

Why People Aren't Deploying to Vercel Anymore

24 points by creativedg 3y ago

mg 3y ago
I never understood the appeal of a hoster "supporting" frameworks. How is it better than using any standard VM for $5/month and running a script like this ... https://www.gibney.org/web_app_from_scratch https://www.gibney.org/web_app_from_scratch ... and then you have a running web app?
- robertlagrant 3y ago
  For me, the main things are: - Vercel will do some decent scaling - Vercel will do feature branch environments, so users can preview how the software will look before merging code into master/main - Vercel maintain NextJS, which is a good thing if you use it
  - mg 3y ago
    When you look back on the history of what you hosted, was the overall price you paid for automatic scaling worth it? In my experience, running a web application on a VM which can handle 10x the normal load is pretty cheap. And occurences where a traffic spike is more than 10x the normal load are so rare (once every couple of years) that I can deal with it manually.
    - locustous 3y ago
      Everyone fancies their success, which means more visitors. They want to be able to handle the odd traffic surge. Understandable desires. But understanding of scaling seems stuck in 2012 when these systems were required for even moderate sites, particularly if slow frameworks are being used. The rise of cloud use is definitely part of this mentality. An ingrained believe that horizontal scaling via vendor is the only way. But meanwhile, in 2023 where we've seen a 500x bump in what servers are capable of and vertical scaling and it's simplicity can just "get you there" for 99% of sites.
      - robertlagrant 3y ago
        For me it's more that hopefully I don't need to worry about being hugged or randomly hit by a driveby DDOS. If my service were popular to have a high sustained load, that would be great, but it's more just having some decent capacity to avoid spikes that $20/mo/team member just seems like a decent deal. The bigger plus is the temp environments, that free up a lot of developer time in my experience; they solve a lot of boring, time-heavy communication problems. A pull request can just spin up a temp environment which a designer can eyeball at the same time as the code is being reviewed. Means less rework.
nfRfqX5n 3y ago
server rendering is cool until you have to pay the bill. this is why I am a bit skeptical of the react server components push.
- hermanradtke 3y ago
  Especially since server side rendering react is a lot more expensive than server side rendering something like a mustache template.
  - zelphirkalt 3y ago
    Why are they not using caching? Does a component have to be rendered differently for each and every visitor? Is there anything that makes caching impossible? In the end it is just a bunch of HTML, CSS and JS being delivered to a browser somewhere. Why is it hard to cache properly?
    - DanielHB 3y ago
      client-rendered SPAs can cache the delivery of JS/HTML/CSS and have only raw data requests be optionally-cacheable server-rendered SPAs mix JS/HTML/CSS with data meaning that if the data served by a request is not cacheable, nothing is when a page has data that is tied to a specific user it becomes very hard to have cache-hits, at least of the dirty-cheap CDN kind of caching type
    - nfRfqX5n 3y ago
      caching costs money too though
- DanielHB 3y ago
  I am skeptical because most applications don't really benefit from being server rendered. Say what you will about performance but if you keep your bundle sizes within reason and apply a small dose of lazy-loading for big dependencies web apps are just fast enough for the majority of the code being written today. And unlike client-rendered SPAs, server-rendered don't fundamentally change how you write your code. Going from template-engine + form-redirects for mutations to an SPA is like unlocking super-powers in the user flows possible and developer capabilities. Going from SPA to server-rendered SPA brings very little new user-flow capabilities or developer-experience benefits, while bringing many downsides. Crazy good performance and SEO is only required for websites that need to grab attention within 200ms before the user closes it down. The fact is, most code being written today is not for this kind of application and smartphones got massively better as well. This is eerie similar to the old days of unix shared-terminals (one mainframe serving a lot of independent terminals) vs micro-computers
zelphirkalt 3y ago
Deploying NextJS stuff on Vercel, while maybe dev experience friendly, is not a visitor friendly thing to do. The amount of websites, that merely show a white screen, when you don't allow arbitrary JS to run ... And of course with allowing tons of JS comes tons of tracking. Of course one can be selective in what one allows, but what happens with the main required scripts is still unclear and it requires one to be knowledgeable and aware about these things. The usual visitor is not. Lets say they were recommended a privacy protecting extension like NoScript or uMatrix or uBlock Origin or ... by a friend. They will notice: "Oh the website is not working now! Guess I have to turn the extension off/have to whitelist the website." All because some wanna go easy web dev does not care and puts simple text content behind JS rendering bloat. Of course you can use server side rendering. but somehow many people don't and all goes to shit. Next one finds oneself rebuilding things, that a normal web browser has had at the ready for decades, only because the whole website was forced into a web app approach and there is a separate router and all that stuff. At that point using a traditional web framework that simply renders HTML on the server would have been a better choice, but of course it is not hyped like NextJS is. It is not fashionable! Usually those websites merely have some text or picture content and the visitor never needed any dynamic features. They merely want to see content, that could be immediately delivered, instead of being hidden behind a white screen and lots of unnecessary JS bloat. Think about how many websites you visit a day truly need dynamic features for the purpose you visit them for. Then think about how many of those are implemented in this style nevertheless. Great that devs are having some great experience on Vercel. That does not make it good websites or visitor friendly. Maybe we can get back to not so selfish development practices some day? I also don't see NextJS as some kind of big improvement over the status quo. I have used it a little, but could not name a single feature it has, that is somehow better than what we had already. If anything, it further entrenches and encourages the "everything as a web app" and "everything using JS" mind set, which I consider to be quite harmful. So I don't think Vercel deserves "to be paid well" for making it.
- DanielHB 3y ago
  > Next one finds oneself rebuilding things, that a normal web browser has had at the ready for decades, only because the whole website was forced into a web app approach and there is a separate router and all that stuff. At that point using a traditional web framework that simply renders HTML on the server would have been a better choice, but of course it is not hyped like NextJS is. It is not fashionable! Your arguments are not related to Next or server-side-rendering frameworks at all, you arguments are related to static websites vs SPAs (client or server rendered). Although you have some valid points it has been proven that devs rather just use the more powerful approach even if they don't need to. The two ways of building apps (static vs SPA) are just too different and there is more job market for SPAs so even things that don't need to be SPAs end up as SPAs. On top of the FOMO of maybe you might need some dynamism in your pages in the future, it just makes sense to go as SPA from the start.
riogordo2go 3y ago
Maybe the new generation of developers are afraid of light Sysadmin tasks like setting up nginx, PostgreSQL, Redis, iptables. And Vercel welcomes them with open arms with the promise of easy deployments and infinite scalability. In reality you probably don't need fancy edge functions and deploying isn't that hard with today's tooling.
- sph 3y ago
  The previous generation deployed their simple Django and Rails apps onto overpriced Heroku. Systems administration has died when it started being called DevOps and got enormously overengineered to the point the golden handcuffs are the only option for pure or beginner developers. When the pathologically lazy sysadmin in a black tshirt got replaced by the ever busy and corporate friendly DevOps types going to fancy conferences. As someone that started as a Linux/UNIX sysadmin and is having an interview for a DevOps position in an hour, I wonder when and why did this shift appear? When did sysadmins find a new job title on their door? Must've been around 2012 or so.
  - riogordo2go 3y ago
    Good luck with the interview!
- DanielHB 3y ago
  > deploying isn't that hard with today's tooling I would argue that deploying today is much harder in comparison to how hard it is to build software in the first place. Building a profitable MVP product is much easier than rolling out your own infra for said product Yes deployment got a lot easier, but product development got much easier in comparison (at least until you run into scalability issues)
- apocalyptic0n3 3y ago
  In a lot of cases, it's less that developers are afraid of light sysadmin tasks and more that companies don't employ anyone capable of development, outsource it to agencies, and then end the relationship once the project is complete. If the devs deploy it to Vercel or Netlify or similar, they can be reasonably certain it will run as-is for months and probably years with no intervention because they client won't be willing to spend money on maintenance. That makes their client happy and leads to repeat business later down the line when budgets allow. Tech debt and lack of proper maintenance is a significant concern with agency projects and is why companies like Vercel and Wordpress hosts like WP Engine are able to spin up and grow so quickly.
tmikaeld 3y ago
Seems like a clickbait article to draw views, someone complaining when they use functions in a wasteful way, isn't "people are abandoning Vercel!!". What kind of function workloads would trigger TBs of data transfers? Images? Video? Why would you push that through a function when you can put a domain on S3 directly.
- ibejoeb 3y ago
  I don't think it has anything to do with function workloads specifically. Vercel prices total bandwidth at $40/100GB over 1TB.
  - rswerve 3y ago
    per 100 GB
    - ibejoeb 3y ago
      Oh jeez yeah, terrible typo. Fixed, thanks.
slimebot80 3y ago
Vercel is an excellent solution. If you ever need to scale beyond it, you're one of the lucky ones ;) But until then, enjoy everything it has to offer, knowing it has good fundamentals.
- slimebot80 3y ago
  lol at this getting downvoted, the bros don't like anything less than rolling their own on Bezo$ infra
curiousbean 3y ago
I don't know how someone uses 1TB of bandwidth so easily. My service is somewhat popular and I see ~200k requests per-day at least and I hardly hit 50GB/month? I am on Linode and serve assets/html/css/js and api responses with zero caching. Perhaps Vercel is doing some creative accounting of bandwidth?

24 points by creativedg 3y ago

mg 3y ago

I never understood the appeal of a hoster "supporting" frameworks. How is it better than using any standard VM for $5/month and running a script like this ... https://www.gibney.org/web_app_from_scratch https://www.gibney.org/web_app_from_scratch ... and then you have a running web app?

robertlagrant 3y ago
For me, the main things are: - Vercel will do some decent scaling - Vercel will do feature branch environments, so users can preview how the software will look before merging code into master/main - Vercel maintain NextJS, which is a good thing if you use it
- mg 3y ago
  When you look back on the history of what you hosted, was the overall price you paid for automatic scaling worth it? In my experience, running a web application on a VM which can handle 10x the normal load is pretty cheap. And occurences where a traffic spike is more than 10x the normal load are so rare (once every couple of years) that I can deal with it manually.
  - locustous 3y ago
    Everyone fancies their success, which means more visitors. They want to be able to handle the odd traffic surge. Understandable desires. But understanding of scaling seems stuck in 2012 when these systems were required for even moderate sites, particularly if slow frameworks are being used. The rise of cloud use is definitely part of this mentality. An ingrained believe that horizontal scaling via vendor is the only way. But meanwhile, in 2023 where we've seen a 500x bump in what servers are capable of and vertical scaling and it's simplicity can just "get you there" for 99% of sites.
    - robertlagrant 3y ago
      For me it's more that hopefully I don't need to worry about being hugged or randomly hit by a driveby DDOS. If my service were popular to have a high sustained load, that would be great, but it's more just having some decent capacity to avoid spikes that $20/mo/team member just seems like a decent deal. The bigger plus is the temp environments, that free up a lot of developer time in my experience; they solve a lot of boring, time-heavy communication problems. A pull request can just spin up a temp environment which a designer can eyeball at the same time as the code is being reviewed. Means less rework.

nfRfqX5n 3y ago

server rendering is cool until you have to pay the bill. this is why I am a bit skeptical of the react server components push.

hermanradtke 3y ago
Especially since server side rendering react is a lot more expensive than server side rendering something like a mustache template.
- zelphirkalt 3y ago
  Why are they not using caching? Does a component have to be rendered differently for each and every visitor? Is there anything that makes caching impossible? In the end it is just a bunch of HTML, CSS and JS being delivered to a browser somewhere. Why is it hard to cache properly?
  - DanielHB 3y ago
    client-rendered SPAs can cache the delivery of JS/HTML/CSS and have only raw data requests be optionally-cacheable server-rendered SPAs mix JS/HTML/CSS with data meaning that if the data served by a request is not cacheable, nothing is when a page has data that is tied to a specific user it becomes very hard to have cache-hits, at least of the dirty-cheap CDN kind of caching type
  - nfRfqX5n 3y ago
    caching costs money too though
DanielHB 3y ago
I am skeptical because most applications don't really benefit from being server rendered. Say what you will about performance but if you keep your bundle sizes within reason and apply a small dose of lazy-loading for big dependencies web apps are just fast enough for the majority of the code being written today. And unlike client-rendered SPAs, server-rendered don't fundamentally change how you write your code. Going from template-engine + form-redirects for mutations to an SPA is like unlocking super-powers in the user flows possible and developer capabilities. Going from SPA to server-rendered SPA brings very little new user-flow capabilities or developer-experience benefits, while bringing many downsides. Crazy good performance and SEO is only required for websites that need to grab attention within 200ms before the user closes it down. The fact is, most code being written today is not for this kind of application and smartphones got massively better as well. This is eerie similar to the old days of unix shared-terminals (one mainframe serving a lot of independent terminals) vs micro-computers

zelphirkalt 3y ago

Deploying NextJS stuff on Vercel, while maybe dev experience friendly, is not a visitor friendly thing to do. The amount of websites, that merely show a white screen, when you don't allow arbitrary JS to run ... And of course with allowing tons of JS comes tons of tracking. Of course one can be selective in what one allows, but what happens with the main required scripts is still unclear and it requires one to be knowledgeable and aware about these things. The usual visitor is not. Lets say they were recommended a privacy protecting extension like NoScript or uMatrix or uBlock Origin or ... by a friend. They will notice: "Oh the website is not working now! Guess I have to turn the extension off/have to whitelist the website." All because some wanna go easy web dev does not care and puts simple text content behind JS rendering bloat. Of course you can use server side rendering. but somehow many people don't and all goes to shit. Next one finds oneself rebuilding things, that a normal web browser has had at the ready for decades, only because the whole website was forced into a web app approach and there is a separate router and all that stuff. At that point using a traditional web framework that simply renders HTML on the server would have been a better choice, but of course it is not hyped like NextJS is. It is not fashionable! Usually those websites merely have some text or picture content and the visitor never needed any dynamic features. They merely want to see content, that could be immediately delivered, instead of being hidden behind a white screen and lots of unnecessary JS bloat. Think about how many websites you visit a day truly need dynamic features for the purpose you visit them for. Then think about how many of those are implemented in this style nevertheless. Great that devs are having some great experience on Vercel. That does not make it good websites or visitor friendly. Maybe we can get back to not so selfish development practices some day? I also don't see NextJS as some kind of big improvement over the status quo. I have used it a little, but could not name a single feature it has, that is somehow better than what we had already. If anything, it further entrenches and encourages the "everything as a web app" and "everything using JS" mind set, which I consider to be quite harmful. So I don't think Vercel deserves "to be paid well" for making it.

DanielHB 3y ago
> Next one finds oneself rebuilding things, that a normal web browser has had at the ready for decades, only because the whole website was forced into a web app approach and there is a separate router and all that stuff. At that point using a traditional web framework that simply renders HTML on the server would have been a better choice, but of course it is not hyped like NextJS is. It is not fashionable! Your arguments are not related to Next or server-side-rendering frameworks at all, you arguments are related to static websites vs SPAs (client or server rendered). Although you have some valid points it has been proven that devs rather just use the more powerful approach even if they don't need to. The two ways of building apps (static vs SPA) are just too different and there is more job market for SPAs so even things that don't need to be SPAs end up as SPAs. On top of the FOMO of maybe you might need some dynamism in your pages in the future, it just makes sense to go as SPA from the start.

riogordo2go 3y ago

Maybe the new generation of developers are afraid of light Sysadmin tasks like setting up nginx, PostgreSQL, Redis, iptables. And Vercel welcomes them with open arms with the promise of easy deployments and infinite scalability. In reality you probably don't need fancy edge functions and deploying isn't that hard with today's tooling.

sph 3y ago
The previous generation deployed their simple Django and Rails apps onto overpriced Heroku. Systems administration has died when it started being called DevOps and got enormously overengineered to the point the golden handcuffs are the only option for pure or beginner developers. When the pathologically lazy sysadmin in a black tshirt got replaced by the ever busy and corporate friendly DevOps types going to fancy conferences. As someone that started as a Linux/UNIX sysadmin and is having an interview for a DevOps position in an hour, I wonder when and why did this shift appear? When did sysadmins find a new job title on their door? Must've been around 2012 or so.
- riogordo2go 3y ago
  Good luck with the interview!
DanielHB 3y ago
> deploying isn't that hard with today's tooling I would argue that deploying today is much harder in comparison to how hard it is to build software in the first place. Building a profitable MVP product is much easier than rolling out your own infra for said product Yes deployment got a lot easier, but product development got much easier in comparison (at least until you run into scalability issues)
apocalyptic0n3 3y ago
In a lot of cases, it's less that developers are afraid of light sysadmin tasks and more that companies don't employ anyone capable of development, outsource it to agencies, and then end the relationship once the project is complete. If the devs deploy it to Vercel or Netlify or similar, they can be reasonably certain it will run as-is for months and probably years with no intervention because they client won't be willing to spend money on maintenance. That makes their client happy and leads to repeat business later down the line when budgets allow. Tech debt and lack of proper maintenance is a significant concern with agency projects and is why companies like Vercel and Wordpress hosts like WP Engine are able to spin up and grow so quickly.

tmikaeld 3y ago

Seems like a clickbait article to draw views, someone complaining when they use functions in a wasteful way, isn't "people are abandoning Vercel!!". What kind of function workloads would trigger TBs of data transfers? Images? Video? Why would you push that through a function when you can put a domain on S3 directly.

ibejoeb 3y ago
I don't think it has anything to do with function workloads specifically. Vercel prices total bandwidth at $40/100GB over 1TB.
- rswerve 3y ago
  per 100 GB
  - ibejoeb 3y ago
    Oh jeez yeah, terrible typo. Fixed, thanks.

slimebot80 3y ago

Vercel is an excellent solution. If you ever need to scale beyond it, you're one of the lucky ones ;) But until then, enjoy everything it has to offer, knowing it has good fundamentals.

slimebot80 3y ago
lol at this getting downvoted, the bros don't like anything less than rolling their own on Bezo$ infra

curiousbean 3y ago

I don't know how someone uses 1TB of bandwidth so easily. My service is somewhat popular and I see ~200k requests per-day at least and I hardly hit 50GB/month? I am on Linode and serve assets/html/css/js and api responses with zero caching. Perhaps Vercel is doing some creative accounting of bandwidth?