from Hacker News

Deno: What we got wrong about HTTP imports

by Signez on 7/29/24, 4:00 PM with 23 comments

• by Thro4l31 on 7/30/24, 11:54 AM

  Deno (with Typescript of course) is my "smaller Rust". Whenever I don't need the performance and efficiency of Rust, I fall back to Deno. The development speed is much higher while the result is reasonable fast and safe.

  - Typescript (compared to other main stream languages like Go or Java) comes pretty close to Rust regarding the type system, e.g. discriminated unions (https://mkosir.github.io/typescript-style-guide/#discriminat...) or null-checks as "the second best version of null safety". (The best is still the option type.)

  - Deno has an exceptional core api and std lib. Performance is great. In my experience it's very stable (except some newer Node APIs). The tooling is great and now the move to JSR and Node compatibility widens the ecosystem while trying to make it safer. I wonder how the Deno team plans to push JSRs adoption.

  - It's single threaded. Yes, I think it's a feature. Multithreading via Webworkers might not be as fast as sharing memory, but it's much safer. I even think it has an edge over Go, if you don't need the extra performance of Go. Go is generally faster, esp. for computations. Web stuff in Deno is fast enough as they use Hyper under the hood.

  I really hope JSR adoption will grow.

• by samschooler on 7/29/24, 7:21 PM

  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 this would maintain the same pros while avoiding the "special" specifier hard coding that exists now (seems to only be for npm: and jsr: right now; no github: for example).

  [0]: https://github.com/denoland/deno/blob/8c2f1f5a55a2a9bb9e04c1...

• by tengbretson on 7/29/24, 5:43 PM

  Introducing the revolutionary new JS runtime "Endo".

• by frankjr on 7/29/24, 4:18 PM

  Not sure if that's any simpler than having the good ol' package.json at this point.

• by mplewis on 7/29/24, 5:23 PM

  It looks a lot like they ended up back at a solution that looks like package.json with npm.

• by m_sahaf on 7/29/24, 9:56 PM

  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 :)

• by xmonkee on 7/29/24, 5:57 PM

  We are using deno to allow our customers to run custom code with imports. This is only made possible with http imports and I for one am very happy it exists.

• by pjmlp on 7/29/24, 4:41 PM

  And yet again some folks rediscover why network based imports isn't something that works beyond toy examples.

  What about reading about what we were doing in distributed computing during the last century?