- 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
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.
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.
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.
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?
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
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.
> 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.
> 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.
That has nothing to do with deploying on Vercel. In fact, deploying on Vercel and using NextJS _should_ allow developers to do exactly the opposite: provide javascript-enhanced [0] websites instead of javascript-only, with server-side rendering with low latency since the servers are right next to the user. It's just most developers are lazy, and for some reason the recommend practice is to do data fetching on the client, even though data fetching on the server is extremely trivial in NextJS [1][2].
Also, Vercel doesn't force you to use NextJS, in fact they hired Rich Harris which is the genius behind Rollup and Svelte. SvelteKit also allow for a hybrid javascript-enhanced approach with remix-inspired form actions [3] and hybrid data loading [4].
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.
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.
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)
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.
I can do all of those sysadmin tasks (learned FreeDBD sysadmin at UC Berkeley’s student ISP) but the experience offered by Vercel (free for hobby user!) is so much better than managing my own VPS, why would I consider it? Even for a team of 10 @ $20/mo, Vercel seems so worth it for preview deploys per branch, production environment management, CDN, etc. “light system management” doesn’t cover any of those tasks, and the whole team is gonna move waaay faster compared to fiddling with VPS provisioning.
> Postgres, Redis
Vercel doesn’t do either of these, but you can pick Postgres up from Superbase (for free) in a few clicks. But I might consider Planetscale for the production DB fork & schema management stuff even though it’s MySQL instead of Postgres.
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?
27 comments
[ 3.0 ms ] story [ 72.6 ms ] threadHow 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
... and then you have a running web app?
- 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
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.
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.
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.
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
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
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.
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.
Also, Vercel doesn't force you to use NextJS, in fact they hired Rich Harris which is the genius behind Rollup and Svelte. SvelteKit also allow for a hybrid javascript-enhanced approach with remix-inspired form actions [3] and hybrid data loading [4].
[0]: https://react.dev/reference/react-dom/hydrate
[1]: https://nextjs.org/docs/basic-features/data-fetching/get-ser...
[2]: https://nextjs.org/docs/basic-features/data-fetching/get-sta...
[3]: https://kit.svelte.dev/docs/form-actions
[4]: https://kit.svelte.dev/docs/load#universal-vs-server
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.
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)
> Postgres, Redis
Vercel doesn’t do either of these, but you can pick Postgres up from Superbase (for free) in a few clicks. But I might consider Planetscale for the production DB fork & schema management stuff even though it’s MySQL instead of Postgres.
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.
But until then, enjoy everything it has to offer, knowing it has good fundamentals.
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?