DEV Community: Caleb Albritton

Introduction to Deno

Caleb Albritton — Fri, 22 May 2020 20:08:28 +0000

Originally published on WA9ACE.net

I've very much enjoyed all of my experiences with Deno and I've wanted to share that experience along with frequent questions I've been asked.

How things are (were?)

Imagine if you will a TypeScript node project similar to this project skeleton I took a few hours to whip together.

This skeleton has:

TypeScript Express
TypeScript aware tests with Jest
TypeScript aware linter with ESLint

To produce that you need upwards of 2k+ packages, and 3 different config files with vaguely similar rules to have them all behave cohesively. This is all not to mention how difficult it is to get debugging in VSCode going with properly mapped files, testing, and breakpoints. Imagine you're a newer developer. You don't have a mentor able to walk you through setting up a new project with a TypeScript stack so you can start writing something, anything, useful. How about from another perspective. Do you trust that your linter isn't silently shipping data off of your machine across the network? If you aren't vetting your dependencies you should be.

There are a lot of little things that are vaguely irritating, but not so entirely off-putting that the internet wouldn't use it. After all the world runs on JavaScript.

This death by a thousand cuts can be a slog and irritating to keep updated, with packages required just to keep your project's source code compiling, tests passing, and linter fixing, a cluster of issues.

What Deno Provides

Deno seeks alleviate many of these issues. Deno has a built-in functionality for almost everything we've discussed above. First of all Deno has a TypeScript compiler built in, with plans to port all of TSC to Rust! It has testing built in out of the box with deno test along with a built in formatter with deno fmt. What's even better is that this requires no extra dependencies, and no configuration to support TypeScript. It Just Works™. Another piece of functionality Deno ships with is the ability to restrict application's abilities with a whitelist permission system. If you're program doesn't need any network access or filesystem access then you can simply run your deno program with deno run. If you need network access to specific domains, and filesystem access to specific folders you will need to declare that when invoking the program. Something similar to deno run --allow-read=/etc --allow-net=github.com,deno.land your_program.ts. -A will blanket allow all permissions, but that's not something that should be used lightly.

Packages

Deno imports packages via URL and takes a completely different approach from Node's NPM ecosystem. There is no centralized package management system. There is deno.land/x however there is discussion regarding whether or not it remains to be a good idea to provide a centralized mirror for simple files hosted on GitHub.

I plan to release modules under my own namespace using this sort of structure https://wa9ace.net/deno/pkg/daro/v0.0.1/mod.ts.

Deno allows you to produce a lockfile so that if a dependency's hash changes between first use and the next reload you can inspect to see why, as well as providing a way to vendor dependencies so that you don't have to rely on anyone's, including my own, dependencies being available on any given server.

But I don't want super long imports all over my codebase

Answer: deps.ts as recommended in the deno.land/manual

What's the convention for publishing packages if there's no NPM?

Essentially projects have a mod.ts file that rexports the public parts of the library you're using. This makes the steps for publishing a package quite easy as all you really need is your TypeScript code, a place to put it online, and a mod.ts file that exports the part of your code that you want published.

If you'd like to learn more about Deno and watch a senior engineer live stream building Deno libraries, join me in Discord every Tuesday and Thursday night at 9pm eastern.

Debugging Deno Projects in VSCode.

Caleb Albritton — Thu, 21 May 2020 21:00:00 +0000

Debugging Deno applications inside VS Code is actually pretty straightforward with the right launch config. Use the below .vscode/launch.json config to debug your entire deno application, debug all of your deno tests, run a single test file, or just the specific test case that you have currently selected.

{
  // Use IntelliSense to learn about possible attributes.
  // Hover to view descriptions of existing attributes.
  // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
  "version": "0.2.0",
  "configurations": [
    {
      "type": "node",
      "request": "launch",
      "name": "Debug Program",
      "runtimeExecutable": "deno",
      "runtimeArgs": [
        "run",
        "--inspect-brk",
        "./src/main.ts"
      ],
      "port": 9229,
      "console": "integratedTerminal"
    },
    {
      "type": "node",
      "request": "launch",
      "name": "Run Tests",
      "runtimeExecutable": "deno",
      "runtimeArgs": [
        "test",
        "--inspect-brk"
      ],
      "port": 9229,
      "console": "integratedTerminal"
    },
    {
      "type": "node",
      "request": "launch",
      "name": "Debug Current Test File",
      "runtimeExecutable": "deno",
      "runtimeArgs": [
        "test",
        "${file}",
        "--inspect-brk"
      ],
      "port": 9229,
      "console": "integratedTerminal"
    },
    {
      "type": "node",
      "request": "launch",
      "name": "Debug Selected Test Case",
      "runtimeExecutable": "deno",
      "runtimeArgs": [
        "test",
        "${file}",
        "--filter",
        "${selectedText}",
        "--inspect-brk"
      ],
      "port": 9229,
      "console": "integratedTerminal"
    }
  ]
}

Writing Hello World in Web Assembly

Caleb Albritton — Fri, 07 Jun 2019 16:08:18 +0000

Syndicated from WA9ACE.net. Originally published on April 20th, 2017.

Before we get into the details we're going to define some terminology.

Web Assembly was recently decided to be a finished MVP
including

a JavaScript API and binary format accompanied by a reference interpreter.

Web Assembly is written in an s-expression syntax (wast) and then needs to be translated down to binary encoded wasm. Below is a gist of wast that imports the stdlib.print function taking a memory location offset and a length, as well as importing a block of memory from the controlling runtime. We then store the string "Hello World" at memory location 0. We then export a main function that calls the aforementioned print function with the memory location offset and length.

hello.wast

module
  (import "stdlib" "print" (func $print (param i32 i32)))
  (import "js" "mem" (memory 20))
  (data (i32.const 0) "Hello World")
  (func (export "main")
    i32.const 0  ;; pass offset 0 to log
    i32.const 20 ;; pass length 20 to log
    call $print))

If you know JavaScript the below will look rather mundane. The only interesting part is really the log function and creating the memory passed into the instantiated wasm. It's 20 pages (1280KiB) which is pretty overkill for this application. Try playing with that value and watch at which point the wasm fails and how. You can see the exposed object is how we make functions from JavaScript available to the wasm underneath.

hello.js

document.addEventListener("DOMContentLoaded", main)

function log(offset, length) {
  const bytes = new Uint8Array(memory.buffer, offset, length)
  const string = new TextDecoder('utf8').decode(bytes)
  console.log(string)
}

var memory = new WebAssembly.Memory({ initial : 20 });

const exposed = {
  stdlib: { print: log },
  js: { mem: memory }
}

function main(event) {
  fetch('hello.wasm').then(response =>
    response.arrayBuffer()
  ).then(bytes =>
    WebAssembly.instantiate(bytes, exposed)
  ).then(result =>
    result.instance.exports.main()
  )
}

Now this is all fine and dandy aside from the fact that we can't run the wast.

In order to run the wast we'll need to turn into binary encoded wasm. Fortunately wabt exists. After you've headed over here
and compiled the toolchain you should have a binary called wast2wasm among others.

Running this command should produce a runnable wasm binary.

wast2wasm hello.wast -o hello.wasm

Now that we have the binary encoded wasm, we need to run it somewhere. As of Node 7.9.0 it uses V8 version 5.5.372.43. Chrome 57 uses V8 5.7.492.71. The older version does not support the latest wasm spec meaning we can't run our wasm in current stable Node (this will probably be wrong when you read this). Node version 8 nightly builds will try running the wasm however it errors out on my Macbook with Illegal Instruction: 4. To try running it in Node when this is solved you can call Node with node --expose-wasm hello.js.

Until then we'll be running it in current Chrome. Here's some HTML you can copy pasta, and if all goes well you should see "Hello World" in your dev tools console!

index.html

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="utf-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <link rel="icon" href="data:;base64,iVBORw0KGgo=">
    <title>Hello World WASM</title>
  </head>
  <body>
  <script src="hello.js"></script>
  </body>
</html>