
From Node to Deno - aralroca
https://dev.to/aralroca/from-node-to-deno-5gpn
======
ljackman
It looks like a good evolutionary improvement over Node.js. However, I have a
concern about its security claims. Perhaps someone on the project can allay
these concerns.

My brief skimming of its site indicates that its security model is based
around the ability to disable, say, network access for whole Deno programs.
However, does it allow starting up with network access, allowing a subset of
the program to handle it, and then dropping those rights for the rest of the
program, _especially_ subdependencies?

I can't see any mention of a more fine-grained approach:
[https://deno.land/manual/getting_started/permissions](https://deno.land/manual/getting_started/permissions)

A modern Node.js web service will have hundreds, if not thousands, of indirect
dependencies. Some network access will be required for at least the Express
routing, or an equivalent.

For a Deno equivalent, this would amount to enabling network access for all
hundreds of those subdependencies, not reproducing the isolation in
capability-based security such as WebAssembly nanoprocesses.

Have I missed something here? That doesn't seem like much of an improvement
over Node.js except for very small and contained programs. Yes, Deno's
dropping of centralised package repositories and package.json might alleviate
this problem _somewhat_, but the same fundamental issue seems to remain.

~~~
sramam
Permissions are a whitelist.

While the grant is a blanket grant to a program and all dependencies,
typically, a well behaved program will seek a limited scope of permissions.
Like "[https://my-program.com"](https://my-program.com"), "[https://preferred-
analytics.com"](https://preferred-analytics.com") etc.

This prevents dependencies from using call back locations that are outside the
permitted list, preventing much of the nefarious activity they can dream up.

If a dependency needs access to specific resources, it can advertise this fact
and the parent module can in turn request this from the user.

Importantly, the user is explicitly aware of these & controls it in an
absolute sense, at run time.

~~~
hn_throwaway_99
> Importantly, the user is explicitly aware of these & controls it in an
> absolute sense, at run time.

I mean, I guess I see value there for the use case of "I want to download a
script to run locally on my machine" type of thing, but for the most common
use of Node, i.e. I'm running a server process, does this really even matter?

~~~
zamadatix
I think the most common use of Node might actually be Electron if you go by
number of users.

------
hn_throwaway_99
I'm really curious about whether people think Deno will succeed. Node
certainly has its warts, but I feel like with recent improvements in the JS
language and Typescript that Deno doesn't really solve problems people have
nowadays. I don't think the decoupling from NPM and the dependency management
approach (or lack thereof) is really a thing that most developers want. NPM
certainly had a bunch of "dumpster fires" for years IMO (lock files mess,
signed code mess, etc.) but I feel most of those pain points have largely been
addressed.

I downloaded Deno and tried it out, but at this point I'm just left thinking
it doesn't really add anything for me that I need.

~~~
xkapastel
This is puzzling to me because I had the opposite reaction: among other
things, Deno solves an incredibly important problem with Node, which is the
complicated configuration used with most projects. Deno can perform, out of
the box, many of the things you'd need to configure Webpack + Typescript to
do:

    
    
        SUBCOMMANDS:                                                      
            bundle         Bundle module and dependencies into single file                         
            cache          Cache the dependencies                                                  
            completions    Generate shell completions     
            doc            Show documentation for a module                                         
            eval           Eval script                       
            fmt            Format source files                                       
            help           Prints this message or the help of the given subcommand(s)
            info           Show info about cache or info related to source file
            install        Install script as an executable
            repl           Read Eval Print Loop
            run            Run a program given a filename or url to the module
            test           Run tests
            types          Print runtime TypeScript declarations
            upgrade        Upgrade deno executable to given version
    

What would it take to get Node to do all of that? Which documentation tool
would you choose, and how would you configure it? Testing? Bundling?
Formatting?

~~~
harikb
If anyone remembers, this is similar to the “Turbo Gears” vs “Django” of
Python world. Turbo Gears allowed me to choose the best of each component -
but pretty soon one ends up having to upgrade or migrate to the new-best-sub-
component on a weeekly/monthly basis. django helped avoided a lot of headache
by defaulting a decent, but not necessarily the best tool, and sort of “won”
in the end.

For some reason, we continue to replay this fight in each and every language
and environment.

~~~
vipshek
This strikes me a similar to a dynamic at the level of entire corporations and
industries—commodification/modularization on one end, wholeness/integration on
the other: [https://stratechery.com/2015/netflix-and-the-conservation-
of...](https://stratechery.com/2015/netflix-and-the-conservation-of-
attractive-profits/)

------
truth_seeker
Few things comes to my mind if you are moving from NodeJS to Deno:

1\. Deno lacks the library eco system which is required to build a production
level app today. I am not saying it cant be done. Just think of the different
third party service integration modern application has to do, their
maintainance and testing by individual vendors or open source contributors !
Blogs mentions few DB driver libraries, i highly doubt they are as mature.

2\. Deno's security model overly hyped at least i see it this way. In last few
version of NodeJS, many security flaws have been addressed, see their
changelog if you dont believe me. But most importantly, security flaws with
native JS is handled by V8 which is common to both NodeJS and Deno. On top of
that, most of the libraries and frameworks in NodeJS during their various
releases sorted out many security issues in their code. If someone is still
doubtful they can use eslint-plugins for sanity and security checks in their
JS files. Adopting Typescript also helps if you cant live without types.

3\. Learning curve to adopt new SDK for Socket API, File API, System call API
etc. I don't think NodeJS falls short significantly anywhere, in fact it
provides more and those APIs have been relatively more battle tested over the
years.

4\. Irrespective of using NodeJS or Deno, following a BDD/TDD practices to
ensure sound test coverage of your business use logic still remain the most
promising tool to make, break and refactor your codebase.

~~~
thosakwe
Solely addressing #1 here, and this may come off harsh, but I think it's
ridiculous to expect Deno to match the library ecosystem of Node on day 1.
That's just literally impossible, but whenever a new language or runtime is
released, it manages to become the most prominent question/concern.

It also is something of a moot point anyways, because people pushing something
into production already are probably not using something so new. Early
adopters don't care about how mature the ecosystem is; part of the appeal of
being an early adopter is helping to build that ecosystem...

~~~
tosserup478
Well, you should scratch language there. kotlin did manage to start with the
huge ecosystem of Java without hassle

------
ralusek
Thanks for doing this. I have a few questions regarding packages/dependencies,
and TypeScript in general.

I tried installing Deno, and I tried including a package, and immediately the
TypeScript typechecking in my IDE (VSCode) failed, of course. The IDE doesn't
know what to do with a URL as a dependency. Is this something Deno will be
able to handle?

The next question is that TypeScript packages I have written in the past use
`baseUrl` and `paths` in their own configs to allow for absolute import paths.
When I look at third-party Deno repositories, I didn't see any that were
building out to JS/declaration files, and were instead just meant to be
included as the original TypeScript source code. Won't this break things like
absolute import paths and other behaviors of the dependency's own tsconfig
file, or does this work fine with Deno/TS?

~~~
brlewis
[https://stackoverflow.com/questions/54794933/how-to-pull-
typ...](https://stackoverflow.com/questions/54794933/how-to-pull-typings-in-
deno)

Looks like there's a plug-in. Can't research much now, but I hope there's
something like that for emacs tide.

~~~
brlewis
I think for emacs/tide I'll just be able to follow the instructions for Atom
here: [https://github.com/justjavac/typescript-deno-
plugin](https://github.com/justjavac/typescript-deno-plugin)

------
dang
The other major threads so far:

[https://news.ycombinator.com/item?id=23172483](https://news.ycombinator.com/item?id=23172483)

[https://news.ycombinator.com/item?id=23093737](https://news.ycombinator.com/item?id=23093737)

[https://news.ycombinator.com/item?id=22102656](https://news.ycombinator.com/item?id=22102656)

[https://news.ycombinator.com/item?id=20373430](https://news.ycombinator.com/item?id=20373430)

[https://news.ycombinator.com/item?id=17183241](https://news.ycombinator.com/item?id=17183241)

Let me know if I've missed any.

------
DrFell
Using JavaScript outside a browser by running the V8 JavaScript browser engine
on the server is a bit of a gimmick, but enough people can't bother to be a
polyglot, and it's not that crazy.

But, once you are writing code in TS, then transpiling that to JS, then
running that in V8 on a server, you have taken a big step into the Rube
Goldberg dimension.

------
k__
Desktop apps build on Electron should be a good fit for Deno, because Denos
API is more like a Browser API than like the Node API.

~~~
tuukkah
Is there a decent browser (or other GUI framework) in Deno though? It has a
wrapper for zserge/webview but I haven't used a webview in ages.

------
milutinovici
The one big thing missing is an ORM. And making those things is notoriously
difficult. Hopefully something will turn up

~~~
hn_throwaway_99
The idea that ORMs are a net-positive is definitely an open question. After
20+ years I'm certainly of the opinion they're not. I recently discovered
Slonik (only for postgres, hope there is eventually a port for MySQL and
others) and I'm a huge fan of the overall approach and the API. This blog post
from the creator explains: [https://medium.com/@gajus/stop-using-knex-js-and-
earn-30-bf4...](https://medium.com/@gajus/stop-using-knex-js-and-
earn-30-bf410349856c)

~~~
seanwilson
> The idea that ORMs are a net-positive is definitely an open question.

If it's still being debated, isn't that a good indication that there's no
perfect solution for every use case?

ORMs are likely more straightforward when you know you're not going to need to
do anything advanced, but get in the way when you need fine grained control
for example.

~~~
thinkloop
The problem is that easy queries are easy, who cares about orm, and hard ones
are too hard for orm. I haven't been able to see the benefits in either easy
or hard projects.

~~~
jdxcode
you nailed it: In simple cases the abstraction doesn't help enough to justify
including it and in complex ones it actually makes things much more
complicated because it just doesn't work right.

Ultimately it's useless for both.

------
dzonga
and the great migration begins. but when you look at other backend ecosystems
e.g php, ruby on rails they're still getting shit done. even though people
might say those languages/frameworks might be slow or insecure. stability is
what's lacking in the JS ecosystem. glad I do my backends in flask now

~~~
Roboprog
Maybe it would be OK if all the Typescript people went Away to Deno and the
few of us left who just want to run plain JS on Node, could, in peace.

... As long as there is enough interest still in Node to maintain it.
Hopefully, there is still interest in running the same language as browsers
do, without additional dependencies.

Personally, I would prefer Clojurescript to TS, but not strongly enough to
want to be tied to its fate.

------
thelazydogsback
What Node is missing due to it's design is parallel (not just async-on-a-
single-thread) processing using either green or OS threads without the
overhead of serialization to web-workers or a cluster. Last time I checked,
Deno didn't have a story there.

