Deno 1.13 Release

[qbasic_forever]

One little deno feature I didn't realize until digging in to play with it more was that it can 'compile' code and the V8 runtime into a single standalone executable. IMHO this is really nifty and feels very go-like in building tools with zero other dependencies. Obviously the V8 runtime adds a lot of size (seems like a hello world is 90MB or so in quick testing) but I like the potential for building tools that are easy to give to others to install and use.

It seems great for internal use where you have analysts and such using a mish-mash of scripts and one-offs with lots of dependencies and little documentation or time to help people setup and use them. Just hook up your CI to spit out new executables and be done with walking people through how to troubleshoot their broken homebrew node, python, etc. environments.

[ksbrooksjr]

There used to be a '--lite' option that produced smaller binaries, but it looks like they removed it recently [0]. There's also a CLI called pkg that lets you achieve something similar with Node. It actually compiles the source code into V8 bytecode and bundles that with the Node binary [1].

[0] https://github.com/denoland/deno/issues/10507

[1] https://github.com/vercel/pkg

[hashbig]

You can do this with Node.js as well using: https://github.com/vercel/pkg

[rektide]

Personally I weap for the death of shared libraries. It's great developer convenience to statically bundle everything, and ever so manageable...

But it makes me so sad thinking not just of the storage footprint of dozens of copies of the library floating around (be it v8 for deno, or chrome for electron), but the memory cost too of having that near-to duplicate library loaded multiple times too.

And then there's the maintenance cost to the user, of needing to update each package independently to get updates. With something like the web, I as a user would far prefer having bleeding edge shared libraries/v8's/browsers underfoot, and carry the expectation that each app can load & run atop this most recent version.

The trends have been very much in the other way. One of the main Go champions tout is it's static compilation, I think rust too. What are containers but entire static system images, as opposed to just having some static libraries? Part of me is willing to acknowledge that the larger footprints aren't that impactful, aren't really a problem, but it contravenes the deliberate & elegant simplicity that something like an OS distribution used to represent: I look at Debian as thousands of different pieces, all wonderfully integrated & interlinked, a cohesive system, that one ought to be able to bring additional projects onto to compile & extend. But our appetite for such has waned. The convenience for you & your users of just bundling everything you personally need to ship your stuff is quite high, at least when you're not updating dozens of oversized apps or running janky old versions because of this easy-to-get-started convenience.

[brundolf]

Is anybody using Deno at work?

I feel like there was this rush of excitement when it first came out, and that's mellowed to a steady stream of updates and some sustained low-medium interest. It seems like everybody's following it from the sidelines, waiting to see what happens. That's my situation at least.

I'd love a world where I can write everything in TypeScript with minimal building hassle, but I'm curious to what degree that's panning out in industry.

[zachlatta]

We're using Deno for some small projects at Hack Club. We open source everything. Code for them should be somewhere in https://github.com/hackclub/hackclub.

In particular, we've been using it to replace some bash and Ruby scripts we had.

[mrkurt]

We have a customer running about 300 million requests per day through a Deno app to generate image variants.

[nullspace]

We are, in a limited fashion.

Can't give too much details (mostly because I'm not directly working on it), but the ability to run in a constrained sandbox and the ability to easily do go style imports from github is seriously useful for our use case.

Don't know how it's going to pan out, but from a high level deno seems to be very well designed. I'm looking forward to see the various niches in which people use it.

[tupac_speedrap]

Not that I know of. TypeScript has had some major adoption over vanilla JavaScript over the past few years, I used it a bit when it was relatively new and now it is pretty common to see it advertised on job specs but I have never seen Deno once, maybe they use it in "ployglot" shops where everybody uses more esoteric languages but I haven't seen it advertised anywhere.

[maga]

I'm using Deno for developing my isomorphic libraries (e.g. structurae[1]). It comes with a built-in toolchain (formatter, linter, test runner, compiler) that significantly reduces headache when compared to jangling prettier, eslint, jest, and tsc.

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

[j-pb]

Yes. We also don't use it with typescript (and would actively advocate for its removal from deno when asked), best JS runtime I've ever used.

[eyelidlessness]

I know at least one person on the Snowpack/Astro team has expressed[1] interest in dual Node/Deno support.

I’m not currently advocating for supporting Deno on my professional projects. But this isn’t for lack of interest, it’s just lower priority than other changes I want to make first. I absolutely want to switch when I can justify it, if for no other reason than fast TypeScript ESM without a build/transformation step.

1: https://twitter.com/n_moore/status/1423672410486755332?s=21

Edit: forgot link

[rektide]

I find doubt/skepticism like this unimportant & irrelevant. I am far more interested in a Tim Orielly style "Follow the Alpha Geeks" mentality, of mining the scene for what is interesting & empowering & novel, understanding contributions & possibilities.

Deno brings two main things that seem undeniably critical & without peer:

1. Fantastic rust integration. Node has neon & napi-rs, but neither of these present as rust-first & readily available extension point, to replicate what node did: be the incredibly super successful bridge between the native platform & the javascript language. Whatever success Rust has will strengthen & alloy Deno's position.

2. Unparalleled web platform support. Always bet on the web. The web is everywhere, it's platform is excellent & healthy & robust, some last cracks of missing capabilities are being filled in. Deno presents as a possible server-side desktop-side web environment in a way nothing else does. Whatever success the web has will strengthen & alloy Deno's position.

Fretting about where in the adoption curve something is is uninteresting to me, a geek. I would rather focus on the thing, know it, assess it's potential, see others assessments, & make my own projections of usability & adoption, than look about for signs. Hopefully the brilliant things will have their due day.

[gutino]

Yes we are building an API of serverless services

[bartlomieju]

Bartek from deno.land here, happy to answer your questions should you have any.

Deno 1.13 is one of the biggest releases to date - we're especially happy with stabilization of native HTTP server bindings. We plan to focus on squeezing the last bits of performance out of it in the coming weeks.

Personally I'm most excited about type checking example code in Markdown files. It's critical to keep your documentation up to date and doing so for code blocks embedded in JSDoc comments or Markdown files was very challenging. With this release we got you covered - just run "deno test --doc" on your codebase.

[brundolf]

I haven't been following the Deno community super closely; do you know if people have converged yet on a go-to web framework, similar to Express? Does this stabilization play into that progression at all?

Last I checked there were several promising-but-fragmented options, so I'm hoping the community has or will pick a "standard" answer for "I want to make a web service", since that seems like one of the headlining (the headlining?) usecases for headless JS

I'm also, and this is more off-topic, but I'm wondering if there's an answer for NextJS out there on its way. The latter is eating (a portion of) the world a little bit right now, and could singlehandedly keep some parts of the industry on Node.

[wuschel]

Hi Bartek, thanks for jumping in.

I am wondering whether one could forego Typescript and use one of the Ocaml/F# to JS converters for the frontend and backend code. Would it even make sense, and would it be convenient to use? How would one set up such a project?

[lxe]

I'm still not a fan of the async iterator API example for server handlers:

    for await (const conn of Deno.listen({ port: 4500 })) {
      (async () => {
        for await (const { respondWith } of Deno.serveHttp(conn)) {
          respondWith(new Response("Hello World"));
        }
      })();
    }

It's hard to reason, and ugly with that async iffe in the middle adding layers of nesting and bf-like `})();` junk.

I think the event subscription API is much easier on the eyes and the mind.

[emptysea]

I'm curious why the IIFE is even necessary in this case. There is already a top level await in the `for await` right?

Looks fine IMHO once the IFFE is removed:

  for await (const conn of Deno.listen({ port: 4500 })) {
        for await (const { respondWith } of Deno.serveHttp(conn)) {
          respondWith(new Response("Hello World"));
        }
    }

Edit: Oh is it so it runs in concurrently and avoids the synchronous handling?

[floatboth]

    const libSuffix = { darwin: "so", linux: "so", windows: "dll", }[Deno.build.os]

oh no, what a bad example. Hope no one ever actually copies that…

(it's bad because it unnecessarily limits the list of platforms to just three. great way to make BSD users hate you. just do: if (windows) "dll" else "so")

[bartlomieju]

Thanks, I'll update the example

[rektide]

Small thing but I dig the new --eval flag.

To do something like this in node, I used to do:

  (echo 2+2; cat -) | node -i

Which would generate some stdin via echo, then use cat to feed stdin to node. --eval 2+2 is a blissfully elegant upgrade to this.

As a comment points out, node has a '-e' (and a -p which prints the evalled thing) but does not open a repl after. This shell receipt, like --eval, leaves the repl open.

[johannes1234321]

1) node has a -e option

2) why the cat? It just pipes the stuff through

3) you can use <<< to pipe something to stdin (`node <<< 1+1`)

[aitchnyu]

The example makes me ask, is there a current/planned function to compare two complex objects are value-equalm like lodash `_.isEqual`?

[reaktivo]

You can find and equivalent to _.isEqual here https://deno.land/[email protected]/testing

[holoduke]

Any reason why I would use this over expressjs?

[FaisalAbid]

Is Deno production ready?

[russellbeattie]

Seriously, HN, is Deno going to hit the front page with every single point release??

[petercooper]

You just reminded me of the Erlang flood of 2009 :-) https://news.ycombinator.com/item?id=512145