<h1>Footguns of the Rust WebAssembly Target</h1>
<img src="/images/rail.webp" alt="A trail in Golden, Colorado">
WebAssembly—even after several years of standardization—is still a nascent technology.
I've been working with Rust and WebAssembly for nearly four years now.
This post is intended to be a distillate of that experience, formatted for developers who are interested in publishing WebAssembly code to npm.
Specifically, these are the footguns I've personally encountered while working on <a href="https://writewithharper.com/docs/harperjs/introduction"><code>harper.js</code></a>, a WebAssembly-powered package for grammar checking at the edge.
This page should be valuable if you are even speculating on the possibility of using WebAssembly in your codebase.
<hr>
<h2>1. Exposing Only Synchronous Functions</h2>
The Harper package exposes one interface that captures all of its WebAssembly interactions: the Linter. This is an object that handles downloading and compiling the Harper WebAssembly module, as well as invoking functions in it. Every function returns a <code>Promise</code>. There are several good reasons for that:
<ul>
<li>WebAssembly modules larger than 4 kilobytes must be instantiated asynchronously to avoid blocking the event loop during download or compilation. This is a technical limitation that cannot be avoided with clever logic.</li>
<li>If most functions are asynchronous, you can centralize computation and caching into a single instance of the WebAssembly module, hiding the complexity of instantiation and making caches easier to build.</li>
<li>If your problem domain can be computationally intense, it might be prudent to offload jobs onto a web worker, which is easier if every function of your facade is asynchronous.</li>
<li>It will be easier for both you and your users to expose any important function as asynchronous out of the gate.</li>
</ul>
<h2>2. Assume Rust Can Trivially Do IO</h2>
Whatever you do: avoid assuming that Rust libraries (like <code>reqwest</code> or <code>rand</code>) will be able to perform IO without some work on your end. WebAssembly alone is not capable of IO, which means any function in that category will require some amount of JavaScript to work properly.
Rather than leaving that up to the Rust toolchain to figure out, save yourself the headache and inject the necessary JavaScript functions directly into the WebAssembly module by passing them through <code>wasm_bindgen</code>.
<hr>
<h2>3. Just Inline the WebAssembly Module</h2>
Obsidian plugins, for example, must be composed of exactly one JavaScript file, which means everything must be inlined. In the interest of keeping the bundle size small, it's much easier for the package developer (of <code>harper.js</code>) to set up inlining than the plugin developer.
On the other side of the spectrum, Chrome's Manifest V3 disallows WebAssembly from being loaded inline.
If you plan for your package to be consumed by a variety of applications, know that it will also be consumed by a variety of bundlers. Both bundlers and applications are pretty inconsistent with their inlining and tree-shaking behavior. To avoid problems, you should provide two versions of your package:
<ul>
<li>One where your WebAssembly module is already inlined.</li>
<li>One where it isn't.</li>
</ul>
<h1>Wrapping it Up</h1>
Harper’s problem domain is not your problem domain.
We have to integrate with a variety of unique applications, which means we must keep our system flexible.
That may not be the case for you, which may mean these footguns do not apply.
If you have any questions about any other problems the Harper project might have faced, let me know.

Four years in Rust + WebAssembly taught me these 3 lethal footguns—don’t learn them the hard way.

Four years in Rust + WebAssembly taught me these 3 lethal footguns—don’t learn them the hard way.

Footguns of the Rust Webassembly Target

<h1>Continuations on Transformation-based Learning</h1>
<img src="/images/clear_creek_steps.webp" alt="Steps near Clear Creek. Taken by me.">
The most common type of machine learning out there takes the form of some kind of neural network. Inspired by how our own brains work, these systems act as function approximations. They are great, but they come with a few key pitfalls.
First and foremost, they start out with very little baked-in understanding of the context they live in. This is fine—usually enough data can be provided to bridge the gap. It does mean, however, that they spend an inordinate amount of time learning the fundamentals of their field. This translates to a larger model size and longer inference time (especially at <a href="https://en.wikipedia.org/wiki/Edge_computing">the edge</a>).
Secondly, most neural networks are initialized with randomness, which results in extremely high entropy. High entropy means that these models cannot be compressed easily (if at all).
This disqualifies neural networks from many aspects of <a href="https://writewithharper.com/">Harper's architecture</a>. Harper tries to be fast and small, so it can be shipped and run wherever our users are. Neural networks (especially in the world of natural language processing) are neither fast nor small.
This is why we've taking an alternative approach to machine learning, as evidenced by last week's post on <a href="https://elijahpotter.dev/articles/transformation-based_learning">transformation-based learning</a>.
<h2>Transformation-Based Learning: A Refresher</h2>
Transformation-based learning is remarkably simple. It boils down to just four steps:
<ul>
<li>Use a simple, stochastic model t label your data. This can be as simple as tagging each token (or other discrete component) with that variant’s most common tag. It doesn’t need to super accurate, just enough to establish a baseline.</li>
<li>Identify the errors between the tags in your canonical data and that which produced by your baseline model.</li>
<li>Using a finite list of human-defined templates, generate candidate rules that transform the output of the baseline model into something else. This is where the term “transformation-based” comes from.</li>
<li>Apply each of the candidate rules to the baseline model’s output. Check if the result is more accurate than before. If so, save the rule for future use.</li>
</ul>
These saved candidates become your model.
If you're interested how this could be applied to POS tagging, I've since updated my original post on the subject to better explain the process. I'd recommend taking a look.
<h2>Nominal Phrase Chunking</h2>
It's often useful, especially when building a grammar checker, to be able to identify the subjects and objects of sentences. Suppose, for example, that we want to insert the missing Oxford comma in a list of fruits: "I like apples, bananas and oranges". In this trivial example, this can be done with POS tagging. If we have more complex subjects, like in the phrase "I like green apples, deliciously pernicious bananas and fresh oranges," POS tagging starts to fall apart. Identifying multi-token subjects is the job of a nominal phrase chunker.
I've been wanting to build a nominal phrase chunker for a while, but haven't had the tools to do so. Now that I have pipeline in place (from last week), it should be relatively straightforward.
For the purposes of this model, we'll be tagging each token with a boolean; it is either a member of a noun phrase, or it is not.
I started by assigning each token to a nominal phrase if a POS tagger marks it as a noun. This is our baseline model. It performs poorly because the resulting nominal phrases do not include determiners or any adjectives.
Similar to our POS tagging model, I used a Universal Dependencies treebank to determine the accuracy of our baseline. After generating candidate rules using the same patch templates as the POS tagging system and running them against the treebank, I have a model with a 90% accuracy.
I feel as though there should be more details to share, but that was pretty much it. I spent a good amount of time optimizing the training code. There's still a lot of work left to do to incorporate it into the rest of Harper. I am also unsatisfied with the model's current accuracy. To get it closer to 100%, I suspect I'll need to do a good amount of data cleaning.

The most common type of machine learning out there takes the form of some kind of neural network. Inspired by how our own brains work, these systems act as function approximations. They are great, but they come with a few key pitfalls.

The most common type of machine learning out there takes the form of some kind of neural network. Inspired by how our own brains work, these systems act as function approximations. They are great, but they come with a few key pitfalls.

More Transformation Based Learning

<h1>Why Rust Might Attract More Developers Than Java and JavaScript</h1>
Rust is undeniably a greatly appreciated language, after all, it has placed as "#1 Most Loved Programming Language" on the StackOverflow Developer Survey for 6th year running.
Reading this, you are probably very aware of why so many people like it, but I will be going over those reasons anyway, at least before I reveal its secret weapon.
It’s fast, very fast. While it may not be a great benchmark, The Computer Language Benchmarks Game, measures that it falls just a hair behind the fastest language, C.
That makes sense, given that Rust was meant to replace C/C++. Even better than the benchmark, it has been shown that in many situations, the Rust compiler is able to optimize code significantly better than C or C++, just because it has more information about the developers intent.
It’s consistent. For more than pretty much any other language, Rust developers can expect that, if their code compiles, it works. When it doesn’t compile, the compiler gives better feedback and advice than any other language. It can even check if your arithmetic is wrong.
It’s complicated, but only where it needs to be. The language itself, as well as its standard library are built very consciously, by its users. Most places where you might find you have to write tedious boilerplate, Rust makes it easy. It also gives you the freedom to write code that does exactly what you want, exactly how you want. We will get back to this later.
<h2>The Problem</h2>
When starting a new project what is the first thing you are going to do? It depends on what stack you are using.
If you want to use NodeJS, it might look something like:
<pre><code class="hljs language-bash">mkdir new_project
touch index.js
npm install
</code></pre>
That is just the bare minimum. If you want to add any dependencies, you have to go through an unreasonable number of hoops, and the standard package repository, npm, is known for being quite insecure, not to mention it being controlled by a private corporation.
If you want to use Java, you have to use some kind of template, otherwise it’s impossible to create a project from scratch. Even then, you have to decide between two or three package managers, and deal with it when libraries don’t support your choice.
If you want to use C or C++ forget it. As a beginner, you are going to be stuck figuring out how to use the local linker and compiler to get any library to work.
<h2>The Rusty Solution</h2>
Cargo is one of the simplest, easiest to use build tools out there. It does everything you might need, and it may be why Rust may soon become a major player. 99% of the time, you can just copy and paste a given library’s string directly from <a href="https://crates.io">crates.io</a>, which is a repository owned and operated by the Rust Foundation, and you are off to the races.
Testing is easy too, just run <code>cargo test</code>, and you're done. It covers both unit tests, and integration tests if you need it.
`cargo doc`` provides a consistent, and easy way to document code. It’s also great for users, allowing developers access to a straightforward representation of what a library looks like.
It’s extensible, some of the greatest binary crates out there exist to extend the functionality. So, in the few areas where <code>cargo</code> on its own doesn’t cut it, there are additional crates to fill the gaps.
<h2>Closing</h2>
At least for the moment, of all the great reasons to use Rust, <code>cargo</code> will be the most significant reason it will increase in popularity.
<img src="/images/most_loved_stackoverflow_2021.png" alt="Most loved programming languages, according to the 2021 StackOverflow Developer Survey">
Rust can be tough to learn, especially for people who are used to dynamic languages like JavaScript. But what Rust has beat for most languages is the build system. <code>cargo</code> alone makes Rust more approachable than C/C++, Java and many others.
More and more new developers will be going to Rust instead of those other languages, because it is easier to start with, easier to learn, and has a great community to request help from.

A key part of Rust is far better than what JavaScript has to offer.

A key part of Rust is far better than what JavaScript has to offer.

Why Rust May Be More Attractive than JavaScript

harper_for_firefox_through_spellbolt

<h1>Harper in Firefox Through SpellBolt</h1>
<img src="/images/ford_street.webp" alt="Ford Street, Golden, Colorado">
We designed Harper to be the ultimately portable grammar checker, but we're still working on living up to that promise.
As the Harper Chrome extension becomes more capable day-by-day, it has one critical weakness: it doesn't support Firefox.
Since Chrome has a much larger market share, it isn't a priority at the moment (although we accept contributions).
This is a wonderful example of where the open-source nature of the Harper's core engine really shines.
Someone has taken <a href="https://www.npmjs.com/package/harper.js"><code>harper.js</code></a> and put it into their own extension.
<a href="https://addons.mozilla.org/en-US/firefox/addon/spellbolt/">SpellBolt</a> is a Firefox extension that delivers Harper's fantastic grammar checking straight into your Firefox browser.
My initial testing shows that it's a solid extension.
I am delighted to see people making use of the pluggable architecture Harper has adopted, and I can't wait to see what SpellBolt does next.

SpellBolt is a Firefox extension that delivers Harper's fantastic grammar checking straight into your Firefox browser.

SpellBolt is a Firefox extension that delivers Harper's fantastic grammar checking straight into your Firefox browser.

Elijah Potter

Harper in Firefox Through SpellBolt

Other Stuff

Footguns of the Rust Webassembly Target

More Transformation Based Learning

Why Rust May Be More Attractive than JavaScript