6 ms·

The article was fine until this part near the end: > engines prominently lists node. And while you hate it with the depth of your soul, you are not going to Bu

The article was fine until this part near the end: > engines prominently lists node. And while you hate it with the depth of your soul, you are not going to Bun or Deno because you know this will not stop the pain. This will only make the pain worse. Deno will make the pain worse? Nearly every complaint in the article could have been solved by using Deno. - Package.json, no such thing for Deno (not unless you go out of your way to infect Deno with it) - main, browser, and fs don't matter in Deno since Deno's APIs are based on browser APIs. - type, module, requires, and imports doesn't matter in Deno since it shares the same import API as browsers. - scripts, doesn't matter since all Deno projects have the same tools built-in (benchmarker, bundler, compiler, formatted, linter, task runner, test runner, etc...) - watchman doesn't matter since deno has watch support built in - dependencies doesn't matter anywhere near as much because Deno comes with a standard library - left-pad doesn't matter because it's part of the language - moment.js doesn't matter since you can just use the browsers built-in Temporal api - resolutions, dev-dependencies don't matter for the same reason that dependencies doesn't matter - eslint doesn't matter since deno has a linter - postcss matters less because modern css is great - jest doesn't matter because deno includes a test runner - no need to work out typescript installation with your dependencies because deno includes typescript and has less dependencies The only things not solved by using deno is version and name, which are universal concerns amongst all projects, not just the js ecosystem.

phist_mcgee 3y ago
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.
- spartanatreyu 3y ago
  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.
  - troupo 3y ago
    > 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.
franciscop 3y ago
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.
- spartanatreyu 3y ago
  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).
SomeCallMeTim 3y ago
> 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.
- spartanatreyu 3y ago
  > > 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.
cxr 3y ago
> 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.

phist_mcgee 3y ago

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.

spartanatreyu 3y ago
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.
- troupo 3y ago
  > 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.

franciscop 3y ago

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.

spartanatreyu 3y ago
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).

SomeCallMeTim 3y ago

> 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.

spartanatreyu 3y ago
> > 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.

cxr 3y ago

> 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.