Deno
Deno's development environment and Deno itself are rough around the edges, and should not be used in production.
Considering Deno's development time, the Deno team's performance has been subpar,
to the extent that Node.js has gradually caught up with Deno's features, and competitors like Bun have emerged in the same ecosystem.
It's difficult to have confidence in Deno's future.
to the extent that Node.js has gradually caught up with Deno's features, and competitors like Bun have emerged in the same ecosystem.
It's difficult to have confidence in Deno's future.
- Developed in Rust.
- APIs are as compatible as possible with the Web environment.
- Opinionated `deno fmt`, `deno lint`, `deno test`, `deno bench`.
- Secure by default, with a fine-grained permission system that supports dynamic permission requests.
Currently, due to Deno having many internal fields, fine-grained permissions can be inconvenient to use, often forcing users to resort to coarse-grained permissions. - Native TypeScript support, which is becoming increasingly important as the JavaScript community shifts towards TypeScript.
- Node.js compatibility.
Deno's built-in functionalities generally lack rigorous testing, relying on community feedback for error detection.
Although LTS in various projects shows signs of getting shorter, Deno 2 declaring 6 months as LTS upon release is still laughable.
Deno Land Inc. is keen on developing clones/alternatives for other ecosystem products.
These products visibly lack thorough consideration, and their maintainability is questionable.
These products visibly lack thorough consideration, and their maintainability is questionable.
This tendency also affects Deno itself; for instance, Node.js compatibility is a typical example of marketing hype overriding actual delivery:
https://docs.deno.com/runtime/reference/node_apis/#fully-supported-modules
https://docs.deno.com/runtime/reference/node_apis/#fully-supported-modules
Even moderately sized Deno projects can lead to slow LSP response times, easily deterring developers who want to use Deno.
In contrast, Node.js and TypeScript-based projects do not have similar issues.
Deno's LSP default configuration is quite conservative; for example, `documentPreloadLimit` defaults to 1000, which is easily exceeded in actual development.
The design of the WHATWG stream model is quite rudimentary, far inferior to Node.js streams.
For example, users cannot even know if or when a stream has closed.
Modules determine their protocol based on how they are imported.
When a module is imported as a local module, its `import.meta.url` uses the file protocol.
When a module is imported as a remote module, its `import.meta.url` uses the http/https protocol.
When a module is imported as a local module, its `import.meta.url` uses the file protocol.
When a module is imported as a remote module, its `import.meta.url` uses the http/https protocol.
The problem is that many APIs only support one protocol; for example, `Deno.readFile` only supports the file protocol, not http/https.
This situation adds more mental overhead for developers when using `import.meta.url`.
The root problem lies in Deno not exposing the local path of imported (cached) modules, which is a problem that could be solved at the design level.
This situation adds more mental overhead for developers when using `import.meta.url`.
The root problem lies in Deno not exposing the local path of imported (cached) modules, which is a problem that could be solved at the design level.
https://github.com/denoland/deno/issues/5987
Quite tragically, Deno solves file reading-related issues by making the fetch function support the file protocol.
https://github.com/denoland/deno/issues/3196
TypeScript does not support compiling module paths with a `.ts` extension to a `.js` extension,
while Deno's module paths must have a `.ts` extension.
Therefore, code for TypeScript projects designed for Node.js modules will not run in Deno.
while Deno's module paths must have a `.ts` extension.
Therefore, code for TypeScript projects designed for Node.js modules will not run in Deno.
TypeScript 5 began supporting the `allowImportingTsExtensions` configuration option, which allows using `.ts` extensions in a project,
but this option is restricted to being used only when configured for `noEmit` or `emitDeclarationOnly`,
meaning that using `.ts` extensions simultaneously with generating code usable by Node.js is not possible.
but this option is restricted to being used only when configured for `noEmit` or `emitDeclarationOnly`,
meaning that using `.ts` extensions simultaneously with generating code usable by Node.js is not possible.
The JavaScript package registry promoted by Deno official.
Although JSR promotes itself as a modern JavaScript package registry, it is still just Deno's version of npm.
JSR is not a superset of npm, just as TypeScript is not a superset of JavaScript.
Although JSR promotes itself as a modern JavaScript package registry, it is still just Deno's version of npm.
JSR is not a superset of npm, just as TypeScript is not a superset of JavaScript.
This registry largely aims to solve Deno's existing dependency management issues (the boomerang Ryan Dahl threw in 2018 finally hit him):
different modules import dependencies from different registries, or import different sub-versions of the same registry dependency due to a lack of SemVer.
This leads to project bloat (which increases LSP burden) and a lack of referential equality between imported dependencies.
different modules import dependencies from different registries, or import different sub-versions of the same registry dependency due to a lack of SemVer.
This leads to project bloat (which increases LSP burden) and a lack of referential equality between imported dependencies.
Deno official states that the original package registry deno.land/xcan still be used,
but considering that the official standard library `std` is no longer updated on deno.land/x, it is expected that publishing packages to deno.land/x further is pointless.
but considering that the official standard library `std` is no longer updated on deno.land/x, it is expected that publishing packages to deno.land/x further is pointless.
Now, a dedicated prefix `jsr:` can be used (similar to the npm module support added in Deno 1.28) to simplify URLs.
https://github.com/oakserver/oak
https://fresh.deno.dev/
Deno's official full-stack Web framework launched in 2022, a counterpart to Next.js.
It is not recommended to use it because:
- Almost no React libraries are tested for Deno support.
- Internally uses Preact, a lightweight variant of React, which is a dead-end technical path.
Deno can import JSDOM via CDN.
import { JSDOM } from 'https://esm.sh/jsdom@22.1.0'https://github.com/b-fuze/deno-dom
This project is a binding for the Rust html5ever package.
SQLite using Deno FFI.
Pros:
- Interface is largely identical to better-sqlite3.
- High performance.
SQLite compiled to WASM.
Pros:
- Minimal permissions.
- Cross-platform.
Cons:
- Limited by Deno's file system API.
- Very few compilation options enabled by default; likely requires custom compilation.
Since Deno 1.21, the standard library has provided a significant number of testing features,
making it possible to complete testing in most cases without using third-party libraries.
Deno's technical choice effectively avoids Node.js testing's vendor lock-in problem.
making it possible to complete testing in most cases without using third-party libraries.
Deno's technical choice effectively avoids Node.js testing's vendor lock-in problem.
The current standard library already supports BDD style, mock/stub, snapshot matching, and timer mocking:
https://deno.land/std@0.181.0/testing
https://deno.land/std@0.181.0/testing
https://github.com/denoland/deno_std/issues/1779
Deno provides a built-in command `deno bundle` to bundle a project into a single script file.
Ryan Dahl once proposed deleting this command, but the idea was later retracted.
However, in v1.31, the command was still listed as deprecated without community discussion, and the official manual suggested using esbuild instead.
However, in v1.31, the command was still listed as deprecated without community discussion, and the official manual suggested using esbuild instead.
In v2.4, deno bundle inexplicably returned, with esbuild as its underlying mechanism.
In v2.5, it gained support for HTML files as entry points for bundling.
In v2.5, it gained support for HTML files as entry points for bundling.
When running a script with the `deno run` command, the TypeScript type checker is loaded, which causes the deno process to use more memory.
If the script is first compiled with `deno compile` and then run, the script's memory usage will significantly improve.
If the script is first compiled with `deno compile` and then run, the script's memory usage will significantly improve.