Hacker News Reader

Comment by binarynate | Hacker News Reader

I'm a long-time Node user but decided to use Deno for a personal project and found that it's is a pleasure to work with. Some highlights:

  - TypeScript works out-of-the-box without configuration
  - includes modern browser APIs like fetch() without needing to import additional dependencies
  - The Deno-specific APIs (like Deno.readTextFile()[0]) are Promise-based and have intuitive interfaces
  - The Deno standard library[1] reduces the need for 3rd party dependencies, since it covers a lot of cases where one would be needed

I haven't yet used Deno in a commercial product, but I believe I will in the future because Deno seems ready for primetime.

  [0]https://doc.deno.land/builtin/stable#Deno.readTextFile
  [1]https://deno.land/manual/standard_library

View on HN

> The Deno-specific APIs (like Deno.readTextFile()[0]) are Promise-based and have intuitive interfaces

FYI, Node has Promise-based APIs for all filesystem APIs. Node also supports ES modules that use top-level await.

If you create a file `test.mjs` and put this in it, it'll work:

    import {readFile} from 'fs/promises';
    console.log(await readFile('foo.txt', 'utf8'));

https://nodejs.org/api/fs.html#fs_filehandle_readfile_option...

Thanks—I didn't know about fs/promises

The fundamental advantage of TypeScript (vs other languages like Scala.js) was that it could easily leverage the entire Node.js (EDIT: JavaScript) ecosystem and vice versa in a very smooth way.

Deno goes in the wrong direction. It's a TS fanboy invention in search of a problem.

And I say that as a TypeScript fanboy.

TS by itself is a great language even without the JS support. The Node ecosystem has a lot of shortcomings which Deno aims to solve. I disagree with your assertion that Deno is a fanboy invention in search of a problem. If the creator of Node, started Deno, then obviously there is some merit to his thought process.

> TS by itself is a great language even without the JS support.

Hardly. TS would have 1% of the adoption without JS.

> creator of Node, started Deno

Kudos for Dahl for his practical, very successful project Node.js.

There is still a lot of friction using Typescript for just about any Nodejs project. Things have definitely improved, but it is still a far cry compared to first class language support.

I’m curious what you think is the right direction Deno should have taken.

Do you know if Deno chose to use strings instead of buffers to be more consistent with the browser? I know buffers can be faster, but overall I like that readTextFile is returning a string here. I suspect most use-cases ultimately want to handle the output as a string.

Deno uses uint8array (pretty much Nodes Buffers (Node Buffers subclass UInt8Array these days)) for almost all methods. For example Deno comes with `Deno.readFile` which returns a Promise<UInt8Array>, but they include the special case Deno.readTextFile because of how common it is to convert the contents to a string.

Ah of course, that seems obvious in retrospect. Thanks for clarifying it for me!

> - The Deno-specific APIs (like Deno.readTextFile()[0]) are Promise-based and have intuitive interfaces

require("fs").readFileSync("hello.txt").toString() // toString because it's a buffer by default

A Promise-based API doesn't block the event loop, but a synchronous one like fs.readFileSync does. Their usage might look similar but their semantics differ vastly.

Fair enough. OP was talking about intuitive non-blocking APIs and I just considered "intuitive".

Reply on news.ycombinator.com