Deno 1.26 Release Notes(deno.com) |
Deno 1.26 Release Notes(deno.com) |
I've been playing with deno lately, and like it, but have been getting tripped up by some things.
I wish the standard library weren't at URLs like all the other packages. It would be great if the `deno` tool you downloaded also included the standard library, and you could just reference it without any network stuff. The documentation is also pretty cryptic (and I think autogenerated?).
The package management stuff I haven't quite wrapped my head around. Obviously, you shouldn't be downloading stuff willy-nilly, but I think with some combination of the conventional deps.ts, import_map, specifying a lock file, the vendor command, --no-remote, etc, I feel like I have all the pieces to kind of build up a reasonable approach, but I don't quite understand it all just yet.
Personally, the `--allow-read`, `--allow-net`, etc stuff feels a little gimmicky to me. I don't think other languages really have that, and I'm not sure what the threat model is here. I control the backend code, and if I'm worried about my code doing unexpected things like that I have larger issues. I just run with `-A` all the time.
Also, I'm looking forward to the idea of running a host like Deno, with applications inside that other people wrote. Kind of like sandstorm.io. I may be naive, but I'm hoping this happens really, really soon.
It is also possible in Deno to set permissions for Workers but that's not just plug and play for existing libraries.
But this also gets at my "you have larger issues" comment. How is library code going to just start talking to a server? I like to review and audit all my dependencies and their changes, so it shouldn't just randomly happen. That's my whole problem with npm and its million dependencies and why I'm glad deno provides a standard library in the first place.
You wrote an app that prints a quote in fancy fonts and colors in the terminal. Your code uses a library to format the text. The library attempts to read and/or write files that might contain secrets, then makes a network connection to an external address.
Contrived and silly example, but I think it illustrates the premise well.
I'd generally like to see more languages with APIs for untrusted sections. If I know my program reads e.g. paths from untrusted files but should only ever access it's own folder, it would be nice to have a way to ensure that I can't get tricked into accessing something outside of it.
Anyone got experience with switching from Node.js to Deno?
What's better with Deno? What's still worse?
The answer is here: https://github.com/denoland/deno/blob/716005a0d4afd1042fa75d...
So
- value of `deno run --location=`
- value of `deno run --config=`, also automatic probing
- path to main script file, or for `deno eval`, current directory
Just show before and after bars...
What are the advantages and disadvantages of each? When would one be better than the other?
Or am I wrong, and they're not competing as much as they seem?
ts-node is good enough to stick to Node for now if you want TypeScript. I don't think the rest of Deno is that compelling, although I would probably switch to Deno once its Node compat is awesome since it is a more compelete package out of the box than Node is.
Deno's battle is that it is an incremental improvement, and competing JS runtimes is quickly become the new JS web framework meme alternative (Bun, Boa, Node, Deno)
Matters for what ? Doing every type of app ? Yeah, that's blocker.
But it doesn't really matter. Every language ecosystem that succeeds starts off lacking things.
Personally I prefer starting with it early and be part of that ecosystem.
I use ts-node with the optional SWC compiler which works great with pretty darn fast startup times. SWC can handle TypeScript experimental decorators including emitting metadata, so not losing out on anything with it ATM.
#! /usr/bin/env node -r @swc-node/register
How come?
Better: Seamless TypeScript support without having to deal with 3rd party packages or tsconfigs. A standard library modeled after Go's that is a WIP, but solid overall. Having browser APIs in the runtime is great, removes the mental context switch between browser/node. Formatter built in to the binary. YMMV, but I prefer the url imports and lack of package.json.
I can't speak from a professional standpoint of migrating a project from Node to Deno; honestly, I don't think it's worth doing that (yet). But Deno is far more enjoyable to me as a hobbyist programmer and working on solo projects. I recently deployed an app backend using just the std and the Deno port of postgres.js[0] to Deno Deploy and it was a breeze.
I also think it's a great starting point for anyone looking to learn JavaScript.
Scripting, tooling/IDE support (webstorm support is pretty good), documentation and standardization, infrastructure as code
> What's still worse?
Node/NPM compatibility is still hit or miss depending on the library you're trying to use, that's something Bun is trying to improve over Deno.
Also, typescript types feel very hacky and I feel that's something very important as one of Deno's biggest selling points is typescript first-class support, definitely typed is doing most of the heavy lifting but things aren't perfect.
Node/NPM compatibility is experimental, as it improves, this lack of Deno native packages should become less of an issue.
1. Standard library: Deno has so much better standard library, support for web standards, promises instead of callback, and need to reach out to third party modules lot less
2. Performance: Deno is focusing a lot on performance and it faster than node
3. Package management: No more gigabytes of node_modules, They just have URLs which are simpler to use
4. Versioned std library:node's standard library is packaged but for deno you can use different std library than deno version.
Whats worse:
1. Ecosystem: There are lot less packages for deno but Deno team is working on npm packages support. So all/most npm packages will work in deno
2. Deployment target: Deno has deno deploy but that pretty much it.
I'm doing regular HTTP stuff, so haven't been suffering with lack of libraries. Most things work just fine.
I'd love to see a permissions system on a library basis. It would ask the first time a dependency is added and when a new permission is requested after an update. Javascript doesn't make that easy though by being so dynamic. SES could maybe help: https://github.com/endojs/endo/blob/master/packages/ses/READ...