[HN Gopher] An Introduction to Deno: Is It Better Than Node.js?
___________________________________________________________________
An Introduction to Deno: Is It Better Than Node.js?
Author : kiyanwang
Score : 33 points
Date : 2022-02-11 21:47 UTC (1 hours ago)
(HTM) web link (blog.appsignal.com)
(TXT) w3m dump (blog.appsignal.com)
| beardedetim wrote:
| I have a strong feeling that deno will be the io of our age:
| important for pushing node forward and ultimately be brought into
| node proper but not worth investing any apps/projects onto.
| eyelidlessness wrote:
| I find it highly unlikely that Node will ever choose to support
| TypeScript out of the box. I'd love to be wrong, but it would
| be a sharp departure from their "bring your own" approach (eg
| with --loader/--require, the former being under active
| development).
| ignoramous wrote:
| Even more unlikely is Deno "merging" in to Node. Deno is
| sponsored by the Deno Company, and even at this nascent
| stage, it is a whole ecosystem unto itself (package manager,
| linter, bundler, transpiler, development tools, ide
| integrations, edge platform and so on).
| The_rationalist wrote:
| this is a moot point as ts-node exist. What's lacking is
| native esmodule support.
| Master_Odin wrote:
| Native esmodule loading has been a thing since node 12,
| almost 3 years ago. You just have to turn on a flag or use
| the `.mjs` file extension.
| devmunchies wrote:
| I see Deno as being better for scripts since you don't need
| extra dependencies or build pipelines to use typescript, and
| you likely don't need many dependencies anyway for small
| scripts. Node.js seems better for services since it has bigger
| ecosystem.
| throwawayboise wrote:
| There's always something better. Get off the treadmill. Become an
| expert in what you know.
| ignoramous wrote:
| Deno is, in essence, a javascript runtime. Unless one wants to
| contribute to Deno core, they don't have to be an expert in any
| _new_ thing?
| anderspitman wrote:
| I've mostly switched to Go for new projects, but if that weren't
| the case I suspect I'd be using Deno a lot. The biggest downside
| I can see is the lack of packages, and I normally avoid
| dependencies like the plague so that doesn't really bother me.
| I'd guess any useful enough to justify their existence will be
| ported soon.
| tinalumfoil wrote:
| I've found these differences make it tough to use Deno on large
| or important projects. Deno does a lot of novel things. On the
| surface they're all things I agree with, but in practice they're
| too novel to understand the implications of.
|
| For instance, bundling typescript. I like typescript and hate
| setting up the build toolchain so this sounds like a good idea.
| _But_ not every typescript upgrade is backwards compatible (even
| if unintentional when not), and I 'd hate to be stuck not
| upgrading V8 because it's bundled with typescript.
|
| Or the import system. Importing from HTTP is useful, it ensures
| things "just work". I like it, on first sight. But is it
| manageable? Let's say I isolate all my external dependencies into
| files that just re-export them, or whatever the standard is
| nowadays. Is the tooling there for when I need to upgrade? How do
| I deal with sub-dependencies using different versions of things?
| How do I keep versions compatible? Will something break if I
| depend on Xv1.1 and Yv1.2 and X uses Yv1.3? Can I force X to use
| Yv1.2? I can see a world where these things are solved, but it's
| a vague image.
|
| Or the permissions. Why does my text processing app need to
| access the web? Again, seems like a good idea. But now the
| behavior of your standard library is tied to cli options. Phone
| apps make this work, but they _request_ permissions, you don 't
| explicitly say, "Open Maps with internet access". Ideally I'd
| like my code not to behave too differently just because it's in a
| different environment. I want to believe, I see a world where
| this all comes together smoothly, but it's tough to trust right
| now.
| searchableguy wrote:
| > Or the permissions. Why does my text processing app need to
| access the web? Again, seems like a good idea. But now the
| behavior of your standard library is tied to cli options. Phone
| apps make this work, but they request permissions, you don't
| explicitly say, "Open Maps with internet access". Ideally I'd
| like my code not to behave too differently just because it's in
| a different environment. I want to believe, I see a world where
| this all comes together smoothly, but it's tough to trust right
| now.
|
| If I'm understanding you correctly, you don't want to run the
| code with correct flags and instead, have deno figure it out
| like a browser where it prompts the user to ask if they would
| like to give a certain permission.
|
| If yes, that is already the case with deno. You can pass
| --prompt flag.
| tinalumfoil wrote:
| Not quite. Prompting works in a user applications but let's
| say I launch my app from a systemd service so there's nobody
| to respond to those prompts.
|
| It's not that I don't _want_ to run it with the correct
| flags. I do want that. Things is, if I run it with too few
| flags the program breaks. Hopefully in a way where it 's
| obvious what happened! If I run it with too many, I lose the
| security benefit Deno gives.
|
| But the last thing I want is my whole service to fail because
| I forgot to add that one darned cli flag to my service file!
|
| And, I admit, maybe this is a non-issue. Maybe I can just
| check I'm in the right environment at program start. But it's
| one of those things where I don't feel like I fully grasp the
| implications.
| jonny_eh wrote:
| It's definitely a new failure scenario we need to worry
| about.
| hitekker wrote:
| It sounds like you haven't used Deno in a large project before.
| Which is weird because you're started by saying "in practice"
| or "I've found", but later switched to abstract "what if's".
| develatio wrote:
| Importing from HTTP is a bad idea on so many different levels
| and for so many different reasons (security, immutability, sec
| compliance, project integrity... the list just goes on and on).
| We've been there (PHP remote includes) and it's as bad as it
| can get.
|
| Please don't say HTTP imports are a good idea. Please.
| nkozyra wrote:
| I think you're maybe confusing what's effectively a namespace
| and point in time install with a dynamic import.
|
| Otherwise there's no difference between http "imports" and
| any dependency management system (which ultimately import
| from some http endpoint)
| develatio wrote:
| If we're talking about
| https://deno.land/manual/linking_to_external_code , then I
| stand to what I said.
| nkozyra wrote:
| But again - and this is mentioned in the page, nothing
| here is unique to Deno. It semantically feels different,
| but is in practice no different than most dependency
| management systems.
| nicoburns wrote:
| Regarding TypeScript toolchains: esbuild and node make a dream
| combination. The configuration comes down to 3-4 command line
| parameters, and it's fast enough that you don't need to use any
| kind of incremental compilation mode. You can just recompile
| the world before restarting node each time. It's under 0.1 of a
| second for our projects at work! (and that's on a fairly slow
| machine where the node process startup time itself can be a few
| seconds when under load)
| brundolf wrote:
| For the versioning thing: each of those would presumably pull
| from a different url, so they'd be fully independent. That
| might result in redundant downloads, but that should be fine,
| because we're not talking about the front-end. Deno has no
| knowledge of versions, just urls.
|
| The permissions model may have been a mistake. In my own
| projects I find myself just doing ---allow-all constantly. I
| could see it being useful for a hardened production server that
| eg. should only have access to the network, but I think
| permission-denial may have been better than permission-
| granting. Maybe they'll change the CLI around this at some
| point.
___________________________________________________________________
(page generated 2022-02-11 23:00 UTC)