DAdangoor·Nov 17, 2021
I'm pretty sure Deno just uses the open source TypeScript compiler: https://github.com/denoland/deno/tree/main/cli/tsc
In The perfect configuration format? Try TypeScriptdenoland
deno
Rust2018–2026
denoland / deno
deno
A modern runtime for JavaScript and TypeScript.
161Distinct people
202Mentions
1Explicit recommenders
108.9KGitHub stars
What to know before exploring
What it is
A modern runtime for JavaScript and TypeScript.
GitHub
Where it is used
What people are saying
I love Deno and I use this, but I really wish they would fix this dumb bug: https://github.com/denoland/deno/issues/16466
IshKebab used a recommendation phrase. One indexed comment matches. This is a phrase match, not a verdict.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
- oven-sh/bun · linked in 6 of the same discussions
- libuv/libuv · linked in 3 of the same discussions
- denoland/rusty_v8 · linked in 2 of the same discussions
Mentioned in the same Hacker News threads. That is not proof they are substitutes.
This week on Hacker News
Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 8:03:49 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year202 dated mentions
Observed mentions: 2018-08-23 15:35:35 UTC to 2026-10-16 06:53:01 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 16 | 4 | 12 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 8 | 1 | 7 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 45 | 18 | 27 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 30 | 4 | 26 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 33 | 4 | 29 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 30 | 1 | 29 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 9 | 1 | 8 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 18 | 0 | 18 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 13 | 1 | 12 |
What Hacker News says
30 sourcesI detest this piece of crap idea so much. You've created "files" and made an interface to them, but they are in no way usable or empowering to users? The files don't really exist at all? They are only for devs to use? How have you fucked up files so badly? Why would you do this? This is just an absolutely ruthlessly awful idea, deeply anti-user, a perfect shit-storm of user-loathing.
On the plus side, at least the spec authors didn't build a ridiculous overprotective childs toy like the File System Access api. Which does actually let the web work with files users can also work with. But which makes all kinds of huge promises about durability & robustness that make sure that the actual API webdevs get for dealing with files is ridiculously hideously unperformant & riddles with problems so as to be nearly useless. It's unusable for any kind
Read the rest
of interesting application like running sqlite or any other scenario where data is updated in-place. Deno evaluated this API & basically laughed it out of the room as infeasible & worthless, on a number of dimensions. https://github.com/denoland/deno/issues/11018
So the web is in the worst possible spot. We have one API where we can do nothing for our users: we can build fancy new data tools with Storage Foundation but we can't work with user files or expose what we're doing. Or we can work with File System Access, and manipulate user files, but incredibly slowly. I think of Adobe recently trying to port Photoshop & Illustrator to the web, & how much they must be cursing the "hell" or "damnation" options they've been given with this sickening situation.
There is work to try to take much of the Storage Foundation API & to extend & build it out into Yet Another Specification, currently called Access Handles, that does interface with real files. This is the only chance we're going to have in the next half decade for the web to not be utterly trash at working with files. Pray for the suck to stop.
OP should have tested Deno (https://github.com/denoland/deno) too along side Node. Alas...
In AWS Lambda Cold Start Times> V8 requires glibc
I don't _think_ this is true.
https://github.com/denoland/deno/issues/3711#issuecomment-62...
In Why I'm donating $150/month (10% of my income) to the musl Libc project (2019)A year and half ago kesor was able to get deno to build without glibc (so it would work on stock alpine). It seems to be gn args/configs that need fiddling.
Unfortunately this work has never been brought into main (a couple of attempts have been made subsequently).
https://github.com/denoland/deno/issues/3711#issuecomment-62...
In Why I'm donating $150/month (10% of my income) to the musl Libc project (2019)That comes at the right time to help me understand why Deno puts in a Node compatibility mode [^1] all of a sudden. Truck loads of eggs, or chickens depending on your view.
[^1]: https://github.com/denoland/deno/issues/12295
In Chicken and Egg Problem (2000)I'd argue the JS engine in browsers is _also_ built for JS developers, and even though we are definitely a minority compared to all the internet users it's important to underline that most of the stuff currently available online, for better or for worse, wouldn't exist without developers writing it. Like the average user in fact couldn't care less about what languages websites are written in, but if browsers shipped only a brainfuck compiler I'm sure there would be a lot less development happening on the web, in some sense JS developers are the target users of JS engines.
I think this is literally the first time that I hear anybody saying that TypeScript is very fast. It's no coincidence that the top open issue in Deno's repo is literally titled "TypeScript compiler in Rust" [0]. The developer behind swc is even rewriting the whole type c
Read the rest
hecker in TypeScript [1]. A lot of people, myself included, think that TS can get excruciatingly slow, in a large-enough but not really huge codebase, in a way that probably wouldn't happen if it were written in something like Rust with a big focus on performance.
[0] https://github.com/denoland/deno/issues/5432
[1] https://github.com/swc-project/swc/issues/571
If you have all code already, just paste into a file and run that file…
Otherwise you might want to check out piping support https://github.com/denoland/deno/pull/6130 Something like `echo "yourcodehere" | deno run -`
In Deno 1.14https://github.com/denoland/deno/discussions/11771
> NodeJS compatibility, what is our high-level strategy, goals, next steps?
> Do we see Node and Deno co-existing, or do we want to think of Node as "legacy"? (Note, there was no clear decision on this question, it was just a conversation)
> If we could say "you can run your Express server under Deno faster than Node" would that encourage adoption? No clear answer
I really wish they go for a better compatibility with Node and sell themselves as a replacement that is strictly better.
In Deno 1.14And indeed, you can see as a great example from the discussion on this thread how they eventually arrived at relying on Rust for most steps in the tsc toolchain: https://github.com/denoland/deno/issues/5432
The conclusion reached there is as you have stated: Rust is simply an order of magnitude faster in most cases.
In Deno Deploy Beta 2Here's a gotcha for you: https://github.com/denoland/deno/issues/4568
In Deno Deploy Beta 2/tmp$ mkdir test
/tmp$ cd test
/tmp/test$ curl -sOL https://github.com/denoland/deno/releases/download/v1.13.1/deno-x86_64-unknown-lin…
/tmp/test$ unzip deno-x86_64-unknown-linux-gnu.zip
Archive: deno-x86_64-unknown-linux-gnu.zip
inflating: deno
/tmp/test$ cat > test.ts
console.log('Hello, World!');
/tmp/test$ ./deno compile test.ts
Check file:///tmp/test/test.ts
Bundle file:///tmp/test/test.ts
Compile file:///tmp/test/test.ts
Emit test
/tmp/test$ ls -lh
total 198M
-rwxr-xr-x 1 user user 83M août 16 23:52 deno
-rw-rw-r-- 1 user user 32M août 23 19:12 deno-x86_64-unknown-linux-gnu.zip
-rwxrwxrwx 1 user user 83M août 23 19:13 test
-rw-rw-r-- 1 user user 30 août 23 19:13 test.ts
/tmp/test$ ./test
Hello, World!
In Deno on MDNShowing the 15 most recent of 30 sources. Enable JavaScript to search and browse every indexed mention.