I mean, Vercel has its usefulness, it’s so well integrated with the NextJS stack, it totally makes sense for small amateurish projects since it saves you time and money… but once you want to push to production, have real customers and satisfy them reliably, these platforms can’t compete with the big ones.
However, I suppose it’s good for content marketing. You’re not going to make front page by choosing boring old technology (unless you’re migrating back to boring old technology after failed HN-frontpage-driven development).
Next.js, TailwindCSS, shadcn/ui, tinybird, turso, drizzle, clerk, Resend
That’s for an app which sends a ping to a URL every x minutes…
My bigger question is: How the fuck do these companies keep getting created? There's gotta be more uptime-monitor SaaS companies than todo MVC demos in existence.
Conclusion: promising builders being bad at startups
Betterstack did this very well.
Until yet another free competitor comes along. Then you're out of business
It's not an apples to apples choice. The people who use Vercel don't know anything about how to deploy on AWS. That's the whole point of Vercel. Whether or not they can be trusted is really orthogonal to the reason they were selected as a provider. But that said, they're just a layer over AWS so why should they be significantly less trustworthy? I haven't used Vercel in production, but I have used a similar "layer over AWS" service (Aptible). The problem where wasn't to do with QoS or support, but rather that the narrowing of the functionality of the "interface" (which is pretty much the point) ends up causing frustration when you want to integrate with other stuff you're doing in AWS.
Ehhhh. I’ve been deploying to AWS professionally for years and I’d choose Vercel for a personal project any day of the week.
Life’s too short to play devops/sysadmin/sre without someone paying you the big bucks.
This is great for personal projects. This is great for budding projects in a professional setup as well.
You could also have said 'ever' instead of 'never', that would be a simpler and better fix on re-reading.
But to the main point: using an extra layer which is on the top of said large provider, like here Vercel over AWS, is not a solution, as this middle man also can be marginalized by the big bully at some moment.
This is why I prefer small providers, like Vultr. (Not affiliated with them in any way; just a happy customer).
Most big providers end up being cheaper for you as well. Vercel is insanely expensive.
Both large and small providers could make the ground from under your feet disappear, in different ways. But only the small provider has a real incentive to actually keep you, as just one customer. It’s only when a small provider goes out of business completely that you have any risk. And that’s unlikely to happen, unless they’re delusional or funded by squirrel-minded VCs – which are things you can determine beforehand.
Anecdotal, sure, but it'd be hard to quantify it.
I see this as a side effect of developing economies in the world coming online. When you have to service millions in places with poor network and provide a competitive UX, you don't have the luxury of going with "simple" solutions.
sql("select * from db");
This is what Vercel is pushing into React code. The caliber of their work is low, very low. They are con masters with MBAs
If the destruction of React by Vercel paid your bills and you feel disrespected by my total despise for this get rich fast schema (a la crypto rugpulls), that's a problem for you to solve, not me.
Edit: but in reality I'm happy and thankful to Vercel for imploding React, it helped me to finally check that there are so many better options nowadays.
Respectfully, you have no idea what you're talking about.
Vercel is doing nothing but trying to improve DX for all the things people complain about React.
I don't think it ruined React at all. I think it helped React gain in popularity - which you might interpret as "destruction".
No, it wasn't. Now it is an engineering process.
> I started using Next.js in 2017. It made React a real production framework
In 2017 I had React projects in production for years.
> React was hard to setup and maintain and hard to make it go fast (on first load)
And it only got worse and the overengineering to make it looks fast in the first load is not worth it as modern JS frameworks are faster than React out-of-the-box.
> I don't think it ruined React at all. I think it helped React gain in popularity
That's not what stackoverflow's Insights says[0]. Looks like a free fall for me.
I doubt that. React wasn't stable until 2015, and wasn't mainstream until 2016.
> And it only got worse and the overengineering to make it looks fast in the first load is not worth it as modern JS frameworks are faster than React out-of-the-box.
Again, Next.js != React; the former builds on the latter, it doesn't replace it nor does it claim to be the same thing. I'm not sure why you keep conflating the two.
> That's not what stackoverflow's Insights says[0]. Looks like a free fall for me.
Perhaps you shouldn't bury the lede here. I'm also not entirely sure what your argument is, or why you hold such strong emotions without making your opinions very clear.
https://insights.stackoverflow.com/trends?tags=reactjs%2Cnex...
I started using React before its 1.0 version. Your reasoning is exactly what's wrong with Vercel. Arrogant inexperienced people that think they know better, empowered by VC money. Together with some idealization of being the smartest people around makes you come with solutions like "use server" and throw tantrums when people say this is stupid for a frontend library.
> Again, Next.js != React; the former builds on the latter, it doesn't replace it nor does it claim to be the same thing. I'm not sure why you keep conflating the two.
It is okay if you can't understand what I'm saying, it is difficult to get a man to understand something, when his salary depends upon his not understanding it. I also don't expect you to agree that the work you did contributed to an open source take-over for the sake of profit.
Edit: I just did a research to see if Meta is adopting the amazing "use server" and no public information is available, only people discussing that they aren't. That says a lot about the applicability of this feature and the direction React is being leaded to.
React was complete shit back then - especially the first load speed. It was not ready for "real" production. We basically built an internal framework on top of React for things like server side rendering (which no one did with React back then), above the fold loading optimization, developer experience, devOps on top of React. We basically built Next.js internally.
So no. It was not production ready for real performance-based websites. Next.js made it significantly better as soon as it came out.
I'm a big fan of OSS projects being sponsored by companies that use them for a higher level business. Vs a ton of the C# ecosystem where they try to sell you the library/framework.
But hosting businesses ain't it when it comes to frameworks.. It creates weird incentives.
I guess you can setup the same kind of structure inside of fly.io but I remember some of their writeups have been talking about deployment and pushing the DB to the edge and then having eventual consistency across?
I think that is my hangup on use cases.
That said, fly's deploys are flaky. I hope they get it fixed because the rest of the service is pretty good.
Not to me, it isn't.
There are plenty of areas-of-interest that attract both hobbyists and serious academics alike - which also tends to attract unwanted attention from callous legal departments who are keep to adopt a shoot-first-ask-questions-later policy - things like (lawful) research into DRM techniques, retro video-games (and not ROM hosting), infosec disclosures, and so on - so if you're really into those areas and want a safe place for your lawful content but without worrying about your site/content/services being taken-down without good cause then it makes sense to side with a provider who is able to resist DMCA requests.