Hacker News new | ask | show | jobs
by ohgodplsno 1150 days ago
Building a KV store into the runtime, that has more features when using deno deploy is just that: vendor lock-in. It's just one more way to force you into paying for the service when you have locked yourself in and you can't use an alternative store.

Deno is not and has never been an "alternative runtime" to node.

2 comments

I am confused. In my book vendor lock-in would refer to a situation where a user or customer would be unable to switch vendors or only with prohibitivly large cost and often under the notion that they were unknowingly lead into that situation.

So first of all, _you_ can use whatever ORM or database solution you like in general so _you_ specifically choose which technology you want to invest in. If you want to hand craft your kubernetes cluster for your database nodes and put them on GCP or Azure, then go for it. You want redis? Go for it. If you want to use supabase, firebase, planetscale or whatever, use that. If you want to choose a KV store that's built into your runtime then that's great. Believe it or not but people use lowdb in production and their database is literally a json file. I would argue whichever you choose, switching from one hosting provider, database solution, managed or unmanaged platform to another will always incur cost and how high that is will depend on your depth of integration and familiarity with it. I am most likely going to use this feature and I am happy it exists. Also let's not ignore that there is a large breadth of different needs that developers have. Would I build a massive modular corporate CRM system with BI features with it? Probably not. Am I going to build my next D&D game tool, habit tracker or Tinder for sneaker trading for it? Maybe!

I sincerely wonder what specifically you loose from this feature simply existing.

If they provide a compelling product offering, and the people understand what's available where, and choose to use it, then I guess that can be called vendor lock-in. But it's hardly nefarious.
It is nefarious when you build up your entire product for years, spamming it everywhere as "node but better", yell "it's so open source too!" on every roof, only to sneakily slide in lock-in features, it's worse than being nefarious. You most likely had this plan in mind all along, and actively lied to get there.

Watch as the same happens with Bun.

What's stopping you sticking with Deno CLI, using it for free forever, and completely ignoring anything related to Deno Deploy?

In this relationship of 3 years and counting, they are the positive contributor because they give you something useful for free and you presumably haven't given them anything.

In this specific case I think it's super reasonable.

The KV store has two backbends: local sqlite and distributed deno cloud.

If you choose the deno cloud backend you're signing up for a closed source cloud service from the start. There's no trickery.