Comment by jamal-kumar | Hacker News Reader

Comment by jamal-kumar | Hacker News Reader

I tried Deno and really liked it. The pros:

- It uses the v8 engine so you've got the same APIs you know and love for the browser like fetch() - Something that nodejs is just catching up to now

- It's not nodejs, the whole name means 'destroy node'. You can get a lot done without being buried in dependencies. Well-maintained core libraries.

- Server-Side WASM is a really interesting idea for encapsulating and integrating stuff written in, say, C++

The cons:

- Some of the third party ecosystem seems to be suffering from a lack of recent maintenance

- Server-side WASM is limited to 32-bit until they figure that out, which also limits whatever you do with it to a 4GB memory ceiling

Other than all that though it's probably not a bad choice for anyone not bothered by those limitations and just wants everyone who speaks typescript on the frontend to be able to grasp what's on the server side end of things too.

I think it could probably thrive with more usage traction.

Node.JS and Deno are both running with V8. fetch() isn't part of the JS standard library, it's a Web API. Deno just made (the good imo) design decision to support WebAPIs over something more custom despite the fact that it's not a runtime for web apps.

Server-side WASM is the future for FaaS imo, sandboxing built in and an effective object-capability approach to dependency safety is amazing.

fetch is also an API in node (last few versions)

https://nodejs.org/dist/latest-v18.x/docs/api/globals.html

Hello Java servlets.

Fetch is not included in v8. If it were, node would have had it earlier...

Deno doesn't mean 'destroy node', it's just node reordered.

i think the name is actually derived from 'node'.split('').sort().join('') but i like "destroy node" a lot better lol

judging by the comments here everything I knew was apparently a confabulation

Explanations that are visceral have narrative power tend to be believed and spread much more widely that the true, boring explanation.

A classic "true fact" that's false: Hey did you ever hear that people in england used to brick up their windows due to a window tax? (true) Thís is the origin of the phrase "daylight robbery" (false)

Node also uses V8, the lack of API parity with browser is unrelated.

Another pro in my book: it "compiles" to a single binary. I was writing a small side project and when it was time to deploy, it was as easy as to push the binary to my server via `scp`. That single binary also includes a copy of `sqlite` since it is a WASM dependency. Also, cross compilation. I can compile it from my m1 mac for an x86 linux server.

This and the built in formatter make me feel like Deno’s developer experience was directly inspired by golang

I mean, the standard library is inspired in golang's[1], so I would assume that other parts of their design are also inspired by go.

[1]: https://deno.land/std@0.177.0#contributing

> copy of `sqlite` since it is a WASM dependency

How's the performance vs ffi version? I'm about to use deno with sqlite and have to decide which one to use. The lack of WAL in WASM version gives me a pause though.

> How's the performance vs ffi version?

Can't say because I haven't compared them. This is a small personal project that will have less than 10 users, so I'm not that worried.

I'm a huge fan of it personally. To me, relative to Node the way this handles feels, broadly, closer to a browser -- by leaning on Web standards there's a variety of knowledge transfer between client-side work and server-side for things like packaging, API calls, and various other functionality; and it builds in enough basic tooling that I don't have to find or install or develop opinions on external libraries for handling anything from watching files to using environment variables to running tests (if I necessarily cared to do that with personal projects).

The limitations that stick out most to me personally are that there's still no ARM support, and that, while the Node compat is getting a lot better, it's still hard to get a clear sense of where it is for individual packages -- what runs natively/is isomorphic, vs what'll run under a compat layer, vs what just won't run at all.

32-bit ARM you mean? I’m not a big user, but it seems to be native on my ARM mac.

That's less of a distinction with 32- vs 64-bit for me (though I know that does also pose issues for, say, users of any Raspberry Pi other than the 4B/CM4) and more that there just aren't any first-party ARM builds for Linux.

(That said I can't really speak to macOS here, as I really only use Macs when workplaces require me to, which also doesn't necessarily translate to having sudo access.)

I do wonder how it compares with a more suitable server language like go. Being better than js is a low bar

Personally given a preference I like go more but sometimes you just need everyone on the frontend to be able to read your code on the backend without having needing them to spend a week learning a new programming language

Reply on news.ycombinator.com