Deno 1.0

&gt; ... 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.<p>&gt; ...<p>&gt; 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.<p>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.<p>Deno is just doing the same thing a browser does. Like a browser, there&#x27;s nothing that JavaScript running on sandboxed Deno can do that a browser can&#x27;t - in principle. So the security concerns seem a little over the top.<p>The one caveat is that once you open the sandbox on Deno, it appears you open it for all modules. But then again, that&#x27;s what NPM users do all the time - by default.<p>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.<p>This seems like an experiment worth trying at least.

If you&#x27;re getting into Deno and want to keep up with new stuff from the ecosystem on a regular basis, we&#x27;re now publishing <a href="https:&#x2F;&#x2F;denoweekly.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;denoweekly.com&#x2F;</a> .. issue 2 just went out minutes after the 1.0 release. I&#x27;ve been doing JavaScript Weekly for 487 issues now, so this is not a flash in the pan or anything :-D<p>Of course, Deno has an official Twitter account as well at <a href="https:&#x2F;&#x2F;twitter.com&#x2F;deno_land" rel="nofollow">https:&#x2F;&#x2F;twitter.com&#x2F;deno_land</a> :-)

&gt; TSC must be ported to Rust. If you&#x27;re interested in collaborating on this problem, please get in touch.<p>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.<p>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.<p>TSC has done some great architectural changes in the past like doing mostly functional code, rather than lots of classes.<p>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.

The dependency management is highly questionable for me. Apart from the security concerns raised by others, I have huge concerns about availability.<p>In it&#x27;s current form, I&#x27;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&#x27;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?<p>Say what you want about Node&#x27;s dependency management, but atleast I&#x27;m guaranteed reproducible builds, and the only SPOF is the NPM repositories, which I can easily get around by using one of the proxies.

I like what Deno is selling. URL like import path is great, I don&#x27;t know why people are dismissing it. It is easy to get up-and-running quickly.<p>Looks like my personal law&#x2F;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.

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&#x27;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 &quot;<a href="https:&#x2F;&#x2F;whatever.com&#x2F;blah@1.0.1&quot;" rel="nofollow">https:&#x2F;&#x2F;whatever.com&#x2F;blah@1.0.1&quot;</a>, do I just poll to see if &quot;1.0.2&quot; exists? Maybe check for &quot;2.0.0&quot; 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 &quot;- blah: 1.0.1, + blah: 1.0.2&quot;.

Congratulations on the 1.0 release! I&#x27;ve been using Deno as my primary &quot;hacking&quot; runtime for several months now, I appreciate how quickly I can throw together a simple script and get something working. (It&#x27;s even easier than ts-node, which I primarily used previously.)<p>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&#x27;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).

Does anyone else see the import directly from URL as a larger security&#x2F;reliability issue than the currently imperfect modules?<p>I&#x27;m sure I&#x27;m missing something obvious in that example, but that capability terrifies me.

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

It would be great if this line were at the top:<p>&gt;&gt; Deno is a new runtime for executing JavaScript and TypeScript outside of the web browser.

&gt; In Deno, sockets are still asynchronous, but receiving new data requires users to explicitly read()<p>Interesting. If I understand correctly, they&#x27;re essentially using pull streams[0]&#x2F;reactive streams[1]. I compiled a few resources on this topic when I was digging into it a while back[2]. I&#x27;ve found the mental model to be very elegant to work with when needing backpressure in asynchronous systems.<p>As for the dependencies-as-URLs, I don&#x27;t mind it, and may prefer it. I&#x27;ve been experimenting with minimizing my dependencies lately, and vendoring them in git submodules. It&#x27;s worked fairly well.<p>[0]: <a href="https:&#x2F;&#x2F;github.com&#x2F;pull-stream&#x2F;pull-stream" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;pull-stream&#x2F;pull-stream</a><p>[1]: <a href="https:&#x2F;&#x2F;github.com&#x2F;reactive-streams&#x2F;reactive-streams-jvm" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;reactive-streams&#x2F;reactive-streams-jvm</a><p>[2]: <a href="https:&#x2F;&#x2F;github.com&#x2F;omnistreams&#x2F;omnistreams-spec" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;omnistreams&#x2F;omnistreams-spec</a>

Of all the problems with NPM, it being centralized is the last of them imo. Having experienced the mess that is go&#x27;s decentralized dependency management, I&#x27;m not sure why anyone would want to replicate it.<p>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.<p>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.

So it&#x27;s an alternative to Node? Sounds incredibly cool, honestly. This:<p>&gt; Supports TypeScript out of the box.<p>Seems like a small thing, but it has me interested all on its own. It&#x27;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).

One question.<p>&gt; The browser provides APIs for accessing cameras and microphones, but users must first give permission. Deno provides analogous behaviour in the terminal.<p>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&#x27;t seem to find anything about it. I can&#x27;t see anything about it in &quot;The Manual&quot; or in the API reference.<p>Then I thought that there may not be documentation because it just mimics the browser&#x27;s API. Ok, but... there must be some command-line flag to give permission to it, right? Can&#x27;t find it either. Maybe &quot;it was just an example; there&#x27;s no media API just yet&quot;?<p>But then I set out to find available command-line flags in general. And I can&#x27;t find those either. There&#x27;s this [0] but is that <i>all</i>? There&#x27;s just --allow-net, --allow-read and --allow-write? Or is there some other place where the available permission flags are listed?<p>[0] <a href="https:&#x2F;&#x2F;deno.land&#x2F;manual&#x2F;getting_started&#x2F;permissions" rel="nofollow">https:&#x2F;&#x2F;deno.land&#x2F;manual&#x2F;getting_started&#x2F;permissions</a>

&gt; Internally Deno uses Microsoft&#x27;s TypeScript compiler to check types and produce JavaScript. Compared to the time it takes V8 to parse JavaScript, it is very slow.<p>&gt; Early on in the project we had hoped that &quot;V8 Snapshots&quot; would provide significant improvements here. Snapshots have certainly helped but it&#x27;s still unsatisfyingly slow. We certainly think there are improvements that can be done here on top of the existing TypeScript compiler, but it&#x27;s clear to us that ultimately the type checking needs to be implemented in Rust.<p>&gt; 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&#x27;re interested in collaborating on this problem, please get in touch.

&gt;&gt; Internally Deno uses Microsoft&#x27;s TypeScript compiler to check types and produce JavaScript. Compared to the time it takes V8 to parse JavaScript, it is very slow.<p>&gt;&gt; We certainly think there are improvements that can be done here on top of the existing TypeScript compiler, but it&#x27;s clear to us that ultimately the type checking needs to be implemented in Rust.<p>Funny, I was just talking about something like this in an earlier TypeScript discussion today. I was saying that I don&#x27;t understand why Microsoft doesn&#x27;t have their own native TypeScript runtime engine by now.<p>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.<p>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.

Number of things come to mind:<p>- 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?<p>- 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&#x27;t break all applications, etc. Since package locations are hard-coded in the package files, it becomes challenging to do this.<p>The argument that deno is mimicking a browser is thin. Browsers are client side, they don&#x27;t access databases or lives inside your firewall. Server applications are much more sensitive to security issues than browsers.

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.

Congrats to the Deno team and community on reaching 1.0!<p>We&#x27;ve launched Deno support on repl.it here (in beta): <a href="https:&#x2F;&#x2F;repl.it&#x2F;languages&#x2F;deno" rel="nofollow">https:&#x2F;&#x2F;repl.it&#x2F;languages&#x2F;deno</a> for folks to try out.

This is super effing awesome.<p>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&#x27;t give for a JS vm that could do all that. . . .<p>* <a href="https:&#x2F;&#x2F;www.unisonweb.org&#x2F;docs&#x2F;tour" rel="nofollow">https:&#x2F;&#x2F;www.unisonweb.org&#x2F;docs&#x2F;tour</a>

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

For context:<p>Deno&#x27;s lead is Ryan Dahl, the creator of Node.<p>In the past, Dahl&#x27;s expressed regrets over choices he made early on in Node&#x27;s development, and on the direction Node has gone since he left the project many years ago.<p>He bravely presented on this topic at jsconf eu, 2018: <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=M3BM9TB-8yA" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=M3BM9TB-8yA</a>, it&#x27;s a fantastic talk.<p>The last 10 minutes are a pitch for what a &quot;better Node&quot; 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.<p>Deno&#x27;s development is (presumably) strongly influenced by his experience and furstrations with Node&#x27;s shortcomings in both performance and developer ux.

This project looks really cool to me.<p>I&#x27;m glad the link to the video is there, because my intuition about pronouncing the name was incorrect.<p>It looks like it could be &quot;deeno&quot; OR &quot;denno&quot;, and I was pushed to the former by the presence of the dinosaur graphic. Isn&#x27;t that old fashioned dinosaur on the Flinstones pronounced deeno? Anywho... good name overall: short, no collisions (i think?), and no strong baseline associations.<p>And only right this instant am I realizing that this is an anagram of node... oh my god i&#x27;m slow. Now it&#x27;s a <i>great</i> name.

- &quot;Rust has its own promise-like abstraction, called Futures. Through the &quot;op&quot; abstraction, Deno makes it easy to bind Rust future-based APIs into JavaScript promises.&quot;<p>That&#x27;s exciting! I wonder if that binding is public for end users to use, or if it&#x27;s an internal design

Given that all API calls in JS have to go through the interpreter, couldn&#x27;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&#x27;s token wouldn&#x27;t match the API interfacing object&#x27;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.<p>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.

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&#x27;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.<p>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.

&gt; 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.<p>Under-mentioned feature. I may migrate my personal site to Deno just for that latency drop.

if you require modules by URL, how does it make sure that the URL always contains the same library?<p>I&#x27;ve read the docs and it says it caches on the initial execution and doesn&#x27;t update unless it&#x27;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?

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.<p>The initial thing is the fear &quot;whoa, that is hella insecure!&quot; 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)<p>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&#x27;m missing something and it isn&#x27;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&#x27;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&#x27;s caching <a href="https:&#x2F;&#x2F;www.mnot.net&#x2F;blog&#x2F;2017&#x2F;03&#x2F;16&#x2F;browser-caching" rel="nofollow">https:&#x2F;&#x2F;www.mnot.net&#x2F;blog&#x2F;2017&#x2F;03&#x2F;16&#x2F;browser-caching</a><p>Finally, in NPM&#x27;s system if a module I&#x27;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&#x27;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&#x27;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.<p>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&#x27;m unnecessarily worried so if that someone is you (the reader of this long post) you can maybe assuage my worries.

What is the reason for making a JavaScript runtime based on browser APIs that cannot also be a browser?<p>Or in other words, wouldn&#x27;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?<p>The choice made means that Deno can&#x27;t be used, at least directly, to make desktop applications, and also doesn&#x27;t have all the features that browsers have for free, like multiprocess and multiple sandboxes, network traffic inspector, local storage, GPU compute, etc.

I feel explicit location imports are a step backwards. Node ecosystem is moving toward workspaces and Yarn Plug&#x27;N&#x27;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.<p>Sure, I guess you could shim it somehow like is happening in the node ecosystem but then.. I&#x27;m not sure what the stock situation brings to the table TBH.

As a functional developer who doesn&#x27;t care for TypeScript in any way, it&#x27;s frustrating to see Deno has it &quot;built-in&quot;.<p>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.<p>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 &quot;compiles&quot; my &quot;TypeScript&quot;. (Again I don&#x27;t write TypeScript so I don&#x27;t need this feature). I should note, subsequent runs will be faster, but as I&#x27;m developing I don&#x27;t want delays between my runs.<p>Since it&#x27;s not even native TypeScript, it&#x27;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&#x27;ve always done.<p>Anyway, I&#x27;m very interested in the fact it&#x27;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.<p>[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&#x27;t have to use it completely mitigates my main concern.

Just a random though but if they want speed they could consider making a typescript JIT instead of typescript -&gt; javascript. Typed languages <i>can</i> run much faster than untyped. Maybe that&#x27;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.

Won’t Meteor.js make this project extinct?

I predict cdnjs&#x2F;jsdelivr types will explode in use for Deno packages since they can make bandwidth and security guarantees behind what&#x27;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&#x27;m missing something.

If you need a server framework for Deno, please take a moment to check out Pogo. It&#x27;s got a powerful and friendly API. It also has the best documention and plenty of tests.<p><a href="https:&#x2F;&#x2F;github.com&#x2F;sholladay&#x2F;pogo" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;sholladay&#x2F;pogo</a>

What exactly does Deno do? I still can&#x27;t figure it out: is it a secure version of Node, if so, how?

Some of the bigger previous threads:<p><a href="https:&#x2F;&#x2F;hn.algolia.com&#x2F;?dateRange=all&amp;page=0&amp;prefix=true&amp;query=Deno%20&amp;sort=byPopularity&amp;type=story" rel="nofollow">https:&#x2F;&#x2F;hn.algolia.com&#x2F;?dateRange=all&amp;page=0&amp;prefix=true&amp;que...</a>

Well, there is a known MITM vuln in Deno by design and the team refuses to fix it soooooo<p>REF: <a href="https:&#x2F;&#x2F;github.com&#x2F;denoland&#x2F;deno&#x2F;issues&#x2F;1063" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;denoland&#x2F;deno&#x2F;issues&#x2F;1063</a>

I am a long-time Node.js user. My question about Deno is &quot;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?&quot;<p>I think evolution &amp; starting over can both be appropriate steps forward, I don&#x27;t question the Deno project, but to have the <i>exact same</i> people who created Node.js say &quot;OK here&#x27;s the <i>new</i> new JS hotness,&quot; I think &quot;how can we expect this time to be different&quot; is a reasonable question. Or perhaps these ecosystems are not meant to last&#x2F;be supported more than 10ish years?

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.

Is there some deterministic way of measuring JS execution time?<p>Explanation for why I want that:<p>I&#x27;ve started making an game RTS game - think starcraft but you can program your units.<p>Currently I&#x27;m trying to decide what language to expose to players. The two main requirements are that it&#x27;s secure (I&#x27;ll be running player A&#x27;s code on player B&#x27;s computer) and that it has a deterministic method of counting execution time (so that player A and player B&#x27;s computer can both make the same decision on whether or not a script took too much time).<p>I&#x27;d appreciate any hints towards other languages I should look at as well.

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

Even if this new thing has slightly nicer syntax or usage of promises or whatever, does this alone justify it&#x27;s existence? Learning all this new tooling and ecosystem all over again? Dividing the web development ecosystem even more? I really don&#x27;t see how the problem it&#x27;s solving is big enough for us to care really. I mean - enough already. In 8 years I&#x27;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 -&gt; Deno -&gt; Dynamite?

Question:<p><pre><code> deno run https:&#x2F;&#x2F;deno.land&#x2F;std&#x2F;examples&#x2F;welcome.ts </code></pre> This works - it downloads the code from that URL, then compiles and runs it.<p>But if you visit <a href="https:&#x2F;&#x2F;deno.land&#x2F;std&#x2F;examples&#x2F;welcome.ts" rel="nofollow">https:&#x2F;&#x2F;deno.land&#x2F;std&#x2F;examples&#x2F;welcome.ts</a> in your browser you get back HTML, not raw code.<p>Anyone know how this works? Is deno.land a special case or is there some Accept header cleverness or something going on?

Some people for the last decade: wouldn&#x27;t it be great if node had a comprehensive, idiomatically coherent, thoroughly typed standard library ? Look, typescript is right here !<p>No-one, at all, for the love of jeebus: Do another node-like thing, but make it in rust <i>on top</i> 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&#x2F;module system.

I don&#x27;t understand how Promises help with backpressure.

So I can import using the URL &quot;<a href="https:&#x2F;&#x2F;somekind.com&#x2F;ofpackage.ts&quot;" rel="nofollow">https:&#x2F;&#x2F;somekind.com&#x2F;ofpackage.ts&quot;</a>, that&#x27;s great but what if that random endpoint changes?<p>The benefit of NPM is that every package version is immutable...<p>Also first class Typescript support is great, but they are just using tsc internally... isn&#x27;t that directly tying a typescript version to the DENO version?

I&#x27;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&#x27;t you simply do this already by changing the package.json and swapping the npm identifier with a URL to the repo?<p>You can already do decentralisation with npm by simply not using`npm i some-package --save` and instead, modify the package.json yourself.<p>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??<p>That&#x27;s just insane, I get the whole idea of decentralisation but why can&#x27;t we concentrate all packages into a single file??<p>Sire this is all good for distribution because you won&#x27;t have to run `npm i` every time you want to run your program, but more often than not, I&#x27;m the one that&#x27;s going to use my program and I don&#x27;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..

&gt; We believe JavaScript is the natural choice for dynamic language tooling; whether in a browser environment or as standalone processes.<p>I disagree with this assessment. Lua is still far superior as an embed-able scripting language&#x2F;runtime. I suspect the preference for JavaScript is mostly due to the Deno developers&#x27; familiarity and preference.

&gt; TSC must be ported to Rust. If you&#x27;re interested in collaborating on this problem, please get in touch.<p>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.

&gt; We seek a fun and productive scripting environment that can be used for a wide range of tasks.<p>So Lua, but Javascript? Could be neat

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&#x27;re doing anything with Javascript. If I wanted deal with repetitive code like &quot;function add(x: number, y: number): number {...}&quot; I&#x27;d just use Java. There&#x27;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...<p>I like that Deno is resetting some of the underlying assumptions that Dahl made in Node. But I think he&#x27;s throwing the baby out with the bath water. I actually <i>like</i> 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&#x2F;replace all the imports? Seems very odd unless I&#x27;m missing something big. Also, not a fan of the hidden .deno cache directory, but whatever.<p>Having to send along a shell script in order to even <i>start</i> an app is another problem. &quot;Here&#x27;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&#x27;t forget them, I&#x27;ve included various shell scripts you can run depending on your platform.&quot; That&#x27;s not improving anything.

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?<p>Clearly without packages we are not going to use deno. Also I don&#x27;t want to switch from well-proven packages like express&#x2F;koa to an new unknown http server just because it supports deno.

&gt; for await (const req of serve({ port: 8000 })) { &gt; req.respond({ body: &quot;Hello World\n&quot; }); &gt; }<p>It&#x27;s not the first time I see js iterators used and abused this way, and every time I feel that js and it&#x27;s users are ready for full-blown monads and do notation instead.

First-class TypeScript support is the thing that excites me the most about this. It&#x27;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.

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?

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

For anyone that&#x27;s interested, here&#x27;s a list of projects I&#x27;m interested in or use with new major versions in 2020: <a href="http:&#x2F;&#x2F;maker.sh&#x2F;2020" rel="nofollow">http:&#x2F;&#x2F;maker.sh&#x2F;2020</a>

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&#x27;t ready for it. I might revisit in a year or two.

I don&#x27;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:<p>1. The sandboxing via --allow-net, --allow-fs, etc is very odd to me. I don&#x27;t recall hearing about a lot of security issues that could have been prevented by this. I mean, I suppose this won&#x27;t hurt anyone, but it&#x27;s certainly never something that I&#x27;ve wanted. I expect most people will simply white-list most access by default in all new projects.<p>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: &quot;we don&#x27;t want bundlers anymore, so we&#x27;re making deno bundle, the one true bundler!&quot; &quot;does it do any of the stuff that webpack does?&quot; &quot;mostly no, because it&#x27;s not meant for that&quot; Read the comments on <a href="https:&#x2F;&#x2F;github.com&#x2F;denoland&#x2F;deno&#x2F;issues&#x2F;2475" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;denoland&#x2F;deno&#x2F;issues&#x2F;2475</a> to get a sense of what I&#x27;m complaining about.<p>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 &#x27;foo&#x27;` does not make my life any easier. It certainly makes the implementation easier, and I&#x27;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&#x27;t provide it, 3rd parties will. My worry is that we&#x27;ll end up with competing third-party solutions and a fractured ecosystem, due to Deno&#x27;s failure of leadership here.<p>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&#x27;t making any efforts to improve this. That&#x27;s ok, they don&#x27;t have to fix every problem. But it does make me worry that they don&#x27;t know what node.js developers actually care about, if this wasn&#x27;t on their &quot;must fix&quot; list.<p>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 &quot;caching&quot;, 99% of the time that you want to start a program, it&#x27;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.<p>I&#x27;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.

&quot;It&#x27;s important to understand that Deno is not a fork of Node - it&#x27;s a completely new implementation. &quot;<p>New implementation of WHAT? Is this a JS Engine, or a wrapper around V8? Which version?<p>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.<p>&quot;First Class Typescript&quot; - does this mean just &#x27;transpilation at runtime&#x27;? Or does it mean something more hardcore? What does it mean at all?<p>This could be 1&#x2F;2 as long a 2x more explanatory and precise.<p>Finally - it all looks super cool - but why specifically am I interested in this over things like Node? Speed, security?<p>Not to take away from the great work.

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

Could take that one step further and run apps from URL&#x27;s like the browser does. eg. deno <a href="https:&#x2F;&#x2F;my.app" rel="nofollow">https:&#x2F;&#x2F;my.app</a>

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

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?

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

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

This sentence, five paragraphs below, says what this is about:<p>&gt; <i>Deno is a new runtime for executing JavaScript and TypeScript outside of the web browser.</i>

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:<p><pre><code> import { serve } from &quot;https:&#x2F;&#x2F;deno.land&#x2F;[email protected]&#x2F;http&#x2F;server.ts&quot;; </code></pre> I mean, std@0.50.0 <i>is</i> a syntactically valid email address, but… protecting email addresses on <i>IP addresses</i>? Why, Cloudflare, why?

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

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

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

Basically better node by creator of node?

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

Does anyone know if there&#x27;s an RSS feed somewhere for posts like these from the Deno project?

What do you think which major projects will use deno in future and which not?<p>React&#x2F;React Native&#x2F;Expo?

Soooooo yea. I&#x27;m excited.<p>(I&#x27;ve been using deno for ~6 months but I&#x27;m happy we hit 1.0!!!)

Waiting for Denodify so I don&#x27;t have to do anything to switch from node.js

&gt;JavaScript is the most widely used dynamic language<p>Wouldn&#x27;t that actually be python?

Seems like a good fit for bundling and&#x2F;or containerization of js-apps.

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&#x27;re left with a runtime and conventions skewed toward statically-typed programming patterns.

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

This is fantastic news!

I&#x27;m drawn to the simple beauty of the deno.land website.

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.

This is pretty fantastic. excited to try it.

Nice. seems Deno is an anagram of Node.

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

&gt; it&#x27;s clear to us that ultimately the type checking needs to be implemented in Rust<p>I hope this results in a faster typescript compiler.

ELI5: why is this so much upvoted?

NODE -&gt; * swap * -&gt; DENO

Deno = no de, sorted ascending

Its improved security model

Added to the resume already

404 not found

Hi, I&#x27;ve been thinking for a while that I want something like Deno that has something like WireGuard built in to it.<p>1) I make a public &#x2F; private key pair.<p>2) I log on to a DNS-like system, and create an account for myself, upload my public key.<p>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.)<p>4) My friend does the same - makes a public &#x2F; private key pair, finds a DNS he likes, uploads his public key, makes a Deno server and registers it with the DNS.<p>5) My friend and I trade DNS+public keys. It&#x27;s a URL to the DNS that has the public key in it.<p>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.<p>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.<p>8) This app that I&#x27;ve picked, it only sees the world through an incredibly narrow API. It&#x27;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 &quot;streaming online&quot;), so it has something like ZeroMQ under the hood to pub&#x2F;sub, client&#x2F;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.<p>9) I now have a sandboxed app that can&#x27;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.<p>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.<p>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&#x27;m their tech support guy. But they&#x27;d be in charge of their own connections and apps in their nodes.<p>So, HN, time for you to tell me that it&#x27;s 1) a terrible idea, 2) already exists, 3) why don&#x27;t I just make it myself. Right? =)<p>[1] <a href="https:&#x2F;&#x2F;alpha.sandstorm.io&#x2F;demo" rel="nofollow">https:&#x2F;&#x2F;alpha.sandstorm.io&#x2F;demo</a>

Awesome!

Nice, I deno about this.

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:<p>&gt; error[E0433]: failed to resolve: use of undeclared type or module `proc_macro` --&gt; &#x2F;home&#x2F;user&#x2F;.cargo&#x2F;registry&#x2F;src&#x2F;github.com-1ecc6299db9ec823&#x2F;swc_ecma_visit_macros-0.1.0&#x2F;src&#x2F;lib.rs:25:20 | 25 | pub fn define(tts: proc_macro::TokenStream) -&gt; proc_macro::TokenStream { | ^^^^^^^^^^ use of undeclared type or module `proc_macro`<p>error[E0433]: failed to resolve: use of undeclared type or module `proc_macro` --&gt; &#x2F;home&#x2F;user&#x2F;.cargo&#x2F;registry&#x2F;src&#x2F;github.com-1ecc6299db9ec823&#x2F;swc_ecma_visit_macros-0.1.0&#x2F;src&#x2F;lib.rs:25:48 | 25 | pub fn define(tts: proc_macro::TokenStream) -&gt; proc_macro::TokenStream { | ^^^^^^^^^^ use of undeclared type or module `proc_macro`<p>error: aborting due to 2 previous errors<p>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 `&#x2F;tmp&#x2F;cargo-installFIkSV2`<p>Caused by: build failed

<i>&quot;Internally Deno uses Microsoft&#x27;s TypeScript compiler to check types and produce JavaScript. Compared to the time it takes V8 to parse JavaScript, it is very slow&quot;</i><p>TypeScript is way too slow for what it does and that&#x27;s <i>ridiculous</i> for a language that rejects useful features because it doesn&#x27;t want to &quot;stray too far&quot; from ECMAScript.<p>In my view, typechecking doesn&#x27;t belong in the &quot;compiler&quot; part of TypeScript. It should stay in the IDE. The compiler should just strip type annotations and do other trivial transformations.

Here we go again guys <a href="https:&#x2F;&#x2F;xkcd.com&#x2F;927&#x2F;" rel="nofollow">https:&#x2F;&#x2F;xkcd.com&#x2F;927&#x2F;</a>

Why are we still treating dynamic languages as &quot;scripting languages&quot; as if you can&#x27;t do the same thing one does in Go?

And the very first line of sample code is adding a dependency on someone else&#x27;s code.<p>Reminds me of <a href="https:&#x2F;&#x2F;npm.anvaka.com&#x2F;#&#x2F;view&#x2F;2d&#x2F;react-native" rel="nofollow">https:&#x2F;&#x2F;npm.anvaka.com&#x2F;#&#x2F;view&#x2F;2d&#x2F;react-native</a><p>Good luck, though. Everyone lives in a different (mental) tribe I suppose...

The claim &quot;TypeScript is an extension of the JavaScript language that allows users to optionally provide type information&quot; 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 <a href="https:&#x2F;&#x2F;medium.jonasbandi.net&#x2F;here-is-why-you-might-not-want-to-use-typescript-50ab0d225bdd" rel="nofollow">https:&#x2F;&#x2F;medium.jonasbandi.net&#x2F;here-is-why-you-might-not-want...</a>

I guess I&#x27;m wondering why Deno is targeting V8 instead of Servo? Maybe I&#x27;m mistaken, but Servo [0] and Stylo [1] are both production-ready browser scripting and styling engines implemented in Rust.<p>[0] <a href="https:&#x2F;&#x2F;servo.org&#x2F;" rel="nofollow">https:&#x2F;&#x2F;servo.org&#x2F;</a><p>[1] <a href="https:&#x2F;&#x2F;wiki.mozilla.org&#x2F;Quantum&#x2F;Stylo" rel="nofollow">https:&#x2F;&#x2F;wiki.mozilla.org&#x2F;Quantum&#x2F;Stylo</a>

I won&#x27;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.<p>I think it falls into the same category as Koa (TJs successor to Express) and the upcoming &quot;Rome&quot; 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.<p>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.<p>Its benefits are questionable, vague, and not really proven.

Hi,<p>I&#x27;m the co-founder of <a href="https:&#x2F;&#x2F;deno.services" rel="nofollow">https:&#x2F;&#x2F;deno.services</a> . We would like to make Deno first language in history comes with its own infrastructure.

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.