Ask HN: Why use Vercel?
I've seen a lot of articles lately referencing Vercel, what is your experience like? What are the advantages to using it?
12 comments
100% use it if it's not your money on the line - solid DX across the board but the pricing is oriented at overfunded startups not the True IDE-wielding Glaswegian
> not the True IDE-wielding Glaswegian
Could you explain this reference? I googled Glaswegian and it appears that it refers to someone from Glasgow, but I'm not sure how that's relevant in the context you just used it.
Could you explain this reference? I googled Glaswegian and it appears that it refers to someone from Glasgow, but I'm not sure how that's relevant in the context you just used it.
No true dev sullies their Code Temple with the false comforts offered by SaaS no matter how vogue
It costs me $20/month for me. Seems reasonable.
It takes about 20s wire up your git repo and have your site running.
Preview builds on push to any branch with a status update in the Github PR and prod deployment on push to main. Easy to roll back to an older version too.
It does other things too, like act as a remote cache for Turborepo, handles env files, and can do more and more analytics. But it’s the seamless preview and deployment integration that does it for me.
Pricy though.
Preview builds on push to any branch with a status update in the Github PR and prod deployment on push to main. Easy to roll back to an older version too.
It does other things too, like act as a remote cache for Turborepo, handles env files, and can do more and more analytics. But it’s the seamless preview and deployment integration that does it for me.
Pricy though.
Good DX, make your life easier.
It can be replaced with netlify, deno deploy, Cloudflare, aws or azure.
But these alternative platforms might need extra human effort to sort out the whole workflow.
It can be replaced with netlify, deno deploy, Cloudflare, aws or azure.
But these alternative platforms might need extra human effort to sort out the whole workflow.
Because some CMS products like Sitecore push it as their main headless FE infrastructure, otherwise I wouldn't care it exists.
The free tier is pretty great for getting out landing pages or static sites. It makes deployment as easy as possible, you just need to push your main branch. If you want a bit more like a database, things get a bit more involved but not any more complicated than setting up your own infra. Overall, happy with using it for the cases it handles really well.
I’ve tried several options for (typescript) monorepo maintenance, and in terms of feature coverage, I think Vercel’s “Turbo” system takes the cake compared to the alternatives. Monorepo manager tools I’ve tried in the past: Raw workspaces (pnpm, yarn), lerna, rush, nx.
Features I was looking for (you’d be surprised how hard it is to get all of them)
1. pnpm support out of the box. WHY: pnpm just seems to be faster/smaller footprint than yarn, definitely npm.
2. Support for intramonorepo dependencies. WHY: our services can auto generate service-clients. It’s extremely helpful to be able to hack a couple of changes on one service and instantly see how your new API breaks other systems. No pushing packages to a private npm registry, waiting for devs to approve your request.
3. Global build system. Why: we have a bunch of micro services that are all frameworked out pretty much the same way, so for the sake of productivity it’s useful that we should be able to reuse the same Dockerfile to produce each, that way we can minify the container pretty efficiently.
4. topologically ordered build jobs. WHY: like I said, we have libraries & autogen service-clients in our monorepo. Building low level components first is a must.
5. Ability to add new projects at minimal overhead cost. WHY: it’s surprising how verbose most monorepo managers expect you to be just to add a new face to the group.
Turbo knocks it out of the park on almost all of these, a feat no other manager is capable of IME. It’s a little shaky on its pnpm support, and I wish that they’d expedite it, but we were able to separate build and development to use yarn & pnpm respectively (turbo has a Docker mode which is why this is relevant), so we can work around it.
Turbo then also brings its own “I didn’t know I wanted that” features to the table. Turbo’s caching functionality is crazy. You can configure it to be smart enough to detect when each of your libs/apps actually changes, otherwise the cached version of the build is bubbled up the chain.
If you want to monorepo in typescript, I’d recommend Turbo.
Features I was looking for (you’d be surprised how hard it is to get all of them)
1. pnpm support out of the box. WHY: pnpm just seems to be faster/smaller footprint than yarn, definitely npm.
2. Support for intramonorepo dependencies. WHY: our services can auto generate service-clients. It’s extremely helpful to be able to hack a couple of changes on one service and instantly see how your new API breaks other systems. No pushing packages to a private npm registry, waiting for devs to approve your request.
3. Global build system. Why: we have a bunch of micro services that are all frameworked out pretty much the same way, so for the sake of productivity it’s useful that we should be able to reuse the same Dockerfile to produce each, that way we can minify the container pretty efficiently.
4. topologically ordered build jobs. WHY: like I said, we have libraries & autogen service-clients in our monorepo. Building low level components first is a must.
5. Ability to add new projects at minimal overhead cost. WHY: it’s surprising how verbose most monorepo managers expect you to be just to add a new face to the group.
Turbo knocks it out of the park on almost all of these, a feat no other manager is capable of IME. It’s a little shaky on its pnpm support, and I wish that they’d expedite it, but we were able to separate build and development to use yarn & pnpm respectively (turbo has a Docker mode which is why this is relevant), so we can work around it.
Turbo then also brings its own “I didn’t know I wanted that” features to the table. Turbo’s caching functionality is crazy. You can configure it to be smart enough to detect when each of your libs/apps actually changes, otherwise the cached version of the build is bubbled up the chain.
If you want to monorepo in typescript, I’d recommend Turbo.
i got massive distaste for it back then due to its internals being a bunch of spaghetti code, but it's kinda tolerable for some static site use cases.
Any advantages over Netlify for static content?
Awhile ago (year+) I was trying to set up a project for free that hand a frontend/backend and database. I landed on Vercel with NextJS and MongoDB’s Atlas, for no other reason than I am familiar with Next and like writing typescript/react, and wanted to not spend any money. It’s been easy to push to master and deploy, and never seems to have any issues. All in all I can see Vercel being great for small/one person teams. Id definitely pay the $12 to not do any dev ops if I was running a business on it.