<a href="http:&#x2F;&#x2F;deno.land" rel="nofollow">http:&#x2F;&#x2F;deno.land</a> itself (without the trailing `&#x2F;v1`) seems to work. It&#x27;s &quot;a secure runtime for JavaScript and TypeScript&quot;.

it hadn&#x27;t been deployed yet, it&#x27;s up now

&gt; bigger fish to fry&gt; fishI see what you did there, and I approve.

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

I evaluated replacing ts-node with deno but if I use -T and install ts-node globally that seems equivalent to deno to me.I think stepping outside the npm ecosystem is going to be a bigger issue then people think.

There are both ocaml and haskell repls, so it can be done with  languages whose type systems are the focus.  Not sure if there&#x27;s anything specific about typescript that would make it hard, though.

i wonder if it&#x27;s conceivable to ever write typescript in a REPL

I really wish they had docker-compose &#x2F; Terraform support. Just not sure at what point that becomes &quot;free&quot; hosting.

Repl.it recently announced a Deno REPL <a href="https:&#x2F;&#x2F;repl.it&#x2F;languages&#x2F;deno" rel="nofollow">https:&#x2F;&#x2F;repl.it&#x2F;languages&#x2F;deno</a>

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.)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).

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

I suppose that makes sense since loading a module from a file on a disk isn&#x27;t all that different from loading a file over a TCP connection.

there are no &quot;async&quot; or &quot;sync&quot; 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))`)

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.

For this sort of problem Rust&#x27;s safety guarantees don&#x27;t buy you all that much. If you&#x27;re generating machine code and implementing a GC that&#x27;s not the sort of thing that Rust&#x27;s typesystem can prove correct.That said, a rust JS runtime would be amazing just because it&#x27;s easier to integrate into rust projects.

Deno plans to not expose V8 internals, unlike node. I do not know where the V8 vulnerabilities came from, but it should decrease the attack surface.

A note on Deno and the safety of its V8 bindings:&gt; All of the V8 source code is distributed in the crate itself. Finally rusty_v8 attempts to be a safe interface. It&#x27;s not yet 100% safe, but we&#x27;re getting close. Being able to interact with a VM as complex as V8 in a safe way is quite amazing and has allowed us to discover many difficult bugs in Deno itself.We&#x27;ll also have to wait on who will be the first to have a production ready Javascript Engine written in Rust that could replace V8, if you&#x27;re talking about safety.Even with the &quot;safe&quot; bindings, you will still get the same C and C++ vulnerabilities found in V8 that will also be present in Deno.

AFAIK, tsc is just a compiler, not a runtime. Once you compiled, you&#x27;re just executing javascript so it only impacts startup time.ts-node is a runtime able to run TypeScript. It is definitely much much slower at execution, not just at startup time. It&#x27;s useful for hacking around, I use it as a REPL but even for a dev environment it&#x27;s faster to use tsc&#x27;s incremental compilation with a file watcher, and execute the resulting JS

It&#x27;s purely in the compilation step, V8 executes javascript.

What is the ongoing performance cost of using the official TypeScript compiler for long-running applications? Or is this primarily a concern of startup time for scripts and short-lived programs like CLIs?

But we have to admit, that most people will be happy enough with a Node.js with browser APIs.TypeScript is just an extra.

It&#x27;s just compiling TypeScript into JS when you import it, and uses tsc to do it. It can load JS just fine as well if you want to use Babel or similar.

My workaround is to use &#x2F;&#x2F;@ts-ignore above the import, but this is clunky. I just tried Deno and found that TypeScript doesn&#x27;t support .ts extensions yet.

I would rather have Clojurescript than Typescript, but absolutely, less is more, and it feels like a bad idea to tie implementation of this runtime to another dependency.My love of the C++, Java, C#, ad nauseum, lineage of Enterprisey OOP languages turned to hate about 15 years ago, though, so take my assessment with a grain of salt.“C with classes” seemed like a good idea, we were told back in the 80s in school, since garbage collection is impractical. Er, yeah. Worse is better...

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?

Deno really shouldn&#x27;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&#x27;t. This alone means the same code won&#x27;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.

esbuild can compile typescript a couple orders of magnitude faster: <a href="https:&#x2F;&#x2F;github.com&#x2F;evanw&#x2F;esbuild&#x2F;issues&#x2F;81#issuecomment-625083418" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;evanw&#x2F;esbuild&#x2F;issues&#x2F;81#issuecomment-6250...</a>though i think it just strips the typescript annotations. but this may be workable if during dev there&#x27;s some kind of guarantee that the typechecking has already been done.

Massive undertaking is a big understatement. It would be better to not tie into TS&#x2F;Flow and let one of the two biggest tech companies implement the best, fastest typechecker.

&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.&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.&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.

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

Also for the uninitiated, fly.io is migrating to deno for their Serverless functions: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=22621926" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=22621926</a>

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

Some of the bigger previous threads:<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>

&gt; 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 <a href="https:&#x2F;&#x2F;stackoverflow.com&#x2F;questions&#x2F;45022048&#x2F;why-does-npm-install-rewrite-package-lock-json" rel="nofollow">https:&#x2F;&#x2F;stackoverflow.com&#x2F;questions&#x2F;45022048&#x2F;why-does-npm-in...</a> , always baffled me in that it seemed like it could have just been so easily avoided about being explicit when you&#x27;re writing a lockfile vs. when you&#x27;re using it.That said, why not be even MORE explicit about it, i.e. &quot;--use-lock=lock.json&quot; vs. &quot;--write-lock=lock.json&quot;?

This looks really promising.However, it still seems risky to me in case a library is not available. Is there a central repository planned? Or are you expected to vendor everything and ship your project with dependencies included?

Instead of referring to the version could you refer to the hash? Then a simple integrity checker could confirm file changes.

This is something that we&#x27;ll further work out in future versions. For now you can use a lockfile: <a href="https:&#x2F;&#x2F;deno.land&#x2F;manual&#x2F;linking_to_external_code&#x2F;integrity_checking" rel="nofollow">https:&#x2F;&#x2F;deno.land&#x2F;manual&#x2F;linking_to_external_code&#x2F;integrity_...</a>

if you require modules by URL, how does it make sure that the URL always contains the same library?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?

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.

Don&#x27;t you know? <a href="https:&#x2F;&#x2F;unbounce.com&#x2F;landing-pages&#x2F;test-new-products-and-ideas&#x2F;" rel="nofollow">https:&#x2F;&#x2F;unbounce.com&#x2F;landing-pages&#x2F;test-new-products-and-ide...</a> :)

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

clojure.jar comes with tools.deps. It needs jvm as well though.

Hi,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.

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

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?).

What does this comment even mean? I can’t make heads or tails of it.

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?

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

And now, he&#x27;ll make a whole different set of good and bad choices to potentially regret later.

&gt; which we should probably think of as bourne-again node.Or maybe as Perl 6

PM on part of Cloudflare Workers and someone who was in physical attendance for this talk here.They&#x27;re not really directly comparable other than &quot;A JavaScript runtime built on top of V8.&quot;Workers doesn&#x27;t support TS directly, though you can compile TS to JS and run it, of course. (My team maintains a worker and this is what we do, and it works well)Deno has its own APIs, as does Workers. Worker&#x27;s main API is the Service Worker API, Deno&#x27;s is not.Workers is focused on V8 isolates as a means of achieving multi-tenency. I don’t believe Deno does anything specific here.Deno is mostly implemented in Rust, the Workers runtime is written in C++.Deno is open source, Workers is not.Workers is being used at scale in production, Deno just launched its 1.0.I am very excited to see what happens with Deno. :) Fun history: I had been dreaming about doing &quot;Chakra Core + Tokio&quot; a few years back, but didn&#x27;t find the time. I&#x27;m skeptical of the dependency approach Deno is taking, we&#x27;ll see what happens!

&gt; 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.Is it fair to say (a managed) deno is what Cloudflare Workers is? If not, what would be key differences between them?

For context:Deno&#x27;s lead is Ryan Dahl, the creator of Node.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.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.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.Deno&#x27;s development is (presumably) strongly influenced by his experience and furstrations with Node&#x27;s shortcomings in both performance and developer ux.

Keep up the good work, JS weekly is a wonderful resource.

I suppose .land is the new .dev now ;)Am curious how Parallelism could be handled in the runtime? Besides exposing WebWorkers, would shared memory be a possibility? V8 looks like its heading toward a portable WebAssembly SIMD accelerator.&gt;&gt;&gt; Promises all the way downAsync &#x2F; await is a great pattern for render loops by resolving to continuous window.requestAnimationFrame calls. Here is a nifty example computing a Buddhabrot and updating new data quite smoothly:<a href="http:&#x2F;&#x2F;www.albertlobo.com&#x2F;fractals&#x2F;async-await-requestanimationframe-buddhabrot" rel="nofollow">http:&#x2F;&#x2F;www.albertlobo.com&#x2F;fractals&#x2F;async-await-requestanimat...</a>

Hmm, interesting! Thanks for the report. I just ran it through Qualys SSL Labs and everything passed. (We got a B though because we still support TLS 1.1.)It&#x27;s a multi-domain Let&#x27;s Encrypt X3 certificate and I believe most LE users will be in a similar boat now.

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

Root certificate not trusted for <a href="https:&#x2F;&#x2F;denoweekly.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;denoweekly.com&#x2F;</a> on both chrome and firefox.

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 :-DOf 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> :-)

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] <a href="https:&#x2F;&#x2F;duckduckgo.com&#x2F;?t=ffab&amp;q=is+luajit+faster+than+v8+javascript%3F" rel="nofollow">https:&#x2F;&#x2F;duckduckgo.com&#x2F;?t=ffab&amp;q=is+luajit+faster+than+v8+ja...</a>

&gt; Lua is far superiorI disagree with this assessment.

It depends what you mean by &quot;superior&quot;. JavaScript (well v8) is far safer as a scripting runtime. And there are a ton of existing JS libs for solving problems. AND there&#x27;s TypeScript, which is pretty great.

i suspect it is more that the whole world is familiar.

&gt; 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&#x2F;runtime. I suspect the preference for JavaScript is mostly due to the Deno developers&#x27; familiarity and preference.

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

&gt; 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

&gt; It&#x27;s basically the same &quot;exposure&quot; as importing a random npm, but it has the benefit if being explicit when you do it.I&#x27;m not sure how this works in detail here, but at least in NPM you got a chance to download packages, inspect them and fix the versions if so desired. Importantly, this gave you control over your transitive dependencies as well.This seems more like the curl | bash school of package management.Edit: This is explained in more detail at <a href="https:&#x2F;&#x2F;deno.land&#x2F;manual&#x2F;linking_to_external_code" rel="nofollow">https:&#x2F;&#x2F;deno.land&#x2F;manual&#x2F;linking_to_external_code</a> and indeed seems a lot more sane.&gt; It&#x27;s also exactly what the websites you visit do. ;)Well yes, and it causes huge problems there already - see the whole mess we have with trackers and page bloat.

&gt; It&#x27;s basically the same &quot;exposure&quot; as importing a random npm, but it has the benefit if being explicit when you do it.This is definitely false. For all the problems with the NPM registry and the Node dependency situation, an NPM package at a specific version is not just at the whims of whatever happens to be at the other end of a URL at any given moment it&#x27;s requested. This is a huge vulnerability that the Node&#x2F;NPM world does not currently have.

It&#x27;s basically the same &quot;exposure&quot; as importing a random npm, but it has the benefit if being explicit when you do it.It&#x27;s also exactly what the websites you visit do. ;)

The code running in my browser isn&#x27;t a multi-tenant production server, with access to the filesystem and DBs.

Does it also terrify you when code running in a browser does it?

I assume you would just download the packages and serve them yourself.

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.

Yes, lock files: <a href="https:&#x2F;&#x2F;deno.land&#x2F;manual&#x2F;linking_to_external_code&#x2F;integrity_checking" rel="nofollow">https:&#x2F;&#x2F;deno.land&#x2F;manual&#x2F;linking_to_external_code&#x2F;integrity_...</a>

Yup! Deno caches remote imports.<a href="https:&#x2F;&#x2F;deno.land&#x2F;manual&#x2F;linking_to_external_code" rel="nofollow">https:&#x2F;&#x2F;deno.land&#x2F;manual&#x2F;linking_to_external_code</a>

You can also use the built in bundle command to bundle all of your dependencies and your code into a single, easily deployable file. <a href="https:&#x2F;&#x2F;deno.land&#x2F;manual&#x2F;tools&#x2F;bundler" rel="nofollow">https:&#x2F;&#x2F;deno.land&#x2F;manual&#x2F;tools&#x2F;bundler</a>.

Does Deno have some built in way to vendor &#x2F; download the imports pre-execution? I don&#x27;t want my production service to fail to launch because some random repo is offline.

deno requires that you give the process explicitly which permissions it has. I think it&#x27;s much better than praying that a package has not gone rough like with node. If you don&#x27;t trust the remote script, run it without any permission and capture the output. Using multiple process with explicit permissions are much safer.

The convention is to make a `deps.ts` and re-export what you need. Like this: <a href="https:&#x2F;&#x2F;deno.land&#x2F;x&#x2F;collections&#x2F;deps.ts" rel="nofollow">https:&#x2F;&#x2F;deno.land&#x2F;x&#x2F;collections&#x2F;deps.ts</a>I don&#x27;t find versioned URLs much more difficult to work with than package@&lt;version&gt; though.

I&#x27;m wondering about the practicality of importing from URLs. I didn&#x27;t see it addressed, but an import like this will be awfully hard to remember.<pre><code> import { serve } from &quot;https:&#x2F;&#x2F;deno.land&#x2F;std@0.50.0&#x2F;http&#x2F;server.ts&quot;;
</code></pre>
Anyone know if there are alternatives or a plan for this aside from &quot;use an IDE to remember it for you&quot;?

It&#x27;s not just about the integrity. The url may very well provide what they claim to provide, so checksums would match, but it&#x27;s the direct downloading and running of remote code that is terrifying.This is pretty much like all the bash one-liners piping and executing a curl&#x2F;wget download. I understand there are sandbox restrictions, but are the restrictions on a per dependency level, or on a program level?If they are on a program level, they are essentially useless, since the first thing I&#x27;m going to do is break out of the sandbox to let my program do whatever it needs to do (read fs&#x2F;network etc.). If it is on a per dependency level, then am I really expected to manage sandbox permissions for all of my projects dependencies?

One advantage of urls is that you can link to a specific git sha, tag, or branch for a dependency, e.g. on github.

Sure do. I wonder if they have a checksum mechanism like browsers do?You can add an “integrity” attribute to script tags in the browser.<a href="https:&#x2F;&#x2F;developer.mozilla.org&#x2F;en-US&#x2F;docs&#x2F;Web&#x2F;Security&#x2F;Subresource_Integrity" rel="nofollow">https:&#x2F;&#x2F;developer.mozilla.org&#x2F;en-US&#x2F;docs&#x2F;Web&#x2F;Security&#x2F;Subres...</a>

One advantage of having a centralized repository is that the maintainers of that repository have the ability to remove genuinely malicious changes (even if it&#x27;s at the expense of breaking builds). Eliminating the middle man isn&#x27;t always a great thing when one of the people on the end is acting maliciously.

&gt; I thought a lot about it, and it seems as secure as node_modules, because anybody can publish to npm anywaynpm installs aren&#x27;t the same as installing from a random URL, because:* NPM (the org) guarantees that published versions of packages are immutable, and will never change in future. This is definitely not true for a random URL.* NPM (the tool) stores a hash of the package in your package-lock.json, and installing via `npm ci` (which enforces the lockfile and never updates it in any case) guarantees that the package you get matches that hash.Downloading from a random URL can return anything, at the whims of the owner, or anybody else who can successfully mitm your traffic. Installing a package via npm is the same only the very first time you ever install it. Once you&#x27;ve done that, and you&#x27;re happy that the version you&#x27;re using is safe, you have clear guarantees on future behaviour.

I thought a lot about it, and it seems as secure as node_modules, because anybody can publish to npm anyway. You can even depend to your non-npm repo (github, urls...) from a npm-based package.If you want to &quot;feel&quot; as safe, you have import maps in deno, which works like package.json.Overall, I think Deno is more secure because it cuts the man in the middle (npm) and you can make a npm mirror with low effort, a simple fork will do. Which means you can not only precisely pin which code you want, but also make sure nobody knows you use those packages either.Take it with an open mind, a new &quot;JSX&quot; or async programming moment. People will hate it, then will start to see the value of this design down the road.

How is it any different than how it works in the browser?

More than likely programming as a whole will get better because of this...Do you trust this thing? Better off developing it yourself, or working with something you trust then.

CMIIW, wouldn&#x27;t enforced https means you can&#x27;t use intranet or localhost url?

espacially since https is not enforced! <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>

You are not alone, this is very unsafe in my humble opinion.

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

They have ChakraCore (which is js), but the thing about a &quot;TypeScript runtime&quot; is it&#x27;s not that different from a JS runtime. TypeScript is a super set of JavaScript so it already has to do the JS runtime work. v8 is pretty good at that.

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

&gt; I don&#x27;t understand why Microsoft doesn&#x27;t have their own native TypeScript runtime engine by nowwhat would they do with it? ship it in Edge? great, now some small fraction of users can run TS natively. but most can&#x27;t, so everyone would still transpile to JS anyway...it could work if Google did it, but i don&#x27;t think MS has enough market share to have an influence here

ts-node still transpiles under the hood, just as this does.

&gt;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.Look into ts-node. It lets me run and debug the TypeScript itself before transpiling it.

&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.&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.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.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.

IMHO those were the golden years of developing with node.

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

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

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

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?

I like that Deno prefers URLs as module specifiers. Need immutable&#x2F;content-addressed dependency graphs? Publish and consume modules via IPFS.

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&#x27;t give for a JS vm that could do all that. . . .* <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>

Yes it&#x27;s great! My deno projects are really simple directories, `deno run server.ts` is nice and tidy.

Zero processing is a little generous, for things like like ES Module support (and interop), ts-node can be a struggle to get going.

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.

It doesn&#x27;t really help that much with TypeScript native NPM-packages being published with JS and D.TS (TypeScript-definitions) instead of the original source, does it?)

You&#x27;ll like <a href="https:&#x2F;&#x2F;www.npmjs.com&#x2F;package&#x2F;ts-node" rel="nofollow">https:&#x2F;&#x2F;www.npmjs.com&#x2F;package&#x2F;ts-node</a> - it allows zero processing use of typescript

So it&#x27;s an alternative to Node? Sounds incredibly cool, honestly. This:&gt; Supports TypeScript out of the box.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).

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

So, I&#x27;ve never seen this before, but I&#x27;m 99.9% sure that&#x27;s just part of the standard library being imported...

And the very first line of sample code is adding a dependency on someone else&#x27;s code.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>Good luck, though. Everyone lives in a different (mental) tribe I suppose...

&gt; or better yet import from a local fileAnd this is different from NPM how? Except that I&#x27;ve now lost all the tooling around NPM&#x2F;Yarn.

It&#x27;s just a URL right? So could you not mirror the packages to your own server if you&#x27;re so concerned, or better yet import from a local file? Nothing here seems to suggest that packages must be loaded from an external URL.

I think the primary way to manage dependencies should be in a local DIR and optionally, a URL can be specified.The default in Deno is questionable choice. Just don&#x27;t fuck with what works. Default should be safest followed by developers optionally enabling less safe behaviors.

Ah, in this case, I would then have to commit my dependencies into my VCS to maintain reproducible builds. I&#x27;m not sure I like that solution very much either. I&#x27;ve seen node_modules in multiple GBs, and I&#x27;m sure Deno&#x27;s dependency sizes are going to be similar.

That might work for some projects, but can quickly blow up the size of the repo.I don&#x27;t think it it is an unsolvable problem. For example, other solutions could be using a mirror proxy to get packages, instead of directly from the source, or pre-populating the deno dir from an artifact store. It would be nice to have documentation on how to do those though.

Hi!
The response to your fears are in the announcement.
&quot;If you want to download dependencies alongside project code instead of using a global cache, use the $DENO_DIR env variable.&quot;
Then, it will work like node_modules.

You’d deploy builds that include all the dependencies. This isn’t Node where you have to download all deps on your production server, they are built into your deployed files.

Go supports &quot;vendor&quot; folders for storing dependencies locally after initial download. That combined with Go Modules means you can handle everything locally and (I believe) reproducible.

Then you either vendor as others have said, or use the built in bundle tool to produce a single js file of all your code including dependencies.<a href="https:&#x2F;&#x2F;deno.land&#x2F;manual&#x2F;tools&#x2F;bundler" rel="nofollow">https:&#x2F;&#x2F;deno.land&#x2F;manual&#x2F;tools&#x2F;bundler</a>

Several responses to your concern but all of them seem to say &quot;you can cache dependencies&quot;. How does Deno find dependencies ahead of runtime? Does Deno not offer dynamic imports at all?If I have an application that uses, say, moment.js and want to import a specific locale, typically this is done using a dynamic import.

How is this different from requiring npm to be up to install packages?

Reproducible builds, sure. Security? that&#x27;s a different story.<a href="https:&#x2F;&#x2F;github.com&#x2F;ChALkeR&#x2F;notes&#x2F;blob&#x2F;master&#x2F;Gathering-weak-npm-credentials.md" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;ChALkeR&#x2F;notes&#x2F;blob&#x2F;master&#x2F;Gathering-weak-...</a>- node ships with npm- npm has a high number of dependencies- npm does not implement good practices around authentication.Can someone compromise npm itself? probably, according to that article.

You can commit your node_modules folder into your repository if you&#x27;d like.

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.

You&#x27;re right.  We call this &quot;vendoring&quot; your dependencies.  And it&#x27;s a good way to do things.

Why can&#x27;t you download all the packages you use actually with your source code? That&#x27;s how software has been built for decades...I&#x27;m a desktop developer so I understand I&#x27;m the dinosaur in the room but I&#x27;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&#x27;ve not thought about. Is it security? Do you want to get the latest packages automatically? But isn&#x27;t that a security risk as well, as not all changes are improvements?

The dependency management is highly questionable for me. Apart from the security concerns raised by others, I have huge concerns about availability.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?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.

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.

using typescript makes it safer. also i believe we can trust the authors, because, they wrote node (or were heavily involved at the beginning)

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

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

What makes you think Python is more widely used than Javascript?

&gt;JavaScript is the most widely used dynamic languageWouldn&#x27;t that actually be python?

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)

- &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;That&#x27;s exciting! I wonder if that binding is public for end users to use, or if it&#x27;s an internal design

&gt; Deno runs JavaScript faster than nodeYup, and that&#x27;s really cool and exciting. My issue isn&#x27;t with runtime timing. That&#x27;s not what costs me money. Developer time is what costs money, and every change having to &quot;recompile&quot; my already raw JavaScript costs way more than saving 0.02s at runtime.

&gt; 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:<pre><code> echo &quot;console.log(1 + 2)&quot; &gt; 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
</code></pre>
&gt; 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.You can!

Since typescript has no runtime, it doesn&#x27;t really need to be compiled, you just strip away all the type annotations. There are tools like SWC[1] that can process TS in milliseconds if you want to skip the type checking.[1] <a href="https:&#x2F;&#x2F;swc-project.github.io&#x2F;" rel="nofollow">https:&#x2F;&#x2F;swc-project.github.io&#x2F;</a>

I won&#x27;t :PBut in seriousness, Go compiles like lightening for me. But yeah, I think everyone has their own needs when they choose their tools. I choose Node for its speed at development and runtime.

Don&#x27;t ever think of trying a compiled language like C++ or Rust, then :)

Any tips for how to work more functional programming into my TS code? I&#x27;m trying to learn more functional techniques.

I&#x27;m a functional enthusiast and I find it much more enjoyable in TS. There is a lot of cool and interesting functional theory that only relates to types. Having a good type system tht TS provides has also saved me so much time debugging. It&#x27;s invaluable

It&#x27;s the inclusion of TypeScript by default that allows it to have a much nicer developer experience compared to Node&#x2F;NPM.And as others have noted: there&#x27;s no downsides for those who wish to simply use straight JavaScript.

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;.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 &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.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.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.[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.

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.

Sometimes it&#x27;s ok to think &quot;this project isn&#x27;t for me&quot; and just leave it be. The cynical-security-concern act is boring.

For the use-case you describe, your just going to need network access: no file access and no process-forking needed, this is a big surface attack reduction.Moreover Idk how granular the network permission is, but if its implementation is smart, you could block almost all outbound network access except the ones to your DB and the few API you may need to contact.

The manual looks pretty sketchy, but it seems you can limit file access to certain files or directories and that could be used to just give it access to the database and log files.

Both the network and disk access permissions are granular, which means you can allow-write only to your logs folder, and allow net access only to your DB&#x27;s address.

&gt; For that you&#x27;d have to open up network and file access pretty much right off the bat.For the network access I have an issue[0] open that asks to separate permissions to listen on the network from permission to dial. Also, along the way I want to have the ability to let the OS pick the port as an option.Permissions are meant to work by whitelisting. So you wouldn&#x27;t open access to the whole system just to talk to your DB, or to operate on some files.[0] <a href="https:&#x2F;&#x2F;github.com&#x2F;denoland&#x2F;deno&#x2F;issues&#x2F;2705" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;denoland&#x2F;deno&#x2F;issues&#x2F;2705</a>

&gt; That combined with the &#x27;download random code from any url and run it immediately&#x27;, means it&#x27;s going to be much less secure than the already not-that-secure NPM ecosystem.What deno does is move package management away from the framework distribution. This is great - one thing I hate about node is that npm is default and you get only as much security as npm gives you. (You can switch the npm repo, but it&#x27;s still the overwhelming favourite because it&#x27;s officially bundled.)Deno can eventually give you:<pre><code> import lib from &#x27;verified-secure-packages.com&#x27;
 import lib from &#x27;packages.cloudflare.com&#x27;
</code></pre>
So you&#x27;ll be able to pick a snippet repository based on your risk appetite.

If I am building a real world application I&#x27;m going to vet the libraries I use.

&gt; means it&#x27;s going to be much less secure than the already not-that-secure NPM ecosystem.I have only the bare minimum of like, experience with nodejs. Would you mind fleshing out why that is so?

&gt; That combined with the &#x27;download random code from any urlWhat protection does NPM actually give you?Sure, they&#x27;ll remove malware as they find it, but it is so trivially easy to publish packages and updates to NPM, there effectively is no security difference between an NPM module and a random URL. If you wouldn&#x27;t feel comfortable cloning and executing random Github projects, then you shouldn&#x27;t feel comfortable installing random NPM modules.&gt; and run it immediatelyNPM packages also do this -- they can have install scripts that run as the current user, and have network access that can allows them to fetch, compile, and execute random binaries off the Internet.From a security point of view, Deno is just making it clear up-front that you are downloading random code snippets, so that programmers are less likely to make the mistake of trusting a largely unmoderated package repository to protect themselves from malware.I lean towards calling that a reasonably big security win on its own, even without the other sandboxing features.

It&#x27;s always a good idea to run in a container, which limits the ports you can listen on, directories allowed for writing and reading, and can have its own firewall to limit outgoing connections.If you don&#x27;t need the firewall, you can just run in a chroot under a low-privilege user.I mean, if you do otherwise, you are not following best practices and the voice of reason.

&gt; For that you&#x27;d have to open up network and file access pretty much right off the bat.I think that overall you&#x27;re right, but it&#x27;s worth noting that deno can restrict file system access to specific folders and can restrict read and write separately. It&#x27;s plausible to me that you could have a web server that can only access specific folders.

I don&#x27;t think running a public web server application is one of the envisioned use cases here. It looks like a tool for quickly and dirtily getting some job done. But I agree that to get something useful done, you probably need to open up a bunch of permissions, so you&#x27;re still running arbitrary code on your machine.

I don&#x27;t think thats very accurate.
You really need to gi watch the first Deno video made by Ryan Dahl at JSConf.

Looking at the flags, one can envision future updates providing flags for scoping to directories, PIDs, domain&#x2F;IP ranges

See the thing about the sandbox is that it&#x27;s only going to be effective for very simple programs.If you&#x27;re building a real world application, especially a server application like in the example, you&#x27;re probably going to want to listen on the network, do some db access and write logs.For that you&#x27;d have to open up network and file access pretty much right off the bat. That combined with the &#x27;download random code from any url and run it immediately&#x27;, means it&#x27;s going to be much less secure than the already not-that-secure NPM ecosystem.

Servo is an experimental project designed to build and test components that can be integrated into Firefox. It relies on Gecko for JS.

&gt;Servo [0] and Stylo [1] are both production-ready browser scripting and styling engines implemented in Rust.Servo is absolutely not production ready. A couple of particular pieces of Servo, such as Stylo and WebRender, can be considered production-ready, but no so much the project as a whole.

Servo uses Firefox&#x27;s SpiderMonkey, which is written in C++, as its JavaScript implementation.

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.[0] <a href="https:&#x2F;&#x2F;servo.org&#x2F;" rel="nofollow">https:&#x2F;&#x2F;servo.org&#x2F;</a>[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>

Until someone thinks that it should follow redirects which probably leads to the same thing that got apt: <a href="https:&#x2F;&#x2F;justi.cz&#x2F;security&#x2F;2019&#x2F;01&#x2F;22&#x2F;apt-rce.html" rel="nofollow">https:&#x2F;&#x2F;justi.cz&#x2F;security&#x2F;2019&#x2F;01&#x2F;22&#x2F;apt-rce.html</a>Not saying that makes it a bad idea, but importing&#x2F;downloading trusted code over http(s) is not simple even if the protocol sorta is.

Simple solution to the dependency management (spitballing): a directory of files where the filename is the module name. Each file is simply:<pre><code> &lt;url&gt;&lt;newline&gt;&lt;size in bytes&gt;&lt;newline&gt;&lt;hash&gt;
</code></pre>
And then in an application:<pre><code> import { serve } from deno.http.server;
</code></pre>
If you want nested levels so deno.X.X wouldn&#x27;t be a ton of files you could possibly just do nested directories so deno&#x2F;http&#x2F;server would equate to deno.http.server.Most people would want the option to do dependency management on a per-project basis as well. Simply allow a command-line parameter to provide one or more other directories to source from first (besides presumably the global one for your installation).If we wanted the file to be generated automatically, maybe something like this:<pre><code> import { serve } from deno.http.server at &quot;https:&#x2F;&#x2F;deno.land&#x2F;std@0.50.0&#x2F;http&#x2F;server.ts&quot;;</code></pre>

&gt; This seems like an experiment worth trying at least.Yup! I am really excited about Deno and curious about how popular it will be in a few years.

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

Most languages block by default, so backpressure is much easier to model: just don&#x27;t read until you need more data and the sender will block.But in JS the receiving end will just keep firing off data events until you pause it, or use something like reactive streams to request data as you&#x27;re ready for it.That&#x27;s my understanding of the situation at least.

Is this different from how streams work in most other languages, e.g. Java, Go, Python?

They&#x27;re saying since the issue doesn&#x27;t present itself until it&#x27;s too late most code does not use pause().

When describing the input stream back-pressure problem:&gt; 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?

I&#x27;m not sure this is referencing the js api, which will be based around promises like node. I believe this is referencing the rust implementation, which is built on top of tokio and rust&#x27;s async&#x2F;await.

I would call it: &quot;They are essentially using the plain async conversions of regular system calls and Stream (e.g. known from Java&#x2F;.Net) APIs&quot;All the reactive streams stuff still had been push streams, just with some backpressure bolted on. The issue was that without async&#x2F;await, you always end up with some kind of callback model, which then again results in a push model.Whereas with async&#x2F;await you can just mostly model IO like any kind of synchronous IO.

&gt; In Deno, sockets are still asynchronous, but receiving new data requires users to explicitly read()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.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.[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>[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>[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>

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

Sometimes splitting a community is worth it, but it shouldn&#x27;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&#x27;s a fair issue for critique.

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

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.

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

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?

Forget 10000000 packages. Many languages often make use of 10s of packages. If I have several projects, each with around 10 packages, and no automated way to just check if all my projects’ respective dependencies have security updates that could be applied, it seems to go against the stated security goal.Separately I’m not sure what is enforcing this “small dependency graph” aside from making it hard to import things I guess. I wouldn’t be surprised if you end up with the normal behavior of people coming up with cool things and other people importing them.

You have to stop thinking in terms of NPM where it takes 1000000000 packages to do anything. A Deno application is designed to be distributed as a single file. You can override the default behavior to have NPM like stupidity, but if that is really your goal why bother moving to Deno in the first place?

You don’t like checking for security updates?

The Deno solution is either:* A deps.ts that handles all external dependencies and re-exports them* Import mapsNeither of these really give you a way to do the equivalent of &quot;npm update&quot;. But I almost never want to update all my packages at once.

This is explicitly listed as best practice by Deno [1], but it doesn&#x27;t handle the updating problem at all.[1] <a href="https:&#x2F;&#x2F;deno.land&#x2F;manual&#x2F;linking_to_external_code#it-seems-unwieldy-to-import-urls-everywhere" rel="nofollow">https:&#x2F;&#x2F;deno.land&#x2F;manual&#x2F;linking_to_external_code#it-seems-u...</a>

Maybe a convention will arise, that you do all the imports in one file (basically like a `package.json` file) and import that from the rest of your code? It seems hackish to me but could work.

&gt; None of your dependencies can say &quot;hey, I work with versions 1.1 to 1.3 of this dependency&quot;That&#x27;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?

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 &quot;hey, I work with versions 1.1 to 1.3 of this dependency&quot;, 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.

Yes, that is of course the point. There’s an infinite number of possible later versions to check for. The suggestion to poll for new versions using cURL was sarcastic. These “conventions” you speak of actually get handled by... package managers! If not everyone who hosts a package needs to “know” about magic files and make sure they make it following a spec that isn’t enforced by anyone and doesn’t break immediately but rather much later when someone tries to update. It’s like everyone managing their own database row with an informally agreed upon database schema.

Just come up with a convention like host a file called version.ts that lists all available versions. Brute forcing for available versions sounds dumb.

I prefer a unix approach where each tool does a single thing.The runtime does runtime things and someone can build a package manager to do package manager things.The benefit of having runtime + package management bundled into one is you have an opinionated and standard way of doing things - the downside is if the package manager stinks then the whole ecosystem stinks.

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;.

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

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

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.

I view it as a replacement for node that requires less overall handholding and ceremony.

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

Deno 1.0