Hacker News Reader

Comment by nmca | Hacker News Reader

I find deno to be very exciting. Viable business model, great ergonomics, glorious lack of bullshit configuration busywork.

View on HN

I have tried to be excited about Deno, but just don't see it. What are they doing that hasn't already been done a hundred times in the past? Deno itself is essentially Node.js + automatic TS compilation (which would otherwise have been 1 extra config file). When the project launched they made a big deal about escaping from the messy NPM ecosystem, but then ended up having to turn around and add support for it, taking that differentiator away as well. Deno Deploy is the same as dozens of other Lambda-like services out there. Their KV store and now Queues is equivalent to Redis/LevelDB/RocksDB/Dynamo/SQS or countless similar options. I have yet to come across a single feature that actually sets Deno apart from the rest.

I could maybe see the appeal if you prefer to have a single company in charge of your language runtime + compute hosting + data storage, but I'd personally want to avoid that, especially when the company doesn't have a track record in it.

I think you're underestimating just how much tooling Deno has built-in. It's not just automatic TS compilation, but formatting, linting, testing, and benchmarking at the bare minimum. I use those for almost every project. Each of those would probably be at least another configuration file.

About Deno Deploy, I completely disagree with the analysis that it's just like any other lambda service. It's not just about easy deploys, the service itself is simply better. There are no cold starts and they don't just do that by keeping a vm up all the time. It's really magical. You should give it a second look.

> There are no cold starts and they don't just do that by keeping a vm up all the time. It's really magical.

Do you know how they're doing that, technically? Is it running on Cloudflare under the hood, or if not does it have a similar set of tradeoffs and benefits vs Lambda? Or is it a third completely different way with different tradeoffs/benefits?

I use Deno because I couldn't be bothered to figure out the Node ecosystem and how to actually wire together the Typescript compiler, package json, builders and bundlers, etc. I just do not care and the mess of tooling is frankly exhausting to wade through.

Deno Just Works for me. `deno run file.ts` and you are good to go.

Not to say it's been 100% smooth sailing; I have hit a few rough patches with deployment into my own infrastructure (some within Deno and its dependency management, some within libs like sqlite3) but overall I am happy to not deal with nodejs.

Even after you figure out typescript with node, then you need to figure out sorucemaps otherwise your stack traces won’t be very useful

Deno is compatible with web code to a much deeper level than Node.js is. As the Deno website puts it: "Built with web standard APIs". This might not make a difference to most. Personally though, as someone who strives really hard to share code between frontend and backend, I'm excited for it. This is pretty much the only reason I see Deno eventually winning out over Node.js (in the long run).

I don't have the time to try to port any of my meaningful projects to it right now, but I look forward to the day when I can do so.

The single piece of extra browser compatibility I have found in Deno is that it supports the fetch API, and Node 18+ has that as well. Beyond that there is really no difference between the two.

Whilst I mostly agree, and Node has arguably been forced down the browser-compatible route (for stuff like fetch() and web streams). There is a bunch of other stuff that isn't in Node, or it has it's own APIs for... alert/confirm for getting user input, Web Crypto, URLPattern etc. You can see them all here: https://docs.deno.com/runtime/manual/runtime/web_platform_ap...

With all those alternatives you need to spend time installing libraries, then for each environment you need to create the db, and setup environment variables. You’ll also probably want to figure out a local environment.

With deno all that setup/configuration is handled by deno. There’s obvious trade offs but I think what deno is doing is pretty cool.

I'm not that familiar with these alternatives. What's a good service provider you recommend for a persistent KV store?

- Redis

- ScyllaDB

- Riak

- Couchbase

- Cloudflare KV

- Many different AWS offerings (DynamoDB, ElastiCache)

- Similar alternatives from Google & Azure if you are in those ecosystems

Of course there's nothing unique about a KV store. You can use literally any SQL or noSQL service out there, or set up your own in any way you want.

They also all have the advantage that you will get bindings for every language, not just Deno.

What makes you believe that Deno has a viable business model?

Reply on news.ycombinator.com