5 ms·

Have folks been using Deno? What are the sharp edges?

Ciantic 5y ago
Sharpest edge to me is that it's not quiet TypeScript. This means that you can't write a TypeScript file that works in both Deno and regular TypeScript (if you use any imports). Because of the issue that in TypeScript you can't import ".ts" file but you can import ".js" file, whereas in Deno you explicitely import ".ts" files. [1] I actually like writing with Deno, and think the module resolution in Deno is easier to understand (it's literally url or explictely what's written on the import). But it's just sad that the TS team is not moving the same direction with the module resoultion, because it splits the TS community to those who write Deno and those who write regular TS. [1]: https://github.com/microsoft/TypeScript/issues/27481 https://github.com/microsoft/TypeScript/issues/27481
- kbenson 5y ago
  > Because of the issue that in TypeScript you can't import ".ts" file but you can import ".js" file That seems really annoying and is something I would expect to work. From the linked issue, does the problem go away if you make sure to always just import without the extension, and does it work both directions (deno TS->TS on JS and TS on JS->deno TS)?
  - davnicwil 5y ago
    No, deno mandates the extension. The no extension shortcut as well as the index file shortcut have not been included in deno as a learning from node, which in my view is probably a wise move - keep it super simple by just specifying the exact filename.
    - eins1234 5y ago
      Exactly this. Deno is designed to align with web module semantics, and omitting the extension is only really feasible when resolving modules on disk where roundtrip times are short and looking for multiple extensions in parallel is cheap. Deno, as well as the web, supports module resolution across the internet, where this resolution strategy would become prohibitively expensive.
    - kybernetikos 5y ago
      Deno's position is much more sensible than the typescript teams position, but not working with the rest of the TS ecosystem is a huge price to pay. I hope that either Deno implements some 'legacy' way of working that is compatible with the way the official typescript team do it, or the typescript team realize the error of their ways. I'm not sure if that's likely to happen short of a fork though.
- rictic 5y ago
  In fairness to the TypeScript team, their position on this subject has been consistent for a very long time, since well before Deno. They do not see themselves as being in the business of rewriting import specifiers because there's just too many things that different groups would want them to do. I'd also like them to support importing .ts files and rewriting those imports to .js, but given that they've been clear about their position I think it's up to Deno to solve this without forking the ecosystem.
- mikewhy 5y ago
  The typescript team has some weird hangups around import paths that bring up issues. I wasn't aware of this Deno issue, but there's a similar one with ESM modules: TS wants you to import "somefile.js" when you actually want "somefile.ts". It's completely non-obvious, and breaks anything that checks if the file to be imported exists on disk.
  - kybernetikos 5y ago
    Yeah, I find this issue very irritating. Forcing you to claim you're importing a file that doesn't even exist except as part of the output of a build step means that you're tying your implementation of a language to a specific set of tooling and environment. It's treating a language like it's a dumb file rewriter rather than something semantically meaningful. It would have made no sense for Deno to do the same thing - if you import a .js file from a remote server, you want that js file, if it doesn't exist automatically trying to load a .ts file from the same location would be pretty odd behaviour. Typescript is a language, the tools should understand it as a language and it should be self-consistent. The other thing that irritates me is that all that typing information is lost at runtime, when it could be very useful in a bunch of situations, but hey, you can't have everything.
    - spiderice 5y ago
      In theory, even though this would probably never actually happen, could a browser add Deno to its build and use it to execute Typescript directly without having to rely on Javascript? Seems like a cool way to eventually get rid of the "baggage" that requires Typescript to not have Types at runtime and that sort of thing. edit: And I realize that Deno currently doesn't maintain your types during runtime either, but in theory that would be fixable since it doesn't have to rely on Javascript.
      - harikb 5y ago
        Deno doesn’t execute TS directly - internally it is still JS executed by v8. Having v8 support direct TS will be a huge effort
    - 5y ago
- ctoth 5y ago
  I am working on a new project where Deno would have been quite nice and this is exactly what prevented me from using it.
pfraze 5y ago
I'm a long-time Node user and gave Deno a pretty close look recently. There's a ton to like, but the ecosystem of nodejs modules is hard to overcome, and I spent a lot of time fighting with the subtle differences between them instead of getting things done, whether it was me learning new patterns, having to search for good modules to solve a problem, or having to transpile node modules to deno. That had me in a bad place, but then the sandboxing (which was uniquely suited for my usecase) had a design challenge that blew up the fit for what I was doing. At that point, I gave up on it. Given what they're doing with Deno Deploy, I almost wonder if the future of Deno is being a vendor-independent version of Cloudflare Workers.
eins1234 5y ago
Sharpest edge I've encountered is the very much WIP WebCrypto API support. In practical terms, this means things like signing/verifying JWTs is not very well supported: https://github.com/panva/jose/discussions/243 https://github.com/panva/jose/discussions/243 That said, the situation is improving rapidly, and I've been personally willing to bet that the support will be solid by the time I finish prototyping and need to start adding auth to my latest project.
ypcx 5y ago
There's a few: https://github.com/denoland/deno/issues?q=is%3Aissue+is%3Aopen+label%3Abug https://github.com/denoland/deno/issues?q=is%3Aissue+is%3Aop...
ypcx 5y ago
Here's a gotcha for you: https://github.com/denoland/deno/issues/4568 https://github.com/denoland/deno/issues/4568

Sharpest edge to me is that it's not quiet TypeScript. This means that you can't write a TypeScript file that works in both Deno and regular TypeScript (if you use any imports). Because of the issue that in TypeScript you can't import ".ts" file but you can import ".js" file, whereas in Deno you explicitely import ".ts" files. [1] I actually like writing with Deno, and think the module resolution in Deno is easier to understand (it's literally url or explictely what's written on the import). But it's just sad that the TS team is not moving the same direction with the module resoultion, because it splits the TS community to those who write Deno and those who write regular TS. [1]: https://github.com/microsoft/TypeScript/issues/27481 https://github.com/microsoft/TypeScript/issues/27481

kbenson 5y ago
> Because of the issue that in TypeScript you can't import ".ts" file but you can import ".js" file That seems really annoying and is something I would expect to work. From the linked issue, does the problem go away if you make sure to always just import without the extension, and does it work both directions (deno TS->TS on JS and TS on JS->deno TS)?
- davnicwil 5y ago
  No, deno mandates the extension. The no extension shortcut as well as the index file shortcut have not been included in deno as a learning from node, which in my view is probably a wise move - keep it super simple by just specifying the exact filename.
  - eins1234 5y ago
    Exactly this. Deno is designed to align with web module semantics, and omitting the extension is only really feasible when resolving modules on disk where roundtrip times are short and looking for multiple extensions in parallel is cheap. Deno, as well as the web, supports module resolution across the internet, where this resolution strategy would become prohibitively expensive.
  - kybernetikos 5y ago
    Deno's position is much more sensible than the typescript teams position, but not working with the rest of the TS ecosystem is a huge price to pay. I hope that either Deno implements some 'legacy' way of working that is compatible with the way the official typescript team do it, or the typescript team realize the error of their ways. I'm not sure if that's likely to happen short of a fork though.
rictic 5y ago
In fairness to the TypeScript team, their position on this subject has been consistent for a very long time, since well before Deno. They do not see themselves as being in the business of rewriting import specifiers because there's just too many things that different groups would want them to do. I'd also like them to support importing .ts files and rewriting those imports to .js, but given that they've been clear about their position I think it's up to Deno to solve this without forking the ecosystem.
mikewhy 5y ago
The typescript team has some weird hangups around import paths that bring up issues. I wasn't aware of this Deno issue, but there's a similar one with ESM modules: TS wants you to import "somefile.js" when you actually want "somefile.ts". It's completely non-obvious, and breaks anything that checks if the file to be imported exists on disk.
- kybernetikos 5y ago
  Yeah, I find this issue very irritating. Forcing you to claim you're importing a file that doesn't even exist except as part of the output of a build step means that you're tying your implementation of a language to a specific set of tooling and environment. It's treating a language like it's a dumb file rewriter rather than something semantically meaningful. It would have made no sense for Deno to do the same thing - if you import a .js file from a remote server, you want that js file, if it doesn't exist automatically trying to load a .ts file from the same location would be pretty odd behaviour. Typescript is a language, the tools should understand it as a language and it should be self-consistent. The other thing that irritates me is that all that typing information is lost at runtime, when it could be very useful in a bunch of situations, but hey, you can't have everything.
  - spiderice 5y ago
    In theory, even though this would probably never actually happen, could a browser add Deno to its build and use it to execute Typescript directly without having to rely on Javascript? Seems like a cool way to eventually get rid of the "baggage" that requires Typescript to not have Types at runtime and that sort of thing. edit: And I realize that Deno currently doesn't maintain your types during runtime either, but in theory that would be fixable since it doesn't have to rely on Javascript.
    - harikb 5y ago
      Deno doesn’t execute TS directly - internally it is still JS executed by v8. Having v8 support direct TS will be a huge effort
  - 5y ago
ctoth 5y ago
I am working on a new project where Deno would have been quite nice and this is exactly what prevented me from using it.

pfraze 5y ago

I'm a long-time Node user and gave Deno a pretty close look recently. There's a ton to like, but the ecosystem of nodejs modules is hard to overcome, and I spent a lot of time fighting with the subtle differences between them instead of getting things done, whether it was me learning new patterns, having to search for good modules to solve a problem, or having to transpile node modules to deno. That had me in a bad place, but then the sandboxing (which was uniquely suited for my usecase) had a design challenge that blew up the fit for what I was doing. At that point, I gave up on it. Given what they're doing with Deno Deploy, I almost wonder if the future of Deno is being a vendor-independent version of Cloudflare Workers.

eins1234 5y ago

Sharpest edge I've encountered is the very much WIP WebCrypto API support. In practical terms, this means things like signing/verifying JWTs is not very well supported: https://github.com/panva/jose/discussions/243 https://github.com/panva/jose/discussions/243 That said, the situation is improving rapidly, and I've been personally willing to bet that the support will be solid by the time I finish prototyping and need to start adding auth to my latest project.

ypcx 5y ago

There's a few: https://github.com/denoland/deno/issues?q=is%3Aissue+is%3Aopen+label%3Abug https://github.com/denoland/deno/issues?q=is%3Aissue+is%3Aop...

ypcx 5y ago

Here's a gotcha for you: https://github.com/denoland/deno/issues/4568 https://github.com/denoland/deno/issues/4568