Hacker News Reader

> Package.json, no such thing for Deno (not unless you go out of your way to infect Deno with it)

Yeah...this always felt like a bug in Deno. ¯\_(ツ)_/¯

> scripts, doesn't matter since all Deno projects have the same tools built-in (benchmarker, bundler, compiler, formatted, linter, task runner, test runner, etc...)

AND...you therefore can't do anything outside of the box in a well-defined way. Oops.

Example: How do I run just the main server and not a worker? How do I seed the database?

> dependencies doesn't matter anywhere near as much because Deno comes with a standard library

Sigh. Yeah. Really. You said that.

OK, using the standard library, please:

- Parse Excel files, modify them, and rewrite them to disk.

- Load and modify a PNG and write it out as a JPG. Be sure you scale it down using a Lanczos kernel.

> eslint doesn't matter since deno has a linter

One of the most powerful eslint rules for TypeScript is the detection of dangling promises. A quick glance at the deno lint rules doesn't see anything that will handle this critical lint rule.

And OOPS, adding eslint to the project in a standardized way isn't possible because there's no package.json!

... I could go on.

Sorry, but Deno fanboying is so last year.

> > scripts, doesn't matter since all Deno projects have the same tools built-in (benchmarker, bundler, compiler, formatted, linter, task runner, test runner, etc...)

>

> AND...you therefore can't do anything outside of the box in a well-defined way. Oops.

>

> Example: How do I run just the main server and not a worker? How do I seed the database?

That doesn't really make sense. If you're trying to do anything in a well-defined way, you're going to need a box. The box is the definition.

------------------------------------------------------------------------------------------------

> > dependencies doesn't matter anywhere near as much because Deno comes with a standard library

>

> Sigh. Yeah. Really. You said that.

>

> OK, using the standard library, please: [...]

I'm not going to be able to do these in a comment here, but I can briefly tell you how I would go about doing them.

> - Parse Excel files, modify them, and rewrite them to disk.

Use streams API to create a pipeline (input -> modify -> output).

If by Excel files you mean CSVs, then I can stream the whole thing, making modifications and saving while I'm still streaming in the file.

If by Excel files you mean an xlsx file, then I tweak the pipeline to (input -> unzip -> modify -> rezip -> output).

> - Load and modify a PNG and write it out as a JPG. Be sure you scale it down using a Lanczos kernel.

First I'd make sure I have the encoder and decoder settled. If you have a specific encoder in mind (e.g. ImageMagick + specific settings) then you can box that up by compiling it to web assembly. If you don't have a specific encoder in mind then it doesn't really matter what you use. If you have a specific encoder in mind, then same thing. If you don't, you can always use the JS standard Canvas API which you can load an image into then pull out raw pixel info.

If you want to do the whole thing from scratch, you can do it like the Excel way and create a pipeline using the streams API and TypedArrays.

------------------------------------------------------------------------------------------------

> > eslint doesn't matter since deno has a linter

> One of the most powerful eslint rules for TypeScript is the detection of dangling promises. A quick glance at the deno lint rules doesn't see anything that will handle this critical lint rule.

>

> And OOPS, adding eslint to the project in a standardized way isn't possible because there's no package.json!

Linting for floating promises is tricky to accomplish (ESLint doesn't get it quite right).

Depending on the code, you can get stuck in the halting problem. To solve it correctly, you need to write a compiler/solver that has access to the relevant type information.

This is something that the typescript project itself has been investigating and once solved would be added as another strict rule (e.g. noImplicitOverride, etc...).

If you don't care about correctness and want any heuristic solution, then use any heuristic solution.

ESLint does an amazing job in detecting floating promises. I've not had it miss one, ever. When adding this to a project, I've discovered multiple accidental bugs due to a missing "await" keyword--bugs that were extremely subtle and intermittent in many cases.

The only thing it can't do is determine that you actually did handle the promise later. Which is fine. It's a LINTING RULE, and false positives are the name of the game.

What's BAD is when you accidentally miss handling a promise at all. It's an invisible error without the linting rule.

Your other comments...don't even make sense. You're going to build a Lanczos filter by hand? Or you're only going to ... compile ImageMagick to WebAssembly?!, ... an implementation which is tremendously slower (nearly unusably so for large images) than that of Sharp:

https://www.npmjs.com/package/sharp

... which is simply an import away?

No, what you're doing is called "motivated reasoning." You've concluded that Deno is the best, and you're reinterpreting all of my complaints in convoluted ways to support your predetermined conclusion.

Standard fanboy behavior. Or troll behavior. I cite Poe's Law as why it's impossible to tell the difference.

Not a fanboy. But I'll go through my reasoning anyway.

----------------------------------------------------------------

## Eslint

We're on the same page that:

- heuristics work until they don't

- we'd all rather have false positives than missed positives

- Having something is better than nothing

- ESLint fits it's roll well for now

I've been using node since the 0.x days and used iojs while it was ahead, I've gone from jslint -> jshint -> eslint -> tslint -> eslint (because it supported ts) + sonarlint -> now (which is rome tools in editor, and sonarlint to catch what rome tools doesn't support yet).

The one problem I've had transitioning projects through each linter is just the amount of crufty exception comments to disable rules that ends up through my code.

I've found that I can get rid of a lot of those by setting up my configs and turning on most of the strict modes.

As for promises specifically, I've ended up needing to fire off a lot of floating promises in the last 18 months. There's a lot of firing things off to set values in things that may not exist anymore. (I've noticed it happens a lot a lot around using Promise.race to make code that gracefully recovers in chaotic environments)

The false positives got too much so I disabled the rule (and at a later point moved away from eslint altogether).

There's also some tricky things with catching floating promises when working with frameworks that can deal with super hard to debug side-effects.

So now I have:

- floating promises where for specific situations I don't want to catch their errors and have them throw up to the next layer

- floating promises that are conditionally caught

- floating promises that are actually a wrapped promise that fails as an uncaught promise should, but also conditionally triggers the debugger or logs out a trace.

I use different approaches depending on the situation.

Maybe for you, the only situation you need to deal with is catching all promises (in which case you should continue using ESLint then turn off that rule when TS gets the correct promise handling detection), but for me it causes more trouble than it fixes.

----------------------------------------------------------------

## Images

If I had to do what you suggested, I would have actually just used sharp, but after reading your comment about dependencies, I wasn't sure if you would accept that answer.

I suggested two alternatives:

1. Compiling an existing solution into web assembly to box up that functionality and call into it. It could be ImageMagick, libpng, libspng, libvips, etc... I suggested ImageMagick because that tends to be the go-to for when someone has a specific setting in mind (usually due to a legacy system).

2. Setting up streams and using TypedArrays (which is what sharp uses anyway)

There's a lot of 'just' in your argument.

As programmers we fall into this trap where we think that 'just' doing something else will solve all our problems. But I can guarantee that it's never that simple, and for the people who consume your library, it won't be either.

There's a lot of 'just' in your argument.

I used the word "just" once in my comment in the point about using Temporal.

The Temporal spec was created in part specifically because of the issues with moment.js.

----------------------------------------------------------------------------------------

> But I can guarantee that it's never that simple, and for the people who consume your library, it won't be either.

Unfortunately, Node has historically not used the same standards as browsers over a whole swath of functionality, which lead to differences in the language based on whether it was running client-side or server-side.

Simple libraries intended to run anywhere would sometimes need to release a client version and a server version.

Even when node started adding support for the standard APIs instead of creating new proprietary APIs, they ended up with a fractured ecosystem where some things would only work with the proprietary APIs, and some would only work with the standard APIs.

There were so many missteps with node that the creator of node essentially said screw this, I'm starting again from scratch, hence: Deno.

Coming back to your point:

> But I can guarantee that it's never that simple, and for the people who consume your library, it won't be either.

But it *IS* that simple.

How?

Because Deno uses the standard APIs for things. If it already works in the browser, it will continue to work in the server. No more fractured language.

> Because Deno uses the standard APIs for things. If it already works in the browser, it will continue to work in the server. No more fractured language.

For greenfield projects? Maybe. For established projects? Not for a very long time.

There's a reason Deno added support for npm modules and CommonJS. Because no amount of wide-eyed naïve fanboyism can replace reality.

This feel pretty biased pro-Deno:

- "main, browser, and fs don't matter in Deno since Deno's APIs are based on browser APIs."

  - fs implies we are reading files, how do you use a browser API to read files in the local filesystem? You cannot, you'd use Deno.readTextFile, which is not browser-compatible, so in Deno you have to either make it for Deno or for the browser, not both. The fields main and browser allow you to make a single package compatible with both NodeJS and front-end JS, something not possible with Deno.

- "type, module, requires, and imports doesn't matter in Deno since it shares the same import API as browsers."

  - Seems like Deno just doesn't support CommonJS, e.g. the vast majority of npm modules, which is a big con and not an advantage: "Current Node.js supports both CommonJS and ES Modules, while Deno only supports ES Modules"

etc.

If you interpret the article as intended, yes Deno will make the pain worse because virtually no one is writing libraries that only supports Deno, so now you'd have all the above issues + Deno-specific ones.

I can see where you've gone wrong, let me briefly go though your points.

> fs implies we are reading files, how do you use a browser API to read files in the local filesystem? You cannot, you'd use Deno.readTextFile, which is not browser-compatible, so in Deno you have to either make it for Deno or for the browser, not both. The fields main and browser allow you to make a single package compatible with both NodeJS and front-end JS, something not possible with Deno.

Both Deno and browsers have a bunch of APIs facilitating File/FileSystem/Stream, etc...

- In Deno, you can use things like Deno.readTextFile which is written on top of those APIs to read/write files on the server's file system which the server will do if it asks for permission and is granted by the developer.

- In browser, you can still use those APIs to read/write files on a private sandboxed file system, and the client can request permission to read/write between the private sandboxed file system and the client's real file system through things like the file picker API's, drag and drop APIs, etc...

- The only real difference between the two is that the developer can explicitly grant the server access to files/folders up-front before the server asks for permission in the first place.

> Seems like Deno just doesn't support CommonJS, e.g. the vast majority of npm modules, which is a big con and not an advantage: "Current Node.js supports both CommonJS and ES Modules, while Deno only supports ES Modules"

Deno *Does* support CommonJS (see the --compat flag). But you probably want to use ESM over CommonJS anyway.

> [...] Deno will make the pain worse because virtually no one is writing libraries that only supports Deno, so now you'd have all the above issues + Deno-specific ones.

If you write your library to the JS standards, then you have code that supports both browsers and Deno (and possibly Node depending on if Node supports those particular standards and you're web standard code isn't being used by your non-web standard code).

- That's not the point, the point is that by having a browser and a main script you can selectively pick whether you are loading one or the other. The browser loads the browser-only code, the main loads the fs-compat code. Browser support for FS is a joke compared to NodeJS support.

- That was a quote from Deno's official page, if it supports commonjs better ofc. "But you probably want to use ESM over CommonJS anyway" -> no way, if you want to use most of the npm packages you need support for commonjs. Ofc you'd be writing ESM for your modern app though.

- There's no "JS standards" for backend stuff like FS, running commands, launching a server, etc. so very often you need backend-specific code. You already showed two extra pain points of using Deno vs Node in this convo, adding the `--compat` flag and granting permissions.

> Nearly every complaint in the article could have been solved by using Deno

Alternatively, don't go out of your way to install Node or Deno—instead, just use the runtime you already have on your computer; browser makers are much better at following the standards (and consequently not encouraging/inducing you to write against standards-incompatible APIs to begin) than the people peddling Node and Node-influenced stuff.