
Deno 1.0 - theBashShell
https://deno.land/v1
======
aazaa
> ... Deno is (and always will be) a single executable file. Like a web
> browser, it knows how to fetch external code. In Deno, a single file can
> define arbitrarily complex behavior without any other tooling.

> ...

> Also like browsers, code is executed in a secure sandbox by default. Scripts
> cannot access the hard drive, open network connections, or make any other
> potentially malicious actions without permission. The browser provides APIs
> for accessing cameras and microphones, but users must first give permission.
> Deno provides analogous behaviour in the terminal. The above example will
> fail unless the --allow-net command-line flag is provided.

The Deno feature that seems to draw the most fire is dependency management.
Some skeptics may be latching onto the first point without deeply considering
the second.

Deno is just doing the same thing a browser does. Like a browser, there's
nothing that JavaScript running on sandboxed Deno can do that a browser can't
- in principle. So the security concerns seem a little over the top.

The one caveat is that once you open the sandbox on Deno, it appears you open
it for all modules. But then again, that's what NPM users do all the time - by
default.

As far as criticisms around module orchestration, ES modules take care of that
as well. The dependency graph forms from local information without any extra
file calling the shots.

This seems like an experiment worth trying at least.

~~~
bgdam
See the thing about the sandbox is that it's only going to be effective for
very simple programs.

If you're building a real world application, especially a server application
like in the example, you're probably going to want to listen on the network,
do some db access and write logs.

For that you'd have to open up network and file access pretty much right off
the bat. That combined with the 'download random code from any url and run it
immediately', means it's going to be much less secure than the already not-
that-secure NPM ecosystem.

~~~
ricardobeat
Maybe this will develop into a standard of multi-process servers (real _micro_
services you could say), where the permissions are only given to a slice of
the application.

~~~
BubRoss
Reinventing QNX will always be cutting edge.

~~~
pupdogg
QNX is hands down amazing! No car manufacturer could ever come close to having
their in-house infotainment system being as snappy as QNX...which is why they
gave up and switched to QNX! Fine print: Tesla not included.

------
petercooper
If you're getting into Deno and want to keep up with new stuff from the
ecosystem on a regular basis, we're now publishing
[https://denoweekly.com/](https://denoweekly.com/) .. issue 2 just went out
minutes after the 1.0 release. I've been doing JavaScript Weekly for 487
issues now, so this is not a flash in the pan or anything :-D

Of course, Deno has an official Twitter account as well at
[https://twitter.com/deno_land](https://twitter.com/deno_land) :-)

~~~
lenkite
Root certificate not trusted for
[https://denoweekly.com/](https://denoweekly.com/) on both chrome and firefox.

~~~
gpm
Maybe they fixed this in the last 2 hours, but it works for me (firefox,
linux).

~~~
lenkite
Weird, it still says that "Cisco Umbrella Root CA" is not trusted. Maybe its
only from certain countries.

~~~
gpm
I'm Canadian and in Canada for what it's worth. Clicking on the lock tells me
that it was verified by lets encrypt. The root is "Digital Signature Trust
Co." Common Name "DST Root CA X3".

Cisco sounds like a router might by running a MITM on you?

Edit: This looks to be confirmation that that root (or one by a very similar
name) is used by a MITM tool:

[https://docs.umbrella.com/deployment-
umbrella/docs/rebrand-c...](https://docs.umbrella.com/deployment-
umbrella/docs/rebrand-cisco-certificate-import-information)

~~~
lenkite
Thanks for the diagnosis. Accessed from a different network and with no
issues. And got the right certificate this time.

------
nojvek
> TSC must be ported to Rust. If you're interested in collaborating on this
> problem, please get in touch.

This is a massive undertaking. TSC is a moving target. I occasionally
contribute to it. It’s a fairly complex project. Even the checker + binder
(which is the core of TS) is pretty complex.

One idea that comes to mind is to work with Typescript team that they are only
using a subset of JS such that tsc can be compiled down web assembly and have
llvm spit out a highly optimized binary. This not only benefits demo, but the
rest of the internet.

TSC has done some great architectural changes in the past like doing mostly
functional code, rather than lots of classes.

The target we should be aiming for is a powerful typed language like
typescript that complies very quickly to webasshmbly that can run in
guaranteed sandbox environments.

~~~
grandinj
v8 has the ability to snapshot a program just after it loads, but before it
executes. If you snapshot after doing some kind of warmup, to trigger the
right optimisations, you get something that should fire up ready to go, which
is probably the main problem - the compiler being repeatedly invoked and
parsed from javascript and compiled on the fly.

~~~
z3t4
One problem with taking the v8 snapshot and using it as a binary executable is
that it will probably be much slower then running v8 live. Although the
startup time will be 10x faster. The runtime will be 10x slower.

------
bgdam
The dependency management is highly questionable for me. Apart from the
security concerns raised by others, I have huge concerns about availability.

In it's current form, I'd never run Deno on production, because dependencies
have to be loaded remotely. I understand they are fetched once and cached, but
that will not help me if I'm spinning up additional servers on demand. What if
the website of one of the packages I depend on goes down, just as I have a
huge spike in traffic?

Say what you want about Node's dependency management, but atleast I'm
guaranteed reproducible builds, and the only SPOF is the NPM repositories,
which I can easily get around by using one of the proxies.

~~~
fsloth
Why can't you download all the packages you use actually _with_ your source
code? That's how software has been built for decades...

I'm a desktop developer so I understand I'm the dinosaur in the room but I've
never understood why you would not cache all the component packages next to
your own source code.

Since this is straighforward to do I presume there is some tradeoff I've not
thought about. Is it security? Do you want to get the latest packages
automatically? But isn't that a security _risk_ as well, as not all changes
are improvements?

~~~
Cthulhu_
For Node, the main tradeoff is number and size of files. Usually the
distribution of a node module (that which is downloaded into node_modules)
contains the source, documentation, distribution, tests, etc. In my current
project, it adds up to 500MB already.

They would do well to have an option to optimize dependencies for vendoring.

------
didip
I like what Deno is selling. URL like import path is great, I don't know why
people are dismissing it. It is easy to get up-and-running quickly.

Looks like my personal law/rule is in effect again: The harsher HN critics
are, the more successful the product will be. I have no doubt Deno will be
successful.

~~~
Aldo_MX
My concern is what happens when popular-library.io goes down or gets hacked?

Or how about attack vectors like DNS poisoning? or government-based firewalls?

I know there's this[1], but somehow I still feel uneasy because the web is so
fragile and ephemeral...

At the very least I would like to have the standard library offline...

[1]
[https://github.com/denoland/deno/blob/master/docs/linking_to...](https://github.com/denoland/deno/blob/master/docs/linking_to_external_code.md)

~~~
mekster
> what happens when popular-library.io goes down or gets hacked?

What is anyone going to do about it? Anything has a chance of getting hacked
or goes down just when you need it, be it GitHub, npmjs.org...

Blaming the tool for not having a protection against DNS poisoning is a bit
far fetched.

~~~
xevrem
ultimately i guess it is about how/if deno caches its imports. with
node.js/npm you have the exact same problems, just the source & sink occur at
different places (package installation)

~~~
z3t4
With Node.js you install the packages in a dev environment, and test
extensively, then push all the code, including node_packages folder to
production. Running npm on the prod server is forbidden. At least in theory =)

------
tolmasky
Forget the (reasonable) security and reliability concerns people have already
brought up with regard to importing bare URLs. How about just the basic
features of dealing with other people's code: how am I supposed to update
packages? Do we write some separate tool (but not a package management tool!)
that parses out import URLs, increments the semver, and... cURLs to see if a
new version exists? Like if I am currently importing
"[https://whatever.com/blah@1.0.1"](https://whatever.com/blah@1.0.1"), do I
just poll to see if "1.0.2" exists? Maybe check for "2.0.0" too just in case?
Is the expectation that I should be checking the blogs of all these packages
myself for minor updates? Then, if you get past that, you have a huge N-line
change where N is every file that references that package, and thus inlines
the versioning information, instead of a simple and readable one-line diff
that shows "\- blah: 1.0.1, + blah: 1.0.2".

~~~
emerongi
Another thing is that with package.json every dependency can say which
versions of its dependencies it works with. This lets you update a dependency
that is used by other dependencies and only have a single version (most up to
date) of it. Some package managers also let you completely override a version
that one of your dependencies uses, allowing you to force the use of a newer
version.

With Deno, both of these use cases seem way harder to satisfy. None of your
dependencies can say "hey, I work with versions 1.1 to 1.3 of this
dependency", instead they link to a hardcoded URL. The best chance of
overriding or updating anything is if Deno supports a way to shim
dependencies, but even then you might need to manually analyze your dependency
tree and shim a whole bunch of URLs of the same library. On top of that, as
soon as you update anything, your shims might be out of date and you need to
go through the whole process again. To make the whole process easier, Deno
could compare checksums of the dependencies it downloads and through that it
could show you a list of URLs that all return the same library, but this would
be like the reverse of package.json: instead of centrally managing your
dependencies, you look at your dependencies after they have been imported and
then try to make sense of it.

~~~
pknopf
> None of your dependencies can say "hey, I work with versions 1.1 to 1.3 of
> this dependency"

That's a real problem that needs to be solved.

Also, what happens when two lib A and lib B depend on different versions of
lib C? Each have their own scoped instance of C?

------
seleniumBubbles
Congratulations on the 1.0 release! I've been using Deno as my primary
"hacking" runtime for several months now, I appreciate how quickly I can throw
together a simple script and get something working. (It's even easier than ts-
node, which I primarily used previously.)

I would love to see more focus in the future on the REPL in Deno. I still find
myself trying things in the Node.js REPL for the autocomplete support. I'm
excited to see how Deno can take advantage of native TypeScript support to
make a REPL more productive: subtle type hinting, integrated tsdocs, and type-
aware autocomplete (especially for a future pipeline operator).

~~~
indemnity
Seconded, a Deno TS REPL would be amazing, but they probably have a few bigger
fish to fry yet :)

~~~
IggleSniggle
> bigger fish to fry

> fish

I see what you did there, and I approve.

------
pedalpete
Does anyone else see the import directly from URL as a larger
security/reliability issue than the currently imperfect modules?

I'm sure I'm missing something obvious in that example, but that capability
terrifies me.

~~~
Saaster
Does Deno have some built in way to vendor / download the imports pre-
execution? I don't want my production service to fail to launch because some
random repo is offline.

~~~
afiori
Deno caches local copies and offer control on when to reload them. in term of
vendoring you can simply download everything yourself and use local paths for
imports.

~~~
xg15
How would this work with transitive dependencies? Sure I can control which
parts I import myself, but how do I keep a vendored file from pulling in
another URL a level deeper?

~~~
thebradbain
Unlike node, recommended deno practice is to check-in your dependencies to the
VCS.

> Production software should always bundle its dependencies. In Deno this is
> done by checking the $DENO_DIR into your source control system, and
> specifying that path as the $DENO_DIR environmental variable at runtime.

[https://deno.land/manual/linking_to_external_code](https://deno.land/manual/linking_to_external_code)

~~~
Rotareti

        du -hs node_modules
        
        1.7G node_modules

------
firloop
For the uninitiated, worth noting that one of the names on this post, Ryan
Dahl, was the original node.js developer.

~~~
ignoramous
Also for the uninitiated, fly.io is migrating to deno for their Serverless
functions:
[https://news.ycombinator.com/item?id=22621926](https://news.ycombinator.com/item?id=22621926)

~~~
mahmoudimus
Precisely the use case that Deno should be used for. Serverless functions are
a great use case for Deno right now.

------
JOnAgain
It would be great if this line were at the top:

>> Deno is a new runtime for executing JavaScript and TypeScript outside of
the web browser.

~~~
abraxas
Thanks. Came looking for this post. Way too many web developers just assume
that everyone follows every nook and cranny of their ecosystem.

------
anderspitman
> In Deno, sockets are still asynchronous, but receiving new data requires
> users to explicitly read()

Interesting. If I understand correctly, they're essentially using pull
streams[0]/reactive streams[1]. I compiled a few resources on this topic when
I was digging into it a while back[2]. I've found the mental model to be very
elegant to work with when needing backpressure in asynchronous systems.

As for the dependencies-as-URLs, I don't mind it, and may prefer it. I've been
experimenting with minimizing my dependencies lately, and vendoring them in
git submodules. It's worked fairly well.

[0]: [https://github.com/pull-stream/pull-stream](https://github.com/pull-
stream/pull-stream)

[1]: [https://github.com/reactive-streams/reactive-streams-
jvm](https://github.com/reactive-streams/reactive-streams-jvm)

[2]: [https://github.com/omnistreams/omnistreams-
spec](https://github.com/omnistreams/omnistreams-spec)

~~~
cakoose
When describing the input stream back-pressure problem:

> To mitigate this problem, a pause() method was added. This could solve the
> problem, but it required extra code; and since the flooding issue only
> presents itself when the process is very busy, many Node programs can be
> flooded with data. The result is a system with bad tail latency.

Are they saying that even with correct use of pause() there are still issues?

~~~
winrid
They're saying since the issue doesn't present itself until it's too late most
code does not use pause().

------
WatchDog
Of all the problems with NPM, it being centralized is the last of them imo.
Having experienced the mess that is go's decentralized dependency management,
I'm not sure why anyone would want to replicate it.

Putting aside security, availability and mutability is a massive problem,
anyone can stop hosting their module, or worse, change an existing published
module at any time.

Why not take some inspiration from maven central, and run a central repo that
actually provides some validation on the quality of and consistency of
published artifacts.

~~~
nesarkvechnep
> Why not take some inspiration from maven central, and run a central repo
> that actually provides some validation on the quality of and consistency of
> published artifacts.

Because then it would be hard to have a new hot framework every day.

------
_bxg1
So it's an alternative to Node? Sounds incredibly cool, honestly. This:

> Supports TypeScript out of the box.

Seems like a small thing, but it has me interested all on its own. It's a huge
pain to set up a whole build process just for TypeScript (which is generally
the only preprocessing you need outside of the browser).

~~~
gunn
You'll like [https://www.npmjs.com/package/ts-
node](https://www.npmjs.com/package/ts-node) \- it allows zero processing use
of typescript

~~~
bgdam
Word of warning though - ts-node can be excruciatingly slow. We recently
switched a project from using ts-node in our dev environment to compiling with
tsc and running with node, and shaved around 5 minutes from our startup time.

~~~
dgellow
You had 5 minutes _startup_ time?!

~~~
z3t4
More then one second and people will test their code less often. Five minutes
and people start relying on the type-checker. Like with the chicken and egg
problem, what came first, the type-checker or the need to have a type checker?

------
genezeta
One question.

> The browser provides APIs for accessing cameras and microphones, but users
> must first give permission. Deno provides analogous behaviour in the
> terminal.

I read this and I started looking around for the camera API or maybe for the
Audio API. And the thing is that I can't seem to find anything about it. I
can't see anything about it in "The Manual" or in the API reference.

Then I thought that there may not be documentation because it just mimics the
browser's API. Ok, but... there must be some command-line flag to give
permission to it, right? Can't find it either. Maybe "it was just an example;
there's no media API just yet"?

But then I set out to find available command-line flags in general. And I
can't find those either. There's this [0] but is that _all_? There's just
--allow-net, --allow-read and --allow-write? Or is there some other place
where the available permission flags are listed?

[0]
[https://deno.land/manual/getting_started/permissions](https://deno.land/manual/getting_started/permissions)

~~~
DougBTX
I don't see it listed in the docs, but try running `deno run -h` to see the
command line help. It should produce output like:

    
    
        -A, --allow-all                    Allow all permissions
            --allow-env                    Allow environment access
            --allow-hrtime                 Allow high resolution time measurement
            --allow-net=<allow-net>        Allow network access
            --allow-plugin                 Allow loading plugins
            --allow-read=<allow-read>      Allow file system read access
            --allow-run                    Allow running subprocesses
            --allow-write=<allow-write>    Allow file system write access
    

etc

~~~
genezeta
Thanks.

------
threatofrain
> Internally Deno uses Microsoft's TypeScript compiler to check types and
> produce JavaScript. Compared to the time it takes V8 to parse JavaScript, it
> is very slow.

> Early on in the project we had hoped that "V8 Snapshots" would provide
> significant improvements here. Snapshots have certainly helped but it's
> still unsatisfyingly slow. We certainly think there are improvements that
> can be done here on top of the existing TypeScript compiler, but it's clear
> to us that ultimately the type checking needs to be implemented in Rust.

> This will be a massive undertaking and will not happen any time soon; but it
> would provide order of magnitude performance improvements in a critical path
> experienced by developers. TSC must be ported to Rust. If you're interested
> in collaborating on this problem, please get in touch.

~~~
spankalee
Deno really shouldn't run TypeScript files directly. Not only is TypeScript
too slow for this, it receives far too many breaking changes.

How will Deno decide when to upgrade its TypeScript compiler version? Will
Deno have to have breaking changes every three months or so?

Also, Deno appears to allow import TypeScript files with .ts extensions while
tsc doesn't. This alone means the same code won't run in Deno and compile with
tsc.

JavaScript at Stage 3 and above is a stable compile target, and Deno should
just run that.

~~~
city41
I’m a huge TS fan and I agree. Deno is just running tsc for me it seems. So
far I don’t see much advantage. It also potentially ties Deno to current
trends. TS is pretty dang popular, but what if something else comes along and
scoops it?

~~~
Ciantic
Note that Deno started out as _Typescript_ runtime, it was it's tagline, they
added the JavaScript later there.

> TS is pretty dang popular, but what if something else comes along and scoops
> it?

Earth is rather small, type inferencing dynamic language is _really_ hard.
There is simply no other language or team that has achived anything like TS.
It's very unlikely that anyone else will do it for JS again. You can just look
at amount of work in TS already.

Only thing that can "scoop it" is another language entirely taking off and
leaving JS developers in the history. In that case the point becomes useless,
it can happen to any runtime for any given language.

------
HeavyStorm
Number of things come to mind:

\- How do you update dependencies? They are urls spread along many files which
can be everywhere... Do I have to find and replace every import statement?

\- In some enterprise environments, we use mirroring of package distributors
(Nexus, jfrog etc.). This give us the ability to audit what packages are being
imported, create a cache of packages so that a single delete or unpublish
(like good old leftpad) won't break all applications, etc. Since package
locations are hard-coded in the package files, it becomes challenging to do
this.

The argument that deno is mimicking a browser is thin. Browsers are client
side, they don't access databases or lives inside your firewall. Server
applications are much more sensitive to security issues than browsers.

~~~
dwb
A lot of comments here can be answered by reading the documentation.

[https://deno.land/manual/linking_to_external_code#faq](https://deno.land/manual/linking_to_external_code#faq)

------
cryptica
>> Internally Deno uses Microsoft's TypeScript compiler to check types and
produce JavaScript. Compared to the time it takes V8 to parse JavaScript, it
is very slow.

>> We certainly think there are improvements that can be done here on top of
the existing TypeScript compiler, but it's clear to us that ultimately the
type checking needs to be implemented in Rust.

Funny, I was just talking about something like this in an earlier TypeScript
discussion today. I was saying that I don't understand why Microsoft doesn't
have their own native TypeScript runtime engine by now.

I have nothing against TypeScript as a language but I hate the TypeScript
transpiler; it should be packaged as an engine, not as a transpiler. I just
hate having to debug mangled transpiled code and dealing with sourcemaps. I
want to be able to run and debug my own code, not some alternative mangled
version of it.

I think Deno is a promising project in the sense that they seem to understand
the drawbacks of transpilation and are actually trying to provide TypeScript
support which feels native. Everyone else seems to be ignoring this problem
including the creators of TypeScript.

~~~
uryga
> I don't understand why Microsoft doesn't have their own native TypeScript
> runtime engine by now

what would they do with it? ship it in Edge? great, now some small fraction of
users can run TS natively. but most can't, so everyone would still transpile
to JS anyway...

it could work if Google did it, but i don't think MS has enough market share
to have an influence here

~~~
noahtallen
It would work for server-side tools (like Deno). For example, cloud functions
on various cloud platforms often support TS.

~~~
uryga
yeah but i don't think MS uses TS-on-the-server enough or has enough Azure TS
users to justify putting in the effort

------
lame88
I briefly looked over this project when this link first popped up and didnt
think much of it, but then i was surprised to see this huge surge in votes. I
dont do much in the javascript and related world - can someone explain what in
particular about this project has generated such interest? Even after reading
the top comments, I feel like im missing the bigger pitcure.

~~~
otoburb
>> _I dont do much in the javascript and related world - can someone explain
what in particular about this project has generated such interest?_

The majority of the interest lies in the fact that Ryan Dahl[1] was the
original creator of Node.JS[2], which is currently a very popular Javascript
runtime and web backend.

Dahl released the initial version of Node.JS in 2009[3]. After a decade of
experience working on Node.JS and growing the community, Dahl decided to
create an alternative Javascript (and Typescript) runtime in mid/late 2018
called Deno which is now v1.0.

[1]
[https://en.wikipedia.org/wiki/Ryan_Dahl](https://en.wikipedia.org/wiki/Ryan_Dahl)

[2] [https://nodejs.org/en/](https://nodejs.org/en/)

[3]
[https://en.wikipedia.org/wiki/Node.js](https://en.wikipedia.org/wiki/Node.js)

~~~
jkrems
> After a decade of experience working on Node.JS and growing the community,
> Dahl decided to create an alternative Javascript (and Typescript) runtime in
> mid/late 2018 called Deno which is now v1.0.

Just to nit-pick: Ryan Dahl had stepped away from node and the surrounding
ecosystem in 2012. So for the vast majority of node's lifetime, he hasn't
really been involved. Node in 2012 was a very different project.

(That doesn't take away from his observations or from the things that deno
does differently. Just trying to reduce confusion.)

------
itsarnavb
Congrats to the Deno team and community on reaching 1.0!

We've launched Deno support on repl.it here (in beta):
[https://repl.it/languages/deno](https://repl.it/languages/deno) for folks to
try out.

------
weeksie
This is super effing awesome.

You know what would be extra amazing? Incorporating (at some point in the
future) all of the very smart stuff that the unison people have been doing.
That would be _tremendous_ for code re-use and guarantees about remote
packages. What I wouldn't give for a JS vm that could do all that. . . .

* [https://www.unisonweb.org/docs/tour](https://www.unisonweb.org/docs/tour)

~~~
cdata
I like that Deno prefers URLs as module specifiers. Need immutable/content-
addressed dependency graphs? Publish and consume modules via IPFS.

~~~
weeksie
Maybe I’m missing something but the reason why the concept behind unison is so
neat is that identifying libraries by AST allows for the kind of code re use
that Joe Armstrong was talking about. It’s not about urls as identifiers,
that’s superficial.

What’s the relevance of IPFS?

------
chrysoprace
This is exciting news indeed. Deno hitting 1.0 still makes the ecosystem
surrounding it quite young, but it's an important milestone and I'm excited to
see what comes of it in the future.

------
gen220
For context:

Deno's lead is Ryan Dahl, the creator of Node.

In the past, Dahl's expressed regrets over choices he made early on in Node's
development, and on the direction Node has gone since he left the project many
years ago.

He bravely presented on this topic at jsconf eu, 2018:
[https://www.youtube.com/watch?v=M3BM9TB-8yA](https://www.youtube.com/watch?v=M3BM9TB-8yA),
it's a fantastic talk.

The last 10 minutes are a pitch for what a "better Node" would look like, if
he were to start from scratch in 2018. The end result of that train of thought
this project, which we should probably think of as bourne-again node.

Deno's development is (presumably) strongly influenced by his experience and
furstrations with Node's shortcomings in both performance and developer ux.

~~~
lghh
And now, he'll make a whole different set of good and bad choices to
potentially regret later.

~~~
gen220
such is the curse of having the audacity to develop software :)

~~~
nkozyra
Sure, but there's a tendency to start over when the development gets hard to
maintain or support instead of just fixing the mistakes.

This really feels like the fundamental response in the js world and why we see
much churn.

~~~
polishdude20
But isn't this an inherent problem in software development that is really
super hard to not do?

Let's say you are deciding how to make node when it was first conceived and
how it would work. You've made decisions about how the thing fundamentally
works. Then after using it and developing for it many years and after having
millions of critical software projects dependant on it, you slowly start to
see the shortcomings of the software that you could only see at this stage.
The problem is that these shortcomings come from a false assumption or
solution to the fundamental problems you had to solve when making node. Now,
the only way to fix node is to change how it fundamentally works. But if you
do that, millions of users' code will break. So, do you require everyone now
to fix their broken code and potentially piss everyone off? Or do you give
people a choice? Stick with node if you aren't noticing any of those
fundamental problems you found, or switch to the new thing on your own time?
It's a question of how to affect the least number of people in the least
negative way.

~~~
nkozyra
I think the answer is a break in backwards compatibility on a major version
release.

People in JS/frontend world are willing to drop the world for the latest new
thing, I see this as less jarring than, say, Python 2 -> Python 3.

~~~
haack
I find it amusing that you use the example of Python 2 -> Python 3, a breaking
change in a widely used language, that has famously been very difficult and
long for organisations to deal with.

Compare that with javascript which has never had a breaking change. On top of
that Typescript is a backwards compatible superset of javascript.

More to the point, Ryan has a humble explanation of what regrets he has about
Node.js[1], why they exist and in some cases why there isn't an easy fix.

The point that I assume you're making, that sometimes it is better to spend
significant energy to fix something, rather than throwing the baby out with
the bath water, is a good one. However I'd suggest this is not one of those
cases.

[1]
[https://www.youtube.com/watch?v=M3BM9TB-8yA](https://www.youtube.com/watch?v=M3BM9TB-8yA)

~~~
nkozyra
> I find it amusing that you use the example of Python 2 -> Python 3, a
> breaking change in a widely used language, that has famously been very
> difficult and long for organisations to deal with.

Why is that amusing? I specifically chose that example for that exact reason.
I was highlighting the difference in the audience and use case.

> However I'd suggest this is not one of those cases.

I don't see the argument that supports that, either in the post or your reply.

The thing is, I can see Beepboo 1.0 being announced in 2025 to address the
things that went wrong with deno. Because there _will_ be design mistakes. And
at what point do you say 'oh too many people rely on this software to fix
this, I have to start over'?

Couple this with a very real trend-chasing and resume pushing in frontend dev
and I'm starting to understand why people are so cynical about this stuff.

Typescript is something more palatable to me because it _wasn 't_ throwing the
baby out with the bathwater.

~~~
haack
> Why is that amusing? I specifically...

My apologies I misread.

> ... there's a tendency to start over when the development gets hard to
> maintain or support instead of just fixing the mistakes.

The thought that Node.js should have been 'fixed' instead of creating Deno is
where I disagree. At a glance I can see a few reasons:

\- Node.js maintainers + community may not even think there is something to be
fixed (see various discussions in this thread about module resolutions)

\- Politics, death by committee, inertia

\- Effectively a dependency with npm registry (although not technically)

\- Lack of backwards compatibility with changes (e.g. module resolution)

> The thing is, I can see Beepboo 1.0 being announced in 2025

Node.js was initially released in 2009 so it's probably fairer to suggest
Beepboo 1.0 will be released in 2030. And yes, if it improved on Deno and
solved inherent problems that couldn't be solved internally, I would
wholeheartedly cheer it along.

I think it's also worth mentioning that Node.js is at a level of stability and
maturity that people who plan to and have already built on it, aren't left
abandoned.

------
appleflaxen
This project looks really cool to me.

I'm glad the link to the video is there, because my intuition about
pronouncing the name was incorrect.

It looks like it could be "deeno" OR "denno", and I was pushed to the former
by the presence of the dinosaur graphic. Isn't that old fashioned dinosaur on
the Flinstones pronounced deeno? Anywho... good name overall: short, no
collisions (i think?), and no strong baseline associations.

And only right this instant am I realizing that this is an anagram of node...
oh my god i'm slow. Now it's a _great_ name.

~~~
swrobel
What video? Mind linking directly?

~~~
ioncube
I think he meant Ryan Dahl's talk: Design Mistakes in Node
[https://www.youtube.com/watch?v=M3BM9TB-8yA](https://www.youtube.com/watch?v=M3BM9TB-8yA)

------
pknopf
\- "Rust has its own promise-like abstraction, called Futures. Through the
"op" abstraction, Deno makes it easy to bind Rust future-based APIs into
JavaScript promises."

That's exciting! I wonder if that binding is public for end users to use, or
if it's an internal design

~~~
steveklabnik
This exists for wasm too; it’s super easy with wasm-bindgen. I wrote a program
with multiple layers, worked flawlessly. (Promise in a future in a promise
created by Rust and passed back to JS)

------
moron4hire
Given that all API calls in JS have to go through the interpreter, couldn't
unsafe API calls have an implicit parameter added that requires a per-package
token, with the API accessed through an interface requested by the package
that pins that interface to that token? Additionally, you could allow package
authors to set their token as a cryptographic public key from a package
manifest, so they could grant access to the API to sub-packages within their
own ecosystem. If you passed the API interfacing object to a package outside
of your control, the calling code's token wouldn't match the API interfacing
object's expected token and would kick a security access exception. This would
be completely transparent to the package author. With such a system, access to
unsafe APIs could be granted to only a shortlist of packages.

Something like this is already done with only allowing access to certain APIs
if they are called from certain types of event handlers, until the callstack
of the event handler is left.

------
ajnin
The fundamental problem of dependency management, as anyone who ever kept
bookmarks knows, is that the external sources might go away at any time. It's
not a problem unique to Deno or Go. Take Java for example, its standard
dependency management tool is Maven, which relies on external repositories of
artefacts to function. From time to time, a repository might go down, or it
might be moved to another address, or a library might be migrated to another
repository. Whenever this happens, your build might break. The solution is to
proxy all requests at the organizational level through your own server which
keeps a mirror of any package that has been referenced once. That way, if it
become unavailable externally, then you can still use it internally. You can
also override packages with patched versions if they misbehave.

I think that Deno should define a standard dependency fetching protocol, and
allow proxying transparently at a native level. If it does, that kind of
dependency management will be fine.

------
_bxg1
> A hello-world Deno HTTP server does about 25k requests per second with a max
> latency of 1.3 milliseconds. A comparable Node program does 34k requests per
> second with a rather erratic max latency between 2 and 300 milliseconds.

Under-mentioned feature. I may migrate my personal site to Deno just for that
latency drop.

~~~
ch4s3
Yeah it seems like the p99 latency of node, which isn’t great, doesn’t get
mentioned much.

------
cocktailpeanuts
if you require modules by URL, how does it make sure that the URL always
contains the same library?

I've read the docs and it says it caches on the initial execution and doesn't
update unless it's forced to update, but what happens when you for example
publish a deno module to github, and someone else downloads it and runs it,
and turns out the URL contains completely different library at his execution
point?

~~~
piscisaureus
This is something that we'll further work out in future versions. For now you
can use a lockfile:
[https://deno.land/manual/linking_to_external_code/integrity_...](https://deno.land/manual/linking_to_external_code/integrity_checking)

~~~
hn_throwaway_99
> Deno can store and check module subresource integrity for modules using a
> small JSON file. Use the --lock=lock.json to enable and specify lock file
> checking. To update or create a lock use --lock=lock.json --lock-write.

HALLELUJAH that there is a clear, simple separation of when (a) you expect a
lock file to be checked to guarantee integrity and (b) when you want it to be
generated. The complete insanity that was npm shrinkwrap and lockfiles for
years, summed up in this stackoverflow post
[https://stackoverflow.com/questions/45022048/why-does-npm-
in...](https://stackoverflow.com/questions/45022048/why-does-npm-install-
rewrite-package-lock-json) , always baffled me in that it seemed like it could
have just been so easily avoided about being explicit when you're writing a
lockfile vs. when you're using it.

That said, why not be even MORE explicit about it, i.e. "\--use-
lock=lock.json" vs. "\--write-lock=lock.json"?

------
bryanrasmussen
The import from url feature is drawing a lot of initial skepticism - but I
think once you look closer at it there are even more things to be wary of.

The initial thing is the fear "whoa, that is hella insecure!" which, I agree
NPM is basically the same problem... although, with NPM - Git system, you can
1. fork a version and use that version (which you can do with this, just host
different url) or two you can freeze version you are using and theoretically
only update after checking stuff out (I guess you would have to do the same
with host different url, seems more difficult process)

Also NPM basically makes a local cache of the files you will be importing, I
guess the first time you run your program it must get the files and then
caching keeps them from updating until the resource updates? Maybe I'm missing
something and it isn't like that but if it is like that I find that weird
because you are arbitrarily adding extra performance overhead to parts of your
system as code loads and sees it needs to get a resource that has updated? I
guess what would end up happening is versioning would be in the url and an
expires header set a long time in the future, like you might do with static
assets now, but Deno doesn't require that, it will be an outgrowth of this
import from url system. Will there be situations where someone has done the
caching poorly, or set the header badly or whatever and you are loading a
resource too often? I would expect so, anyway I guess there will have to be
testing of Deno's caching [https://www.mnot.net/blog/2017/03/16/browser-
caching](https://www.mnot.net/blog/2017/03/16/browser-caching)

Finally, in NPM's system if a module I'm importing is a little bit weird I can
always just go into the folder quickly and start debugging and maybe fixing
the code, and then when I've got things working the way I think they should
with changes do an actual fork pull-request, or just fork and use my fork of
the code, or if it turns out as it often does that I've misunderstood
something revert my changes to their code and go fix my code instead. I can of
course still achieve the same effect with Deno but the workflow would have to
be different and I think would end up being more convoluted, at least in the
beginning.

These are the initial worries that I get when seeing import from some url. I
suppose someone has already thought these things through and I'm unnecessarily
worried so if that someone is you (the reader of this long post) you can maybe
assuage my worries.

~~~
ecares
Well is has a huge security hole that ry wont fix
[https://github.com/denoland/deno/issues/1063](https://github.com/denoland/deno/issues/1063)

~~~
bryanrasmussen
I would like to write a long damn with an exclamation point at the end but the
margins of my screen are insufficient to hold it.

------
devit
What is the reason for making a JavaScript runtime based on browser APIs that
cannot also be a browser?

Or in other words, wouldn't it have been easier and better to make an
optionally headless version of the Servo browser with additional native APIs
and some enhancements like being able to run JavaScript directly in addition
to HTML?

The choice made means that Deno can't be used, at least directly, to make
desktop applications, and also doesn't have all the features that browsers
have for free, like multiprocess and multiple sandboxes, network traffic
inspector, local storage, GPU compute, etc.

~~~
timw4mail
The Javascript engine is a lot smaller code surface area than an entire
browser rendering engine.

------
Rapzid
I feel explicit location imports are a step backwards. Node ecosystem is
moving toward workspaces and Yarn Plug'N'Play style manifest lookups for deps.
The de-coupled import from where physically the dependency is being satisfied
from seems desirable and it is a common next-level pattern in project and
dependency management across language ecosystems.

Sure, I guess you could shim it somehow like is happening in the node
ecosystem but then.. I'm not sure what the stock situation brings to the table
TBH.

------
turblety
As a functional developer who doesn't care for TypeScript in any way, it's
frustrating to see Deno has it "built-in".

As a node developer writing pure none-compiled JavaScript, my run time is
extremely fast from changing code to seeing its results. It takes milliseconds
for me to run brand new code in my terminal.

If I make an index.ts file simply adding two numbers together (with no
TypeScript), there is a 1 to 2 second delay while it "compiles" my
"TypeScript". (Again I don't write TypeScript so I don't need this feature). I
should note, subsequent runs will be faster, but as I'm developing I don't
want delays between my runs.

Since it's not even native TypeScript, it's just embedded the tsc which builds
and caches the compiled code, why not let TypeScript developers add their
bundling pipeline in the same way as they've always done.

Anyway, I'm very interested in the fact it's built in Rust and seems to be
faster than node after compilation in many aspects. Congratulations to the
Deno guys and thanks for all the effort.

[edit] Correcting myself. I was wrong. As @jon889 informed me, you can
actually run a `.js` file and it will skip compilation. Again I remain that
the TypeScript compiler should not have been included, but the fact I don't
have to use it completely mitigates my main concern.

~~~
mrkurt
> As a node developer writing pure none-compiled JavaScript, my run time is
> extremely fast from changing code to seeing its results. It takes
> milliseconds for me to run brand new code in my terminal.

Deno runs JavaScript faster than node:

    
    
       echo "console.log(1 + 2)" > not-ts.js
       time deno run not-ts.js
       3
       0.01s user 0.01s system 89% cpu 0.025 total
       time node not-ts.js
       3
       0.03s user 0.08s system 53% cpu 0.203 total
    

> Since it's not even native TypeScript, it's just embedded the tsc which
> builds and caches the compiled code, why not let TypeScript developers add
> their bundling pipeline in the same way as they've always done.

You can!

~~~
turblety
> Deno runs JavaScript faster than node

Yup, and that's really cool and exciting. My issue isn't with runtime timing.
That's not what costs me money. Developer time is what costs money, and every
change having to "recompile" my already raw JavaScript costs way more than
saving 0.02s at runtime.

~~~
jon889
Can't you just pass it a .js file and it will skip the TypeScript compiling
completely?

~~~
NoInkling
That's not gonna help if you're using any part of the standard library though
(or presumably most 3rd-party modules), since it's written in TS, right?

~~~
chrischen
I'd assume you can just use regular node modules in that case?

------
cambalache
FWIW I tried to install it in a) Windows 10 via PowerShell, success, it took 1
min. b) Linux (WSL1) with curl, 2 min, failed. 3) Linux(WSL1) via cargo.10 min
failed with this jewel:

> error[E0433]: failed to resolve: use of undeclared type or module
> `proc_macro` \-->
> /home/user/.cargo/registry/src/github.com-1ecc6299db9ec823/swc_ecma_visit_macros-0.1.0/src/lib.rs:25:20
> | 25 | pub fn define(tts: proc_macro::TokenStream) ->
> proc_macro::TokenStream { | ^^^^^^^^^^ use of undeclared type or module
> `proc_macro`

error[E0433]: failed to resolve: use of undeclared type or module `proc_macro`
\-->
/home/user/.cargo/registry/src/github.com-1ecc6299db9ec823/swc_ecma_visit_macros-0.1.0/src/lib.rs:25:48
| 25 | pub fn define(tts: proc_macro::TokenStream) -> proc_macro::TokenStream
{ | ^^^^^^^^^^ use of undeclared type or module `proc_macro`

error: aborting due to 2 previous errors

For more information about this error, try `rustc --explain E0433`. error:
could not compile `swc_ecma_visit_macros`. warning: build failed, waiting for
other jobs to finish... error: failed to compile `deno v1.0.0`, intermediate
artifacts can be found at `/tmp/cargo-installFIkSV2`

Caused by: build failed

------
greggman3
Just a random though but if they want speed they could consider making a
typescript JIT instead of typescript -> javascript. Typed languages _can_ run
much faster than untyped. Maybe that's impossible with current typescript
given anything can be changed, eg (30 minutes into running something does
Math.floor = ... etc, but maybe some kind of escape analysis could help or
maybe push for some new keyword to mark code as safe to optimize.

~~~
marijn
Building a new JIT for a dynamic language, if it is supposed to be competitive
with JS compilers, is a project several orders of magnitude bigger than
building a runtime like this.

TypeScript's design is very much that of a typing layer over a dynamic
language. It's unsoundness and various loopholes to escape typing mean it's
not much of a help for typed compilation.

~~~
torb-xyz
Microsoft _do_ have the research project Static TypeScript that does try to do
this with a subset: [https://www.microsoft.com/en-
us/research/publication/static-...](https://www.microsoft.com/en-
us/research/publication/static-typescript/)

But your point stands I think this subset will be incompatible with how many
(including myself) writes TypeScript.

------
kentf
Won’t Meteor.js make this project extinct?

~~~
mahmoudimus
Clever ;)

------
diffrinse
I predict cdnjs/jsdelivr types will explode in use for Deno packages since
they can make bandwidth and security guarantees behind what's actually
returned from the URL as well will be able to accomodate versioning in the
path. That seems to be what this dep system is built for, unless I'm missing
something.

------
sholladay
If you need a server framework for Deno, please take a moment to check out
Pogo. It's got a powerful and friendly API. It also has the best documention
and plenty of tests.

[https://github.com/sholladay/pogo](https://github.com/sholladay/pogo)

------
sdan
What exactly does Deno do? I still can't figure it out: is it a secure version
of Node, if so, how?

~~~
kennymeyers
It’s an alternative to node. If Node is Photoshop than Deno is Pixelmator.
They both take in similar kinds of output and make similar things, but have a
very different approach on how the tooling is built and used.

~~~
sdan
Good explanation, thanks!

------
pvg
Some of the bigger previous threads:

[https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...](https://hn.algolia.com/?dateRange=all&page=0&prefix=true&query=Deno%20&sort=byPopularity&type=story)

------
ecares
Well, there is a known MITM vuln in Deno by design and the team refuses to fix
it soooooo

REF:
[https://github.com/denoland/deno/issues/1063](https://github.com/denoland/deno/issues/1063)

~~~
crabmusket
Lockfiles should be used for production code, as per
[https://deno.land/manual/linking_to_external_code/integrity_...](https://deno.land/manual/linking_to_external_code/integrity_checking)

~~~
realharo
Can checksums/hashes be specified directly in the source file?

EDIT: I mean hashes of dependencies.

That is important for single-file scripts, if this is meant to be useful as a
bash replacement for scripting.

Having to download two separate files for a script and execute it with special
arguments already adds too much friction to that scenario.

~~~
ecares
>Can checksums/hashes be specified directly in the source file?

That would defeat their point actually :D malicious attacker could inject any
script by hacking on the network and replace modules that are downloaded
through http

~~~
realharo
How? Say I have `script.ts`. That file exists locally on my computer and the
code inside it is trusted (say it was downloaded from a trusted github project
via https). It contains

    
    
        import { dependency } from 'http://whatever.url/@1.0.3'
            with hash '6f09aa686a6263f9e992'
    

or something like that. If an attacker replaces stuff during transfer of the
dependency, then the hash won't match (assuming a collision resistant hash
function). This can be transitive if the dependency also has hashes of its
dependencies directly inside it (and a "only allow that" mode could enforce
it).

The additional benefit is that you also don't need to trust the server to not
replace code for a URL under your nose from one you have previously verified.
So like a lockfile, but without needing to download a separate file (because
you also want verification on the first run) and a command-line argument on
launch - which makes it a much more viable replacement for bash scripts (in
fact, that's why I care about the ability, I wouldn't mind https-only). Am I
missing something here?

~~~
ecares
Oh, I did not get what you meant ^^ well, there are still other issues than
integrity with not using https.

~~~
realharo
Yeah, I'll edit the original comment to clarify that I mean hashes of
dependencies.

------
sequoia
I am a long-time Node.js user. My question about Deno is "is there any
indication that this project will have a different trajectory from the node.js
project (also started by some of the same people as Deno), or should I expect
Deno to also follow a 10 year arc?"

I think evolution & starting over can both be appropriate steps forward, I
don't question the Deno project, but to have the _exact same_ people who
created Node.js say "OK here's the _new_ new JS hotness," I think "how can we
expect this time to be different" is a reasonable question. Or perhaps these
ecosystems are not meant to last/be supported more than 10ish years?

------
ravenstine
Are imports async by default in Deno? That seems to be how it works given that
you can import from a URL. This is interesting since async imports are
currently a part of JavaScript(or at least a proposal?) by using the
`import()` function.

~~~
snek
there are no "async" or "sync" imports in js. there are static and dynamic
imports. An implementation is free to spend as much time as it likes between
parsing a file to get the static imports and actually running the file doing
whatever it likes, including fetching urls, reading the file system, etc.
dynamic imports return a promise but the implementation is free to resolve
that promise immediately (e.g. `return Promise.resolve(loadSync(module))`)

~~~
ravenstine
I suppose that makes sense since loading a module from a file on a disk isn't
all that different from loading a file over a TCP connection.

------
gpm
Is there some deterministic way of measuring JS execution time?

Explanation for why I want that:

I've started making an game RTS game - think starcraft but you can program
your units.

Currently I'm trying to decide what language to expose to players. The two
main requirements are that it's secure (I'll be running player A's code on
player B's computer) and that it has a deterministic method of counting
execution time (so that player A and player B's computer can both make the
same decision on whether or not a script took too much time).

I'd appreciate any hints towards other languages I should look at as well.

~~~
proc0
I guess it would depend on the JS engine. If the player is the one writing JS,
and you want a scaled down environment (since it's not an app in the browser),
probably making your own JS parser/engine could be the way to go? You'd want
the JS engine to be inside the game engine somehow.

~~~
gpm
> and you want a scaled down environment

This is definitely a requirement, a very scaled down one since I don't want
any interaction with the outside world apart from the game engine (for
determinism purposes).

> probably making your own JS parser/engine could be the way to go

That sounds like a _lot_ of work to do well. If I had infinite time I suppose
re-implementing a common language would be the best way forwards, but I don't,
especially for a hobby project.

~~~
proc0
Yeah I can't comment much on how long a JS engine would take. You could start
using V8 I guess, but I would think using an existing JS engine inside a game
engine might by tricky because they seem complex. JS the language is easy to
create a _parser_ for, and that might be what you really want to be custom in
order to do other things in between the JS code. Maybe try looking for
stripped down JS engines that have source code to see how hard it is. I'm also
assuming you will code this game with C++ for performance, but maybe a JS/HTML
game could leverage V8 from the browser, if that was your initial thinking.

~~~
gpm
I'd be _delighted_ to use V8... if I could figure out a way to get a
deterministic estimate of the runtime of scripts (e.g. in languages that
compile to a bytecode I could add a "bytecodes executed counter" easily
enough).

I'm coding the game in Rust, but I really don't care what the language is
coded in, linking in a language runtime isn't a problem.

------
zaro
Some compatibility with Npm modules would have been better choice for
adoption.

------
joelbluminator
Even if this new thing has slightly nicer syntax or usage of promises or
whatever, does this alone justify it's existence? Learning all this new
tooling and ecosystem all over again? Dividing the web development ecosystem
even more? I really don't see how the problem it's solving is big enough for
us to care really. I mean - enough already. In 8 years I'm sure Ryan Dahl can
come up with an even better runtime written in Grust, will we then all be
migrating our codebases from Node -> Deno -> Dynamite?

~~~
BenoitEssiambre
Also you can get most of the benefits of async/await without all the downsides
of promises:
[https://www.npmjs.com/package/casync](https://www.npmjs.com/package/casync)

------
simonw
Question:

    
    
        deno run https://deno.land/std/examples/welcome.ts
    

This works - it downloads the code from that URL, then compiles and runs it.

But if you visit
[https://deno.land/std/examples/welcome.ts](https://deno.land/std/examples/welcome.ts)
in your browser you get back HTML, not raw code.

Anyone know how this works? Is deno.land a special case or is there some
Accept header cleverness or something going on?

~~~
akamaozu
Was waiting for the first person to point out that what you get when you visit
a url is not guaranteed to be the exact same on a subsequent visit.

Not seeing how url-based package management is safer when a package host can
use a server that sends a special payload to certain requester ips, headers,
cookies or referrer.

Until there are firm guarantees around what you get from a url, a trust-able
third party is needed, even if just as an option.

------
seemslegit
Some people for the last decade: wouldn't it be great if node had a
comprehensive, idiomatically coherent, thoroughly typed standard library ?
Look, typescript is right here !

No-one, at all, for the love of jeebus: Do another node-like thing, but make
it in rust _on top_ of C++ (or is the other way around ?), somewhat similar
but generally incompatible, have a whole different set of APIs, a bunch of new
tools and yet another package/module system.

------
avodonosov
I don't understand how Promises help with backpressure.

------
gitgud
So I can import using the URL
"[https://somekind.com/ofpackage.ts"](https://somekind.com/ofpackage.ts"),
that's great but what if that random endpoint changes?

The benefit of NPM is that every package version is immutable...

Also first class Typescript support is great, but they are just using tsc
internally... isn't that directly tying a typescript version to the DENO
version?

------
ranguna
I'm probably just one more person among the hundreds who are missing something
here but: if the big thing about deno is that you can directly fetch
dependencies from source with, for example, a GitHub repo URL, instead of
going to a package registry like npm, where the package is decoupled from the
source, why don't you simply do this already by changing the package.json and
swapping the npm identifier with a URL to the repo?

You can already do decentralisation with npm by simply not using`npm i some-
package --save` and instead, modify the package.json yourself.

Now the problem with deno is that if I import 5 packages (locked to a specific
version) across 50 files and I want to update them to a new version, am I
really gonna need to go into every single file and change the URLs??

That's just insane, I get the whole idea of decentralisation but why can't we
concentrate all packages into a single file??

Sire this is all good for distribution because you won't have to run `npm i`
every time you want to run your program, but more often than not, I'm the one
that's going to use my program and I don't mind running `npm i` beforehand and
feel safe that I have all my packages downloaded and ready to go, instead of
worrying that my program will fail at run-time because the URL for one of my
packages is down..

------
VWWHFSfQ
> We believe JavaScript is the natural choice for dynamic language tooling;
> whether in a browser environment or as standalone processes.

I disagree with this assessment. Lua is still far superior as an embed-able
scripting language/runtime. I suspect the preference for JavaScript is mostly
due to the Deno developers' familiarity and preference.

~~~
tills13
> Lua is far superior

I disagree with this assessment.

~~~
VWWHFSfQ
LuaJIT is nearly 3x faster than V8 JavaScript the last time I checked. Just
anecodal DDG search [0]. Maybe V8 has gotten faster since the last time I
checked.

[0]
[https://duckduckgo.com/?t=ffab&q=is+luajit+faster+than+v8+ja...](https://duckduckgo.com/?t=ffab&q=is+luajit+faster+than+v8+javascript%3F)

~~~
rosywoozlechan
Lua also has a smaller footprint I think.

~~~
hombre_fatal
It has a worse standard library than Javascript. And its static typing
solutions don't compare to Typescript.

~~~
wyozi
Funnily enough the state of art in typed lua _is_ typescript:
[https://github.com/TypeScriptToLua/TypeScriptToLua](https://github.com/TypeScriptToLua/TypeScriptToLua)

------
Keats
> TSC must be ported to Rust. If you're interested in collaborating on this
> problem, please get in touch.

Have you talked with the TS people to see if maybe there are some bottlenecks
that could be rewritten in Rust rather than rewriting everything? Even though
I would love to have TSC in Rust, it seems like it would be a huge amount of
work.

------
corndoge
> We seek a fun and productive scripting environment that can be used for a
> wide range of tasks.

So Lua, but Javascript? Could be neat

------
russellbeattie
I think Deno is fine, and I think the project is interesting, but I also think
those who want to use Typescript should do so, and stop pretending they're
doing anything with Javascript. If I wanted deal with repetitive code like
"function add(x: number, y: number): number {...}" I'd just use Java. There's
reasons I love JavaScript, and not dealing with types is one of them. When is
Typescript going to have its own version of the V8 engine and just leave
JavaScript out of it? Honestly, it harkens back to the classic Microsoft
Embrace, Extend, Extinguish strategy that I though we left behind in the early
2000s...

I like that Deno is resetting some of the underlying assumptions that Dahl
made in Node. But I think he's throwing the baby out with the bath water. I
actually _like_ and prefer an explicit node_modules directory. Grabbing
everything I need, and then being able to zip it up as needed to save or share
is convenient and easy. Not sure why so much effort was made to avoid this
module pattern. I really think using URLs is going to be a maintenance
nightmare. Instead of changing one entry in package.json (great for testing
new code or tweaking something locally), I have find/replace all the imports?
Seems very odd unless I'm missing something big. Also, not a fan of the hidden
.deno cache directory, but whatever.

Having to send along a shell script in order to even _start_ an app is another
problem. "Here's a JavaScript file which will do some task. In order to run
it, you need to make sure you include these 10 command-line flags for security
purposes. To make sure you don't forget them, I've included various shell
scripts you can run depending on your platform." That's not improving
anything.

~~~
qudat
> Instead of changing one entry in package.json (great for testing new code or
> tweaking something locally), I have find/replace all the imports?

This is my biggest beef. When building large scale applications there are many
more files with imports than a typical large scale golang project that uses
the url import scheme. It's just going to be a really annoying thing to deal
with. ATM I see deno being great as a replacement for nodejs scripts and
smaller scale projects. But for massive projects I don't see the gain.

------
giorgioz
I have two questions: 1) How to port a node package to deno? 2) How to keep
both a node and deno packages in the same repo?

Clearly without packages we are not going to use deno. Also I don't want to
switch from well-proven packages like express/koa to an new unknown http
server just because it supports deno.

~~~
austincheney
There are some manual things you can do to ensure portability from Node to
Deno:

* separate out the Node APIs from the rest of your application logic as much as possible as those will be different unrelated API conventions.

* convert your application from using _require_ to using ES6 modules. This won’t work if you have more that few highly trivial dependencies as Node requires picking one way of importing files and that one way extends to your dependencies as well.

* Node uses callbacks for asynchronous logic where Deno uses promises, so ensure all callback functions are passed by reference so that the difference is an API difference instead of a logic difference.

------
golergka
> for await (const req of serve({ port: 8000 })) { > req.respond({ body:
> "Hello World\n" }); > }

It's not the first time I see js iterators used and abused this way, and every
time I feel that js and it's users are ready for full-blown monads and do
notation instead.

------
torb-xyz
First-class TypeScript support is the thing that excites me the most about
this. It's so annoying when you want to navigate TypeScript code from a
dependency in Node and it kicks you to a TypeScript-definition file instead of
the actual TypeScript source.

------
izelnakri
I would really like a testing framework like AVA on deno, same amazing API of
seperating parallel and serial tests and running them on multiple threads.
Also I will need npm compatibility soon, once these are in, why would I ever
write code in node.js?

------
kalium-xyz
Finally we can use it on production, great work everyone involved in making
this happen!

------
tmvnty
For anyone that's interested, here's a list of projects I'm interested in or
use with new major versions in 2020:
[http://maker.sh/2020](http://maker.sh/2020)

------
wincent
I tried it briefly on a side project a couple of months ago. I like some of
the ideas in it, but my editor tooling (which is TypeScript-ready but not
Deno-ready) wasn't ready for it. I might revisit in a year or two.

------
emtel
I don't want to be overly critical of a very well-intentioned and worthy
effort, but it is looking less and less to me like Ryan and the rest of the
Deno team understand what problems node.js developers care about.
Specifically:

1\. The sandboxing via --allow-net, --allow-fs, etc is very odd to me. I don't
recall hearing about a lot of security issues that could have been prevented
by this. I mean, I suppose this won't hurt anyone, but it's certainly never
something that I've wanted. I expect most people will simply white-list most
access by default in all new projects.

2\. deno bundle: Initially, when I heard about this, I was excited. The need
to bundle code via webpack and similar systems is one of the worst things
about front end browser development. It introduces tons of complexity and
makes debugging much harder. So I thought, wow, maybe deno is going to just
give us a first-class solution to this problem that will just work. Nope. They
are only concerned with bundling code such that it can be run elsewhere by
deno. A friend put it thus: "we don't want bundlers anymore, so we're making
deno bundle, the one true bundler!" "does it do any of the stuff that webpack
does?" "mostly no, because it's not meant for that" Read the comments on
[https://github.com/denoland/deno/issues/2475](https://github.com/denoland/deno/issues/2475)
to get a sense of what I'm complaining about.

3\. URL Imports. Packages in node.js are stupendously easy to use. Making me
import from a URL instead of typing `yarn add foo` and `import * as foo from
'foo'` does not make my life any easier. It certainly makes the implementation
easier, and I'm glad to see the last of node_modules and path-climbing module
resolution. But the URL-based system offers no equivalent that I can see to
lock files and automatic upgrades (e.g. `yarn upgrade`), which are two crucial
features. This is something that node developers need and want, and if Deno
doesn't provide it, 3rd parties will. My worry is that we'll end up with
competing third-party solutions and a fractured ecosystem, due to Deno's
failure of leadership here.

4\. Stack traces: The single worst thing about using node is the frequency
with which you get utterly useless stack traces that tell you nothing about
the true source of the error. It was easier to debug C++ programs 20 years ago
that it is to debug node.js apps today. But as far as I can tell, deno isn't
making any efforts to improve this. That's ok, they don't have to fix every
problem. But it does make me worry that they don't know what node.js
developers actually care about, if this wasn't on their "must fix" list.

5\. Typescript by default. I really like typescript. I mostly want to use it
instead of javascript these days. But tsc is slow. Slooooooow. Really really
slow. I am worried that most deno programs are going to be very slow to start
up in practice. (Before you say "caching", 99% of the time that you want to
start a program, it's because you just changed the source code. caching can
only do so much in this case). And I am extremely skeptical of the plan to
build a new typescript compiler in rust.

I'll conclude with praising a few things that I am very glad to see: No more
node_modules, Web APIs, and a promise-based stdlib.

------
jariel
"It's important to understand that Deno is not a fork of Node - it's a
completely new implementation. "

New implementation of WHAT? Is this a JS Engine, or a wrapper around V8? Which
version?

Guys - whatever it is - I love it (!!!), but this is a very long and wordy
article that does not well summarize the most relevant things, and uses words,
long explanations for issues that I think are just a little specific.

"First Class Typescript" \- does this mean just 'transpilation at runtime'? Or
does it mean something more hardcore? What does it mean at all?

This could be 1/2 as long a 2x more explanatory and precise.

Finally - it all looks super cool - but why specifically am I interested in
this over things like Node? Speed, security?

Not to take away from the great work.

------
stevehiehn
This is interesting. Can you ship the Deno runtime with your runtime code?
That's the thing that kills me about Javascript; having to assume the consumer
has a runtime setup.

~~~
lucasyvas
Compiling to a single binary is on the roadmap, but was dropped from 1.0

~~~
stevehiehn
Great, thx, I'll definitely be keeping an eye on this project!

------
z3t4
Could take that one step further and run apps from URL's like the browser
does. eg. deno [https://my.app](https://my.app)

------
cdnsteve
Is anyone else excited about a standard library out of the box?

------
morenoh149
I do a lot of django. Does anyone know if it can handle backpressure as
described in the deno announcement? Or is that typically seen only in a
microservices context?

------
todd3834
Is the name Deno a play on shifting noDe over two spaces?

~~~
CawCawCaw
Yes. Maybe the next framework will be called "Done".

------
gridlockd
_" Internally Deno uses Microsoft's TypeScript compiler to check types and
produce JavaScript. Compared to the time it takes V8 to parse JavaScript, it
is very slow"_

TypeScript is way too slow for what it does and that's _ridiculous_ for a
language that rejects useful features because it doesn't want to "stray too
far" from ECMAScript.

In my view, typechecking doesn't belong in the "compiler" part of TypeScript.
It should stay in the IDE. The compiler should just strip type annotations and
do other trivial transformations.

------
tills13
I want that hoodie but $100 is a little steep for me...

------
Jugurtha
This sentence, five paragraphs below, says what this is about:

> _Deno is a new runtime for executing JavaScript and TypeScript outside of
> the web browser._

------
chrismorgan
Pet peeve: programming sites behind Cloudflare protection with email address
protection enabled, because we regularly have things with at signs in them
that aren’t email addresses, which it mangles, ruining my standard no-JS
experience:

    
    
      import { serve } from "https://deno.land/[email protected]/http/server.ts";
    

I mean, std@0.50.0 _is_ a syntactically valid email address, but… protecting
email addresses on _IP addresses_? Why, Cloudflare, why?

------
stackzero
As someone not from a js background, when would I use this? is it a drop in
replacement for node with TS support? or something else

~~~
sintaxi
Deno will likely be well suited for network oriented server-side programs.
Deno is not a drop-in replacement for node. It is an alternative JS runtime.

------
malkia
No. Without some kind of signature check (SHA256 or SHA512 or something more
modern - just say No). it's tempting though :)

------
Avi-D-coder
This is fantastic. I would love to see vscode, coc, kde, gnome and other
applications that use node extensions, to adopt Deno.

------
homakov
Basically better node by creator of node?

~~~
mathiasrw
Yes

------
ausjke
The key is, can it re-use all those npm modules? otherwise the ecosystem is
too large to take on these days.

------
Vinnl
Does anyone know if there's an RSS feed somewhere for posts like these from
the Deno project?

------
pezo1919
What do you think which major projects will use deno in future and which not?

React/React Native/Expo?

------
jppope
Soooooo yea. I'm excited.

(I've been using deno for ~6 months but I'm happy we hit 1.0!!!)

------
angel_j
Waiting for Denodify so I don't have to do anything to switch from node.js

------
soperj
>JavaScript is the most widely used dynamic language

Wouldn't that actually be python?

~~~
mrkurt
There are way more browsers in use than Python runtimes. ;)

------
tiedemann
Seems like a good fit for bundling and/or containerization of js-apps.

------
goofballlogic
Main thing that would prevent me investing in this stack is that the runtime
has been designed with typescript in mind. In a few years if the typescript
thing blows over, you're left with a runtime and conventions skewed toward
statically-typed programming patterns.

~~~
Vinnl
As someone who works with TypeScript extensively, TypeScript patterns are
basically Javascript patterns - although perhaps with slightly fewer runtime
type checks.

------
29athrowaway
Would like to see a comparison between node and deno using http2 and TLS.

------
peartips
This is fantastic news!

------
secondbreakfast
I'm drawn to the simple beauty of the deno.land website.

------
sergiomattei
This is pretty fantastic. excited to try it.

------
ausjke
Installed and run the REPL deno, hit TAB twice there is nothing, node REPL
give you auto-complete but there seems no for deno, not beginner friendly
unfortunately.

------
chintan
Nice. seems Deno is an anagram of Node.

~~~
noisy_boy
In my mind, it came across as Deno(de) :)

------
perlpimp
I remember node stayed 0.11 or some sub 0.* numbers for the longest time.
barely progressing version numbers, anything changed? Just wondering.

~~~
sintaxi
IMHO those were the golden years of developing with node.

------
thayne
> it's clear to us that ultimately the type checking needs to be implemented
> in Rust

I hope this results in a faster typescript compiler.

------
frouge
ELI5: why is this so much upvoted?

------
jslakro
NODE -> * swap * -> DENO

------
onemoresoop
Deno = no de, sorted ascending

------
DroitThemes
Its improved security model

------
the_mango
Added to the resume already

------
mburns
404 not found

~~~
JadeNB
[http://deno.land](http://deno.land) itself (without the trailing `/v1`) seems
to work. It's "a secure runtime for JavaScript and TypeScript".

------
VikingCoder
Hi, I've been thinking for a while that I want something like Deno that has
something like WireGuard built in to it.

1) I make a public / private key pair.

2) I log on to a DNS-like system, and create an account for myself, upload my
public key.

3) I start up a Deno server, giving it my private key, and I give it the
address of the DNS. Deno uses my private key to inform the DNS that it exists
and is serving traffic. (Much like any Dynamic DNS server.)

4) My friend does the same - makes a public / private key pair, finds a DNS he
likes, uploads his public key, makes a Deno server and registers it with the
DNS.

5) My friend and I trade DNS+public keys. It's a URL to the DNS that has the
public key in it.

6) I go to some administrator page on my Deno, it looks a lot like this [1]. I
create a new Connection, and plug in the DNS+public key of my friend. He does
the same on his server.

7) On my admin page, I pick an app that I want to use to communicate with my
friend. I can see a list of my Connections, and I just check off a box that
the app has permission to communicate with that friend.

8) This app that I've picked, it only sees the world through an incredibly
narrow API. It's like WireGuard. Deno handles all of the communication and
permissions, much like Sandstorm.io. The first thing I want is just queued-up
JSON messaging. The app can send and receive JSON messages. I envision that I
want it to be in messaging mode (rather than "streaming online"), so it has
something like ZeroMQ under the hood to pub/sub, client/server, all that. But
roughly it has a bi-directional pipe for sending and receiving JSON and can
queue up messages when the other server is offline.

9) I now have a sandboxed app that can't talk to the rest of the world, has
its own private VPN-like connection to another process. All traffic is
encrypted like WireGuard. The DNS aspect lets my friend move his server if the
IP changes.

I feel like if some project kind of like Sandstorm, kind of like Dynamic DNS,
kind of like WireGuard, and kind of like Deno all got together, they would
make a beautiful thing.

When I think about how I wish Diaspora worked, as a way to replace Facebook,
this is it. I wish it was built on top of something like this. This is the
atomic unit of distributed, yet safe, that I wish internet apps were made out
of. I imagine that I would be setting up hosting of the Deno server nodes for
my friends and family, since I'm their tech support guy. But they'd be in
charge of their own connections and apps in their nodes.

So, HN, time for you to tell me that it's 1) a terrible idea, 2) already
exists, 3) why don't I just make it myself. Right? =)

[1] [https://alpha.sandstorm.io/demo](https://alpha.sandstorm.io/demo)

~~~
z3t4
You can run wireguard in a Linux network namespace, then start the app in that
namespace. You can also use Systemd or Docker.

------
uyuioi
Awesome!

------
raibosome
Nice, I deno about this.

------
oknoorap
Here we go again guys [https://xkcd.com/927/](https://xkcd.com/927/)

------
swah
Why are we still treating dynamic languages as "scripting languages" as if you
can't do the same thing one does in Go?

~~~
Gene_Parmesan
So at this fine grain of semantic detail, making strong statements about
differing labels feels a little silly, but I have always thought that the
difference is dynamic refers to typing, whereas scripting is usually a
reference to the language being interpreted rather than compiled. Dynamically
typed languages can certainly be compiled (I think Clojure qualifies here?).

~~~
IggleSniggle
And in that case, what do we make of QuickJS, which compiles JavaScript to
bytecode?

------
squid_demon
And the very first line of sample code is adding a dependency on someone
else's code.

Reminds me of [https://npm.anvaka.com/#/view/2d/react-
native](https://npm.anvaka.com/#/view/2d/react-native)

Good luck, though. Everyone lives in a different (mental) tribe I suppose...

~~~
kevinkassimo
The very first line of sample code is linking to Deno standard modules,
basically the standard library for Deno, aiming to be feature complete enough
to bring down the side of dependencies

------
fbn79
The claim "TypeScript is an extension of the JavaScript language that allows
users to optionally provide type information" is misleading. Typescript is not
an extension of Javascript (not all javascript code is valid TS code).
Typescript is a subset of Javascript plus mild type checking. For more details
a nice article [https://medium.jonasbandi.net/here-is-why-you-might-not-
want...](https://medium.jonasbandi.net/here-is-why-you-might-not-want-to-use-
typescript-50ab0d225bdd)

~~~
hombre_fatal
This is such a weird point to me, maybe pedantry at best. Typescript is, to
99% of people, just Javascript with types. With few exceptions, TS compiles
1:1 to JS.

That blog article just looks like an intro for beginners who don't quite know
what static typing entails. Yes, static typing is different from runtime
checks, that's why it's static.

~~~
fbn79
The devil is in the detail

------
VWWHFSfQ
I guess I'm wondering why Deno is targeting V8 instead of Servo? Maybe I'm
mistaken, but Servo [0] and Stylo [1] are both production-ready browser
scripting and styling engines implemented in Rust.

[0] [https://servo.org/](https://servo.org/)

[1]
[https://wiki.mozilla.org/Quantum/Stylo](https://wiki.mozilla.org/Quantum/Stylo)

~~~
steveklabnik
You’ve made a category error; Servo is not a JavaScript engine.

~~~
VWWHFSfQ
> Servo is a modern, high-performance browser engine designed for both
> application and embedded use.

What does that mean? "browser engine"

Does it execute JavaScript code?

Edit:

I bought your Rust book on Amazon, supposed to be delivered this Friday. I
can't wait!

~~~
steveklabnik
Servo puts all the parts of a browser together. SpiderMonkey is what Servo
uses to execute JavaScript. That’s shared with Firefox.

Ah cool! I hope you like it! :)

------
censoredbyleft
I won't be using Deno. For starters, I like javascript, not typescript, and I
think Ryan was considering the idea of making Deno TypeScript only at one
time. That is enough for me to never consider it alone.

I think it falls into the same category as Koa (TJs successor to Express) and
the upcoming "Rome" project. Someone creates a successful open-source project
and then at some point in the future decides to make a better one with
questionable tangible benefit and various downsides of its own.

The downsides I can see of Deno so far are that it is slower than node, it is
not compatible with any server-side node code because it has rewritten the
standard library, and it is inspired and based on the Go standard library,
seemingly using Go idioms and so on.

Its benefits are questionable, vague, and not really proven.

------
m00dy
Hi,

I'm the co-founder of [https://deno.services](https://deno.services) . We
would like to make Deno first language in history comes with its own
infrastructure.

~~~
omniscient_oce
Is there much point asking for signups when the only info there is is one
sentence and a screenshot?

~~~
hello_moto
Don't you know? [https://unbounce.com/landing-pages/test-new-products-and-
ide...](https://unbounce.com/landing-pages/test-new-products-and-ideas/) :)

------
cphoover
I think Deno is a mistake at this point... Yes we thank Ryan Dahl for his huge
contributions to integrating libuv and v8 outside of a browser to create
node.js but a lot of work has been created by a huge ecosystem of developers
after this. I think this de-facto fork of node.js will only serve to create
fragmentation, and confuse product owners about which platform to use.

~~~
gutino
If We were all follow your rationale, We will be all programing in COBOL
still. Accept the pain of experiment and growing up.

~~~
cphoover
Sometimes splitting a community is worth it, but it shouldn't be a decision
made lightly. And Ryan Dahl should consider his words bear weight as the
original creator of the platform. I think it's a fair issue for critique.

