deno

> Neat. But for a relevant query, try searching for "npm" instead `is:issue is:open npm` 467 open https://github.com/denoland/deno/issues?q=is%3Aissue+is%3Aop... `is:issue is:open label:bug npm` 199 open https://github.com/denoland/deno/issues?q=is%3Aopen+is%3Aiss... For the record, "NPM compat" probably does include many feature requests (legitimately), not just bugs.

JSX can become valid, standardized ECMAScript syntax. But first we need a valid syntactic sugar transformation, which I propose here. Then we need to implement it in things like babel[0] bun[1] and deno[2]. Then, frameworks would adopt it as an optional alternative implementation. Eventually, it could gain widespread support and become standardized. [0] https://github.com/sdegutis/vanillajsx.com/blob/main/site/un... [1] https://github.com/oven-sh/bun/issues/13630 [2] https://github.com/denoland/deno/issues/25312

Ha, in what I believe Ryan's first talk about Deno, he mentioned something about avoiding cute features or so, then he said Deno has URL-based imports "because they're cute". It didn't take long for someone to raise it up in 2018: https://github.com/denoland/deno/issues/195 We've come full circle :)

This seems like a good step with import maps. Especially following web standards. I like the idea behind jsr, however I'm interested in how they will be integrating additional specifiers. I don't philosophically like having hard coded [0] strings vs smart redirect urls. I'd be interested why jsr couldn't have used standard smart semver following 301s to dynamically load packages, combined with an import map lock file. For example: `import { assertEquals } from "jsr:@std/assert@1";` could be: `import { assertEquals } from "jsr.io/std@1/assert";` With this deno could assume https, as well as follow configs/redirects to get the correct import, then lock those correct paths using import maps (the logistics of this would need hashing out, but it doesn't seem impossible considering they do it with the "special" `jsr:` specifier). It seems like

"embeds TSC as a library" understates the integration: https://github.com/denoland/deno/blob/75efc74931c1021fdc41c9... https://github.com/denoland/deno/blob/75efc74931c1021fdc41c9... Deno makes certain tradeoffs that make it feel seamless

https://github.com/denoland/deno/issues is the ideal place -- we try to triage all incoming issues, the more specific the repro the easier it is to address but we will take a look at everything that comes in.

QUIC is very exciting, after seeing what it did for latency in Cloudflare network and Cloudflare workers, I can't wait to finally see it in Deno 1.41[0]. [0] https://github.com/denoland/deno/pull/21942#issuecomment-192...

Would love to see the compile situation fixed - the generated executables are ~90MB+ at this stage and do now allow compression without erroring out. Deploying ala Golang is not feasible at that level but could well be down the line if this dev branch is picked up again! The exe output grew from from ~50MB to plus ~90MB from 2021 to 2024: https://github.com/denoland/deno/discussions/9811 which mean Deno is worse than Node.js's pkg solution by a decent margin.