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.<p>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.
Is anybody using Deno at work?<p>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.<p>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.
Bartek from deno.land here, happy to answer your questions should you have any.<p>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.<p>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.
I'm still not a fan of the async iterator API example for server handlers:<p><pre><code> for await (const conn of Deno.listen({ port: 4500 })) {
(async () => {
for await (const { respondWith } of Deno.serveHttp(conn)) {
respondWith(new Response("Hello World"));
}
})();
}
</code></pre>
It's hard to reason, and ugly with that async iffe in the middle adding layers of nesting and bf-like `})();` junk.<p>I think the event subscription API is much easier on the eyes and the mind.
<p><pre><code> const libSuffix = { darwin: "so", linux: "so", windows: "dll", }[Deno.build.os]
</code></pre>
oh no, what a bad example. Hope no one ever actually copies that…<p>(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")
Small thing but I dig the new --eval flag.<p>To do something like this in node, I used to do:<p><pre><code> (echo 2+2; cat -) | node -i
</code></pre>
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.<p>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.