Hacker News new | past | comments | ask | show | jobs | submit login
Deno 1.14 (deno.com)
257 points by sondr3 39 days ago | hide | past | favorite | 108 comments

I tried out Deno last weekend for a fun little hack project (syncing a local Markdown file to a formatted Google Doc), and it was awesome.

Writing TypeScript code for Deno feels a lot like writing Go (which is a very good thing to me):

- opinionated build/fmt/deps

- well-designed stdlib

- no need for scaffolding files (.eslintrc, babel.config.js, jest.config.js, mocha.opts, etc.)

If that sounds good to you, try Deno!

I also tried it out recently, because I wanted to make a small utility for myself and liked the idea of it providing a single executable (and bypassing the node/NPM ecosystem for learning a JS/TS based system appealed to me). It delivered on that beautifully, as all I did is switch from running "deno run" as I was for testing to "deno compile" and it delivered to me exactly what I was looking for. A bit large at 57 MB but that's not too bad for a fully bundled JS runtime and no library dependencies except glibc that I could see.

As someone that's barely touched node for dev and always been put off by NPM and how that works (and the heavy build chain for some stuff), I find it much more palatable.

That's interesting.

57mb is big, but not an issue when it's for personal use.

Somewhat related, I haven't used rust, but I read that it can produce an executable including the run time for edge that is less than 1mb,. I couldn't find the source, but this article shares how an extension was reduced from 12mb to 4.5mb.

> 57mb is big

Honestly, I think most the time you're looking at 10MB+ for interpreted languages that are turned into executables (through a bundling of the runtime and scripts, that is, not through compiling to something else which is likely much smaller if offered).

The complexity and size of the runtime is going to necessarily influence that size. V8 is fairly complex compared to most runtimes I think, with the JVM and maybe Mono being notable exceptions, and if you were to bundle the JVM with an app instead of just expecting them to have it installed, I imagine that would be quite large as well.

> Somewhat related, I haven't used rust, but I read that it can produce an executable including

That's actually the other thing I wanted to do with the project I built in Deno. Since it was very simple, but actually useful for me, I was also going to implement it in Rust. I've played with it a few times over the years, but never really had anything real that needed to be built in it, so this seemed like a good chance to build something real in it.

In case anyone is wondering because I mentioned it twice, the project is just reading an ini file which defines browsers, pattern matches to apply to URLs to determine which browser to load based on the URL, and a default browser. The idea being that I can send work URLs to the browser I dedicate to work that's proxied through a SOCKS connection, and other URLs get handled automatically by the browser I use for personal stuff, and I can just make the application my default URL handler. Dead simple, but very useful for my current workflow.

If you happen to be on mac, there's an app called finicky that does this. It can also pattern match on source application which is pretty handy.

I'm not, but that's nice. Pattern matching on the source application is actually what I would have preferred (and what I kept looking to see if anything on Windows could provide), but never found anything. Matching on the URL actually works well enough though, which I know because my prior workflow was just a work container tab in Firefox with the Container Proxy extension to proxy only those tabs in that container, and work URLs were set to prefer that Firefox container.

I was actually fairly happy with that, but it's nice to just be able to close the chrome instance with all the work tabs at the end of the day and have them all reopen when I start it up the next day, and all my work tabs are self contained and proxied through work. The only downside is I can't just click to open in Teams or Outlook, and need to copy the link and manually open it in Chrome, which is what I was aiming to fix.

Much appreciated! The first looks to be an example of how to register the handler through an installer, instead of the registry hack I'm doing (since MS only wants things actually installed and visible in Add/Remove programs to be protocol handlers, for obvious reasons, even if annoying), and the second isn't barely related, it's looks to be essentially the same thing but in C. Here's mine for comparison: https://github.com/kbenson/urlswitcher-deno

Does the fact that you didn't need Npm mean that Deno has a suffciently large built-in library that a thing like Npm is in most cases not needed?

Honestly, I'm not sure. My needs were very minimal, one Deno stdlib import, and one third party module import (for ini file parsing). https://deno.land/x/ has their third party module ecosystem, but it's all just JS in the end, so I think think there's anything making it so you couldn't use the NPM ecosystem.

I found this article[1] which seems to indicate if the node packages use ES modules you can use import them as is, or if not it says JSPM can help with that.

1: https://medium.com/samsung-internet-dev/using-node-modules-i...

It's also great for scaffolding CRUD sites. I used it a while ago on a MERN stack project in order to loop over a directory of game files -- Stepmania simfiles if anyone's wondering -- cleaning them up, parsing their metadata, and then POSTing it to my Express server. While I didn't avail myself of its CSV/YAML/etc parsing (JSON was a builtin and is now a third-party library), the stdlib's walk function made this generally painless.

And to top it off there's yet another bonus to this approach: having Fetch included out of the box enabled me to mock out what eventually became my frontend requests, by running them headlessly and worrying about the form logic later.

I haven't actually gotten to using TypeScript with it personally (it's among a few things built into Deno that I've been meaning to try now that I can run them with zero config), but when writing JS I've found myself reaching for it in some of the same scenarios I (anecdotally) see people point to for Python -- bulk file manipulation, scraping, programmatic requests, etc.

Checking Deno out for my next project. I'm a recent typescript convert after working on a full JS team.

The types feel soooooo good.

Is it fast to start up? I have been using node with ts-node, and it takes a couple of seconds before it can start executing the actual code.

Yeah - it is very fast. You can specify a --no-check flag which makes it even faster.

mind sharing that project? I have a similar need.

you got me at no need for scaffolding files babel.config.js reply

It's always worth reading the Deno release notes even if you're not using Deno because it's such a fascinating collection of interesting ideas.

I always learn something new from them.

In this case it was the existence of the URLPattern web API: https://pr8734.content.dev.mdn.mozit.cloud/en-US/docs/Web/AP...

Also that Mutual TLS is an alternative term for client authentication.

> Also that Mutual TLS is an alternative term for client authentication

Mutual TLS is where both the server and the client must present certificates and both must verify the others' certificate in order for them to communicate. It's useful for backend server to server communications mainly.

One of the most exciting opportunities IMO that Deno opens up, compared to most traditional server-side frameworks, is the possibility for simple url-based live-reload workflows in production.

I'd love to be able to develop backend services by pushing source code to some url as I develop, and then have the production instances of the service notified of the changes and reload themselves immediately for a super-tight feedback loop.

In theory, building this kind of workflow in Deno should be very feasible, so I'm hoping to give it a shot in the not too distant future, but I'm wondering if anyone else has already tried it?

This is a really old concept with interpreted languages, Capistrano in Ruby came out in 2006 for this sort of workflow:

10 year old gist for this exact thing:

Same exists in Node, using PM2 process monitor via rsync/ssh:

Run a command, new code is pushed to server files, you have a file-watcher daemon monitoring the directory and stopping + restarting the app, or you run stop/start as part of the deploy command.

Arguably, this is the model of CGI, which is about a decade older. Every time you hit a page on a CGI-powered service, it starts up a new process that runs your script. So you just edit a shell/Perl/PHP/Python/etc. file in place (or edit it locally, and FTP/SCP/etc. it to the remote host) and immediately on the next page load you see the impact of your change.

It was kind of the original "serverless" - you'd often host it on a shared (multitenant) server with other users, with someone operating the web server for you and providing you with storage space. And it was a great development experience for small sites, especially for people new to web programming, and I miss it a lot.

For performance reasons people built "FastCGI" where you have a long-running process that handles multiple requests, and for software engineering scaling reasons people moved away from the model of one file on disk per URL (and URLs mostly mapping to file paths on disk), and then eventually we got the setup we have now.

Thanks for sharing! I have to admit that I am probably very ignorant of backend dev paradigms in general since I got my start in frontend dev. Definitely cool to see that I'm not anywhere close to the first one to find this kind of workflow compelling.

IMO the possibility for an air-tight feedback loop is _the_ killer feature for interpreted languages vs compiled ones. I can always feel my productivity plummet whenever I work in an environment that takes that away from me. I wish more people would try to take advantage of it.

Some frameworks will offer this as part of the development process with a development server. Mojolicious (Perl) for example ships with Morbo as a development webserver, and Hypnotoad as a more enterprise ready one. One of the major differences is that morbo will take a path and auto-reload if any file in it updates, while hypnotoad offers zero downtime reloads, but you have to manually tell it to restart.

Arguably a delineation like this is better, even if just a single flag separating the behavior in the server, since it allows production to not worry about some file copies/changes forcing lots of reloads that aren't needed, which isn't really a problem in most development environments.

This is the biggest upside I see for Deno. I imagine a lot of fat could be trimmed in service orchestration with something that simply resembles a headless browser, and all it takes to deploy new code to your running service is giving it the equivalent of an `f5` and you're on your way.

Heck lets get this headless browser running in Ring 0 and skip to the end of Gary Bernhardt's dream.

I built this https://webcode.run/

This looks super dope. I also love Observable and have wanted to find more ways to leverage it. This seems perfect!

Does anyone know if Deno has undergone a security audit yet? I'm interested in using it as a sandbox to run user-submitted JS, and I know its permission model is powerful, but I don't know if it is formally certified (if that's even a thing) and if you can prove that there can't be some exploit that can be used to break out of the sandbox.

If you’re thinking of V8 isolates, I believe Cloudflare was running their edge compute product using that.

Oh interesting, do they talk about this somewhere? Is there a conference talk or blog post?

Has Node undergone such scrutiny? Honest question.

You don't need to test a feature that they don't have

Funny, I was just looking into whether I could add a Deno config file to my project. Nice to know this was just made possible!

Can you share a bit on the use case, i.e. what do you need configured?

Personally, I find Deno's "zero config" approach appealing, although I do have to fight the linter's "ban-types" rule occasionally since suggested type replacements are not equivalent.

> Personally, I find Deno's "zero config" approach appealing, although I do have to fight the linter's "ban-types" rule occasionally since suggested type replacements are not equivalent.

Precisely this. I'm compiling TS using `Deno.emit()`, which can be directly configured, but it would be nice to just configure Deno's linting/compiling behavior at the project level so that the same issues don't appear in VS Code with the Deno extension.

Please open an issue on denoland/deno_lint with examples so we can make the diagnostic messages more useful.

Thanks, I usually do, but in this case they are typescript issues and have tickets in the ts repo.

For example, constructor signature for mixins requires `any` type that conflicts with `no-explicit-any` rule. In another case, `object` cannot be replaced with `Record<string, unknown>` when used with conditional types to mean "any non-primitive value".

This comment right here is enough for me to become suddenly much less keen on Deno.

If you're somebody who wants to make their ts as close to provable as possible, but also be able to handle dynamic / generative content, then you run into issues of this nature all the time with (for example) linter settings that think they know typescript better than you do, but fail to recognize that there is literally no other way to express some type-concept in typescript without using a larger feature set.

I agree wholeheartedly with the argument: tools getting in a way is the ultimate annoyance; in fact, struggling to force Jest to play nicely with ESM modules and TypeScript was the final straw that pushed me towards Deno for library development.

However, the argument can be made against any tool, and I'd say Deno here is the least deserving: in most cases it has just adopted the "defaults" set by tsc, eslint, or prettier, and just like them it allows ignoring these rules where necessary.

That said, I also think Deno made the right choice by enforcing these by default. Hopefully, it will fight the tide of low-quality code that plagues NPM. I do have to wrestle the linter, but it's mostly because I'm writing libraries that by themselves are pushing the limits of the TS type system, e.g. in structurae[1] I make an extensive use of mixins extending built-in objects, and mixin support is still nascent in TS. This is far less common in day-to-day production code, where, for example, using `any` or `object` is more often a sign of sloppy thinking rather than a necessity.

[1] https://github.com/zandaqo/structurae

// deno-lint-ignore no-explicit-any

You can use Deno without TS. I use it with plain JS and the code/test cycle is much faster without typescript compilation. Basically prefer Deno for ES6 modules and the good standard library.

Love Deno and using it as a node replacement. Fantastic work. I encourage anybody who has npm packages to move everything to deno.

I have 2 projects all in node, using express. Is there an easy way to migrate it? What happens to all the imported modules and dependencies? Can I still use express in Deno the same way?

"Easy" is highly subjective. If you're proficient at picking up new architecture paradigms for familiar languages, you're adept with ESM syntax, and refactoring is a skill; then you might consider it easy.

It's a paradigm shift, so there's always going to be some friction in migration. For your express needs, check out Oak https://deno.land/x/oak@v9.0.0

I wouldn't call it a paradigm shift in terms of the code itself. The main thing is that it's a completely different set of system APIs that have to be targeted (by you or by the libraries you use). That means a lot of changes wherever those are involved, but they should mostly be straightforward changes (of course YMMV if you're having to use a new library/framework instead of just the new system APIs)

Could you clarify what is the paradigm shift? Static types? (If so I agree, but using Node does not imply not using TS)

This is my first day obviously, but what I can see are the following interesting syntax, bare server.

   const server = Deno.listen({ port: 8080 });
   console.log(`HTTP webserver running.  Access it at:  http://localhost:8080/`);

    // Connections to the server will be yielded up as an async iterable.
    for await (const conn of server) {
     // In order to not be blocking, we need to handle each connection individually
     // without awaiting the 

     async function serveHttp(conn: Deno.Conn) {
      // This "upgrades" a network connection into an HTTP connection.
      const httpConn = Deno.serveHttp(conn);
      // Each request sent over the HTTP connection will be yielded as an async
      // iterator from the HTTP connection.
      for await (const requestEvent of httpConn) {
       // The native HTTP server uses the web standard `Request` and `Response`
       // objects.
    const body = `Your user-agent is:\n\n${requestEvent.request.headers.get(
    ) ?? "Unknown"}`;
    // The requestEvent's `.respondWith()` method is how we send the response
    // back to the client.
      new Response(body, {
        status: 200,

Everything async await. There is an option to use a library, but it's to be deprecated,the native option is stable. Interesting import code:

    import { serve } from "https://deno.land/std@0.105.0/http/server.ts";
So, Deno supports typescript out of the box or just plain JS. Deno doesn't support npm packages, imports are done via url. There is a window object, for whatever that's supposed to be used. Runs sandboxed, access to filesystem etc runs on permission basis. Access to the browser API without installing anything else. Packages are cached, this was very annoying in nodeJS.

Sounds and looks pretty damn good.

Probably more the removal of nodejs apis in favour of browser apis. For everything. (modules/imports included).

package management, scripts are quite the shift in Deno. there are tools like velociraptor and trex which help bridge the gap, but there's still a lot to learn that's much different than node-world.

Probably not, but Deno has Oak, which is Express-like and the combination of those two will get you close. But most node libs are not compatible and similarly node projects.

Thanks for that,Oh dear, I was secretly hoping for something as easy as a new package.json. A quick look around, I found this: Opine attempts to solve this by completely porting ExpressJS over to TypeScript in Deno, making changes only where the Deno APIs dramatically differ from Node.

Will give it a try, really curious how importing works and all.

> really curious how importing works and all.

So was I, so this is what I determined, on top of the official docs.[1]

On deno run of a script, it will download referenced imports and put them into a cache directory with a hash of the name. On a UNIX-like, this seems to be in ~/.cache/deno/deps (there's also a ~/.cache/deno/gen for the TS to JS stuff). Subsequent runs do not seem to download the scripts, but instead use the cached hashed versions. There's probably a way to blow out or overwrite the cache with newer download with a deno command, but I'm not sure what it is.

Compiling bundled the cached dependencies, so they aren't downloaded on run. Importing from local files is also possible, as noted in the docs I linked.

I'm happy to be corrected to supplemented on any of that info, I would rather know the actual way it works than persist in a slightly wrong assumption. :)

1: https://deno.land/manual@v1.11.5/examples/import_export

Isn't there a compatibility layer available, or are there reasons that in principle make this impossible?

There is a compatibility layer but it is not complete.

One of Deno's objectives is not to expose V8 internals, so node packages relying on those will be harder to port

Who doesn't love being removed even further from the platform they're running on?

Deno is striving for more unified APIs with browsers, so while they are moving away from the "platform" of internal use only V8 APIs, they are moving toward the "web platform", which seems an admirable goal to me. One of my biggest complaints for a while has been how drastically different some Node APIs are from the way any actual "web platform" APIs work in 2021 (Promises for filesystem APIs in Node are still "experimental", and meanwhile there's an actual filesystem API standardized in the "web platform" that is entirely incompatible but Promise-based). You can polyfill some of the "web platform" libraries back on top of Node in many cases, but Deno seems sensible to me in trying to better unify such things from the start.

One of Deno's value props is to have a tighter and more explicit trust model.

And this is not a obscure need. There are cloud providers who let you run JS on a specialized and restricted API.

However, there is nothing stopping you from using Node or integrating V8 and go wild with it! (In fact I would argue that this is a solid strategy for some types of projects, where you can get the best of both (static/dynamic) worlds.

> And this is not a obscure need. There are cloud providers who let you run JS on a specialized and restricted API.

Sounds rather obscure actually. Still somewhat confused why this would be useful in Deno. Looks like it's just a repeat of what happened with Java's SecurityManager, which is now being deprecated and removed.

> Sounds rather obscure actually.

It is how cloudflare workers work

Yes, something very obscure. Maybe a handful of companies in the world have a need to operate something like that.

> Love Deno and using it as a node replacement.

I'm pretty happy with Node.js. What would be some good reasons to switch?

Only tangentially related, but what's the point of a static class block? What problem does it solve that's not covered by either the class constructor or a static const? Doesn't it introduce a weird (stateful!) computation that's hard to reason about?

There's probably a use-case I'm missing, because intuitively I'd automatically classify it as bad a practice.

> Doesn't it introduce a weird (stateful!) computation that's hard to reason about?

Yes and no. For example, maybe you want to initialise a temporary directory on the filesystem for writing files to, for some caching mechanism. The pointer to the cache directory (maybe a const x = {}) can exist anywhere, but spinning up the directory itself in the static class block ensures that it's set up once and only once for all instances of the class. So, any instances get to reuse the directory without worrying about checking for initialisation first.

Just another tool in the toolbox, best evaluated on a case-by-case basis

That's a pretty terrible example. No way do you want temporary directories to be created just by loading a class. That violates all sorts of best practices.

There's a better example here: https://v8.dev/features/class-static-initializer-blocks

You could also use it for initialising generated constants.

What’s the difference from declaring the entropy pool in the example outside the class, in the module scope? Still private, still a single shared value.

I think just scope (same reason static class members exist).

Off the top of my head it's probably useful for implementing The Singleton Pattern, which reduces to one single instance of a class: https://en.wikipedia.org/wiki/Singleton_pattern

Singletons in JS/TS are done by creating and exporting an instance of a class:

  class MyClass {}
  export const myClassSingleton = new MyClass()
Static initialization blocks = "Constructors, for static class members/values"

Static blocks only run once, like the class declaration itself:

  class User {
    constructor(public name: string, public age: number) {}

    static {
      console.log("Hello from class User static block")

  const a = new User("a", 1)
  const b = new User("b", 2)
Is transpiled to:

  class User {
    constructor(name, age) {
        this.name = name;
        this.age = age;
  (() => {
    console.log("Hello from class User static block");
  const a = new User("a", 1);
  const b = new User("b", 2);

That's pretty close, but you need to add the protections around Object.keys(...) with guards in the getters and setters when using JS/TS. Sealing the entire class static should prevent the need and ability to edit that way.

Another perspective on static blocks is what they replace/help migrate away from. Static blocks are one of the last pieces of the puzzle holding some projects (or at least some particularly old legacy objects in those projects) from migrating to the new class syntax. For better or worse the classic Constructor Function pattern of building objects in JS was full of static initialization code (as it was an easy thing to do in that pattern). Static blocks bring back a way to do that in class syntax while adopting the better scoping rules of class syntax, helping more projects move away from Constructor Functions to class syntax.

Yeah, this makes a lot of sense. ES6 classes are restrictive if you look at them from a pre-ES6 perspective. Of course many of those restrictions are "right", but they are restrictions nonetheless.

I guess it's a good way to bring back that behavior with the added bonus of being useful by itself in some limited but legitimate cases (sibiling comment mentioned cache initialization, also a good point).

Here's a pattern I've been using for some time in ES6 JavaScript (on Node.js) :

   module.exports =  
   class MyClass
   { // ...

     static init ()
     { // ... do something, like create and 
       // cache a Singleton etc. 
       return this;
   } . init();
The static method init() is executed only once when the class is created and exported. You could add some check to it that causes an error if it gets called more than once.

Do static blocks allow me to do something more?

Modifying class static private properties

It might be helpful if you have a "registry" of classes. The classes can self-register statically, rather than you having to add separate code which registers the just-declared class.

It seems like a minor convenience, but it might play well with inheritance or mixin classes?

You can use it to load or compute derivatives of environmental configuration once


> NodeJS compatibility, what is our high-level strategy, goals, next steps?

> Do we see Node and Deno co-existing, or do we want to think of Node as "legacy"? (Note, there was no clear decision on this question, it was just a conversation)

> If we could say "you can run your Express server under Deno faster than Node" would that encourage adoption? No clear answer

I really wish they go for a better compatibility with Node and sell themselves as a replacement that is strictly better.

Node is from the days before ES6 and uses a different API. Should just kill it and start fresh. Deno conforms to modern JS standards and is much more pleasant to use in pretty much every way.

Node.js adds new-style APIs all the time. The File-system API now has an async/await version which is a joy to use.

When you load a library you can load a newer version or an older one. It's up to you. You can use both.

I agree that that's the direction of the future. I wouldn't start a new, important project with Deno just yet. It's still the early days.

Yeah, things like Oracle drivers might be nice.

Choose one:

1. Same. 2. Better.

You can't have both. Since getting better involves change, which is the opposite of staying the same.

Deno is awesome, and it's great to see the WebCrypto additions!

My current top feature request is that I wish Deno would have the same permission model for the repl.

I highly recommend listening to this recent podcast with Ryan Dahl: https://changelog.com/podcast/443

That would make REPL difficult to use, since you would need to know in advance what you want to do to pass the right permission flags.

REPL is particularly useful when trying out things "live" as they come into your mind.

A common use case for a repl is to copy and paste code into it, or to give code to someone and have them run it. It's nice to not have to think about what the code could do to the system before running it.

If you have all code already, just paste into a file and run that file…

Otherwise you might want to check out piping support https://github.com/denoland/deno/pull/6130 Something like `echo "yourcodehere" | deno run -`

Deno is really awesome for shell scripts. Forget Bash. Forget Python. Deno is way better.

You get a fairly sane type system, good performance, easy deployment (it doesn't count as easy if it's a pain on Windows), supports single file scripts with third party dependencies, and no compilation to deal with.

There aren't really any alternatives that offer all that as far as I know.

I'm convinced to try deno. I only use node for small testing scripts so it should be easy enough.

> This release allows deno lint and deno fmt to be configured.

That's good news. The main thing holding me back from seriously looking at Deno was the lack of config for the formatting. The default settings weren't right for me, and I tend to avoid projects where you have to fight the tools. I'm going to take another look now.

Anyone using Deno in production? Would love to hear how it's going for your team.

We tried it for a couple months, it was basically a huge hassle getting our stuff to work especially anything that has bindings to CPP (any of the node gyp packages). Also felt like we were putting in a lot more effort to try to get packages with docs for node to work similarly in deno, and weren’t really feeling any value from using deno over node.

If you’re a hobbyist or an academic or starting a totally new project that won’t have dependencies/doesn’t need a large community of modules, then I recommend deno. Otherwise I highly recommend sticking to node until deno comes out with something to make the switch more appealing.

I honestly think the switch (being getting node libraries working in deno) won't happen.

I believe it will be a much better if the community puts time into making a larger module pool that is upto the standard of node

Yeah I wonder how this will work long-term. I haven't heard of an ecosystem where they successfully avoided packages. Eventually you need some way of pulling in code that's versioned and has versioned dependencies of its own. Otherwise you end up with implicit versions or rolling your own everything, both of which are less than ideal and not necessarily better than packages. Deno could keep adding stuff to its standard library but I doubt even the largest stdlib could fit all users' needs.

I agree with this entirely. I would absolutely use deno to teach js/ts. I would absolutely use deno in a hobby project. I would absolutely use deno if my requirements were such that I wanted to minimize js dependencies.

I use when doing DSA/Algorithmic puzzle solving. I typically would use Java for such a thing. TS is pretty nice and when I don't need dependencies.... deno is a nice Typescript first language/runtime/env.

I know it's a bit superficial, but I love Deno's branding. Their logo is cute and evokes a sense of calm, and the variations on the mascot are nice.

Looks good. Interesting that they are "bringing back" mutual tls (after browsers pretty much axed it..).

Is there support on the (deno http) server-side too? Eg: easy to set up mutually trusted, private-/non-ca tls between a deno client and deno server? Perhaps via a self-signed/private CA?

The server does not support mutual TLS as of yet. Feel free to open an issue on denoland/deno though, so we can look into this :-)

Does anyone know of providers for running deno FAAS style? Or is a VPS needed?

How it is the zero-copy ArrayBuffer transfer function implemented?

ArrayBuffers are just views on underlying memory owned by the thread a V8 isolate is running on. (Each worker runs on a separate thread, each with its own V8 isolate). When we transfer an ArrayBuffer, we detach the underlying memory from the isolate in the sending thread, and move ownership of the memory area to the receiving thread, where a new JS ArrayBuffer object is created that points to that memory area.

TLDR: The memory is never moved, the pointers to it are just detached from one isolate, and instead passed to another.

Hats off to you, helping Javascript programmers break out of the matrix ;)

My son is 13. He loves Deno. What I don't get is why a 13-year-old can get Deno, and we don't, and it's not as widely popular as it must be for its merits!

you got me at no need for scaffolding files babel.config.js

Why’d they have to give a JS environment the name of a guido.

How many runtimes are there for JS? They seem to pop up once a week...

Practically, number of browsers + 2 (Node and Deno, and Deno is stretching the definition of practical at this early stage).

Edit: + Electron + the JS runtime used for Windows ecosystem based on Chakra (not sure if that's still alive though?) + a few other similar ones in that vein for desktop or mobile OS'.

+ whatever is available for embedded & similar devices, (I guess there will be a few but I know little about that area).

+ various [highly] specialised business/academic/hobby/PoC/etc runtimes, but they're not realistically things that many people care about.

follow up question: how many different incompatible ways to require(), import … are there?

Two (import + require, which, as import didn't exist, was necessary). Most current tooling is built to handle both (Deno draws a line under it by disallowing the older one)

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact