Hacker News new | past | comments | ask | show | jobs | submit login

I like using Workers for smallish http services. The uptime, pricing, and latency are fantastic. I would never use them for anything complex as the vendor lock in is quite strong and the dev experience still needs to improve.

Containers on the edge with low cold starts, scalability, the same reliability as Workers, etc would be super cool. In part to avoid the lock in but also to be able to use other languages like Go (which Workers don't support natively).




Workers use the web worker API so theoretically there’s less lock in. I’ve also found wrangler pretty good, what problems have you run into?


You can't really run the Worker code without modifications somewhere else afaik (unless you're using something like Hono with an adapter). And for most use cases, you're not going to be using Workers without KV, DO, etc.

I've hit a bunch of issues and limitations with Wrangler and Workers locally over the years.

Eg:

https://github.com/cloudflare/workers-sdk/issues/2964

https://github.com/cloudflare/workerd/issues/1897


This is why I switched to deno deploy. Much of the same benefits and much more portable stack.


It's great you can run Deno anywhere you want. Their KV service is phenomenal too.

Personally I don't want to keep using JS in the server anymore. As more time passes I feel like TS is a hack compared to the elegance of something like Go.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: