[HN Gopher] Deno 1.26 Release Notes
___________________________________________________________________
Deno 1.26 Release Notes
Author : exists
Score : 99 points
Date : 2022-09-29 14:02 UTC (9 hours ago)
(HTM) web link (deno.com)
(TXT) w3m dump (deno.com)
| wener wrote:
| Deno looks good, but don't support musl, I'm not the target
| audience.
| edave64 wrote:
| Using bar graphs just showing the factor of improvement is kinda
| baffling. It took me a bit to understand how to read it, which is
| the last thing you want in a diagram.
|
| Just show before and after bars...
| losvedir wrote:
| Deno is pretty neat. I really want it to succeed. I really like
| TypeScript, and Deno almost gives me what I want: pretending
| TypeScript is a full-fledged language, with a standard library,
| that I can build non-frontend apps with. Let's just sweep all
| that JS-heritage and V8 stuff under the rug...
|
| 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.
| koprulusector wrote:
| Regarding security:
|
| 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.
| edave64 wrote:
| Have you ever executed a script you didn't write? It's handy to
| have a runtime where you can see what a script can do from its
| permissions.
|
| 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.
| losvedir wrote:
| Actually, the use case of running other people's scripts is
| pretty neat. I audit pretty closely the code I use in my
| projects for work (the use case I was thinking of), but
| having Deno as a scripting platform, and running a script
| someone shared is a pretty neat place to apply the
| network/disk limits.
| croes wrote:
| Nothing learned from node-ipc?
| VikingCoder wrote:
| To the last point - imagine that you're using some library
| code, and you do an update, and now it starts trying to talk to
| some back-end server. That might be a good thing to stop.
|
| 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.
| losvedir wrote:
| Sure, I suppose if you granted it at the library level that
| might be good, but it's at the whole app level. You could
| maintain a very fine grained list of network URLs, though.
| That might be nice if you could configure in the
| `deno.config` file, rather than having to specify them all on
| the command line.
|
| 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.
| eis wrote:
| The problem is that you grant the privileges on the
| application level and not library level. You grant network
| access to your app and then some updated dependency suddenly
| starts communicating home and it wont prevent that.
|
| It is also possible in Deno to set permissions for Workers
| but that's not just plug and play for existing libraries.
| Hovertruck wrote:
| I suppose that depends on if you're blanket-allowing
| network, though. You could pass an allow list of ips/hosts
| that are allowed, though that's not going to be feasible
| for every application: https://deno.land/manual@v1.26.0/get
| ting_started/permissions...
| eis wrote:
| Yea you could restrict the app by whitelisting only the
| network services and folders that it will use and that's
| pretty valuable though at least on Linux could already
| easily be achieved otherwise. It's good that Deno makes
| it easy but let's be honest, most people will just pass
| -A.
|
| 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...
| johannes1234321 wrote:
| On a library level won't be easy, as there will be
| wrapper libraries of some kind (axiom-style or whatever)
| and those wrapper lib will get the permission, so you'd
| then need a mechanism to prevent somebody calling into
| that library directly ... and not indirectly (say telling
| a third module to use the http-wrapper as a callback for
| some other thing) it is a rabbit hole
| laurencerowe wrote:
| Workers are the solution here since they provide a security
| boundary. Access to the outside world must then be
| intermediated by your app. You might provide a version of
| fetch inside the worker that works through postMessage or
| SharedArrayBuffer allowing your app to filter the requests
| made by the untrusted script inside the worker.
| VikingCoder wrote:
| The other day, Workerd was featured, and here's Deno.
|
| 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?
| atonse wrote:
| They all have Function-as-a-service offerings and have pledged
| to work together on a common standard/compatibility layer so
| your code can port easily.
| k__ wrote:
| Half-OT:
|
| Anyone got experience with switching from Node.js to Deno?
|
| What's better with Deno? What's still worse?
| frou_dh wrote:
| Deno is very nice for writing a script that uses a dependency,
| without the ceremony of setting up or generating a
| pseudo-"project". One file with your code in it.
| lucasyvas wrote:
| Ecosystem is still worse, which is IMO all that matters at this
| point.
|
| 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)
| mirekrusin wrote:
| #! /usr/bin/env node -r @swc-node/register
|
| ...shebang is better than ts-node
| k__ wrote:
| _" it is a more compelete package out of the box than Node"_
|
| How come?
| lucasyvas wrote:
| Deno fmt, testing, capabilities, standalone binaries,
| built-in TS. Just a bit more modern and nice and saves a
| lot of setup you'd have to do with Node.
| Rapzid wrote:
| ts-node is great. Proper ESM support landed over the summer.
| All my new projects at work are module type now.
|
| 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.
| labarilem wrote:
| +1 for the SWC compiler, been using it for some time and I
| love it.
| simlevesque wrote:
| > Ecosystem is still worse, which is IMO all that matters at
| this point.
|
| 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.
| nicoburns wrote:
| I think esbuild is simpler than ts-node. We simply compile
| everything from TS to JS with esbuild every time we launch
| node (it takes less than 0.1 seconds)
| keb_ wrote:
| See: https://github.com/lukeed/tsm which is built on
| esbuild.
| lucasyvas wrote:
| It very well could be - I suppose that's more evidence to
| the point that working with Node is very doable these days
| even without built-in support for many tools.
| themerone wrote:
| I haven't switched yet, but I would say everything is better
| except package availability. For example, there is no package
| to connect to an SQL Server database.
|
| Node/NPM compatibility is experimental, as it improves, this
| lack of Deno native packages should become less of an issue.
| mirekrusin wrote:
| When they say npm compatiblity, they mean non-native npms -
| native npms will never be supported.
| dsherret wrote:
| Node API will be supported sometime soon
| https://github.com/denoland/deno/pull/13633
| mirekrusin wrote:
| Thanks, I stand corrected, one ambitious pr!
| Mikeb85 wrote:
| Everything is better except the amount of packages available
| for it.
| keb_ wrote:
| Worse: Ecosystem
|
| 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.
|
| [0] https://github.com/porsager/postgres
| lucis wrote:
| Deno Deploy[1] is amazing, the deploy time is unbelievably
| fast.
|
| I'm doing regular HTTP stuff, so haven't been suffering with
| lack of libraries. Most things work just fine.
|
| https://deno.com/deploy
| akmittal wrote:
| Whats better:
|
| 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.
| nyadesu wrote:
| > What's better with Deno?
|
| 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.
___________________________________________________________________
(page generated 2022-09-29 23:02 UTC)