<h1>Putting Harper in Your Browser</h1>
When our users <a href="https://writewithharper.com">install Harper</a>, they should expect it to work anywhere they do.
Whether they're writing up a blog post in WordPress, leaving a comment on Facebook, or messaging a loved one on WhatsApp, Harper should be there.
Harper's core is extremely portable and it can run pretty much anywhere Rust can, so what's the big deal?
Why can't we just run Harper in the browser through a web extension?
<h2>Running Locally</h2>
There's a single complaint that I hear over and over again from people who use Grammarly or LanguageTool: they are both slow as molasses.
The process of writing has slowly evolved to be more complex than it needs to be.
With these tools, it writing looks like:
<ol>
<li>Write a sentence.</li>
<li>Wait for the grammar checker to run (which takes as many as four seconds).</li>
<li>Fix the mistakes you made.</li>
<li>Go back to step one.</li>
</ol>
The whole process reminds me of the <a href="https://thomasvogelaar.me/posts/the-copilot-pause/">copilot pause</a>.
This is part of why Harper is better than these other tools: it doesn't stop you from writing at the speed of thought.
Our most ardent users tell us this all the time: it feels great to just write, error free.
<h4>How do we deliver grammar checking so quickly?</h4>
Instead of hosting huge Java codebases in the cloud, we ship our software straight to the user's device.
Since there's no network request involved, we're able to put pixels on the screen faster than anyone else.
That's not to mention the privacy implications.
<h4>Running Harper's engine locally in the browser presented some technical challenges.</h4>
I'm quite proud that our JavaScript library can be installed as simply as <code>npm install harper.js</code>.
In order for that to work as well as it does, I needed to develop a system for:
<ol>
<li>Compiling our engine to WebAssembly.</li>
<li>Shipping that engine to the browser.</li>
<li>Instantiating the WebAssembly code.</li>
<li>Build out the boilerplate necessary to make it feel native.</li>
</ol>
Steps one and four were easy.
I just slapped <code>#[wasm_bindgen]</code> tags on a Rust library and put on a pot of coffee.
Steaming coffee is vital for writing tedious JavaScript.
Steps two and three, however, were a little more difficult.
The latest iteration of Google's extension standard, Manifest V3, places some heavy-handed rules on how executable code could be loaded.
I won't bore you with the details here.
Know that I spent many hours in JavaScript bundler hell.
<h2>Running Everywhere</h2>
Harper, nascent as it is, has the greatest market opportunity in the browser.
Over 3.5 billion people use Chrome on a weekly basis.
The plurality of knowledge workers spend most of their waking moments (as crushing as it sounds) in a web browser.
Half of the time spent at desks today is spent writing.
In order to address this market segment, we need a Chrome extension.
To lint text in the browser, I need a way to:
<ol>
<li>Cleanly read text from input fields.</li>
<li>Locate the pixel coordinates of grammatical errors.</li>
<li>Render suggestions in popups.</li>
<li>Cleanly replace text in input fields when a suggestion is selected.</li>
</ol>
<img src="/images/harper_chrome_ext_2.png" alt="An example of Harper&#x27;s suggestion box.">
<h4>Reading and Writing Text is Hard</h4>
The web may have standards, but there is nothing standard about it.
The "standard" way to input text is with a <code>&#x3C;textarea /></code> element.
Even so, most high-traffic sites implement their own text editors from scratch, using <code>&#x3C;div contenteditable="true" /></code> as a base.
Each of these cases required special care.
<h3><code>&#x3C;textarea /></code></h3>
<code>&#x3C;textarea /></code>s are hard for one reason: it is difficult to get a good understanding of what they look like.
I can obtain their content with <code>input.value</code>, but I can't directly infer the pixel coordinates of grammatical errors inside them.
When the Harper Chrome Extension is offered an <code>&#x3C;input /></code> or <code>&#x3C;textarea /></code> element to analyze, here's what it does.
<ol>
<li>Creates a new <code>&#x3C;div /></code>.</li>
<li>Copies all styles from the provided element onto the <code>&#x3C;div /></code>.</li>
<li>Using <code>position: absolute;</code>, it moves this <code>&#x3C;div /></code> directly on top of the provided element.</li>
<li>Copies the content of the provided element into the <code>&#x3C;div /></code>.</li>
<li>Uses the <a href="https://developer.mozilla.org/en-US/docs/Web/API/Range">Range API</a> to turn the text indices emitted by Harper's engine into pixel coordinates on the <code>&#x3C;div /></code>.</li>
</ol>
Using this mirroring strategy works, but has performance implications and additional complexity to handle scrolling within the element.
<h3><code>&#x3C;div contenteditable="true" /></code></h3>
Since elements in a <code>contenteditable</code> text editor (like Trix, Lexical, Gutenberg, etc.) actually exist in the DOM, I can just use the <code>Range API</code> to get pixel coordinates.
The trouble this time comes when I try to write a suggestion back into the editor.
Most documentation I could find suggests that you:
<ol>
<li>Select the content of the element you wish to edit.
This can be done using <code>window.getSelection().addRange()</code>.</li>
<li>Call <code>document.execCommand('insertText', null, "YOUR TEXT")</code>.</li>
</ol>
Much of this documentation acknowledges that <code>document.execCommand</code> is deprecated, but instructs you to use it anyway.
This is bad advice. Do not do this.
I spent an embarrassing amount of time trying to get it to work consistently.
The better way to replace text programmatically comes directly from the W3C standard:
<ol>
<li>Manually edit the DOM in the fashion outlined by the suggestion chosen by the user.</li>
<li>Fire input events to instruct WYSIWYG editors to synchronize their internal state to the DOM.</li>
</ol>
I'll admit that this is an oversimplification.
Much of the complexity here lays in determining which DOM nodes to edit or fire events on.
<h2>Read the Source of Truth</h2>
If you take one thing away from this post, it should be this: always read from the source of truth.
There is a lot of faulty information out there, especially when it comes to creating complex interactions with opaque systems.
If there is a source of truth, read it.
It may look intimidating or seem unnecessarily verbose.
It is that way for a reason.

When our users install Harper, they should expect it to work anywhere they do.

When our users install Harper, they should expect it to work anywhere they do.

Putting Harper in your Browser

<h1>Photography as Meditation</h1>
The goal of meditation is to become more mindful and aware.
For me, it is often an attempt to get an appreciation for my surroundings—to see how utterly complex the world is.
<img src="/images/pink_flower_tree.webp" alt="Spring has sprung in Colorado. That means pink flowers everwhere.">
Photography does something similar for me.
The heft of the camera in my hands reminds me to slow down and take in the view.
My mother is a photographer—a great one at that.
She's been in the business for at least as long as I've been alive.
She tells me something similar: the act of framing a picture is itself a way to understand your subject better.
<img src="/images/puddle.webp" alt="Spring brings rain and rain brings puddles.">

Reflecting on the clarity photography brings.

Reflecting on the clarity photography brings.

Photography As Meditation

<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

notifications

<h1>Notifications</h1>
I have found that the first couple hours of the day are my most productive.
I try to move tedious tasks to later so I can focus on solving "hard problems" that need my full attention.
In the past, this has been hard to do for one reason: GitHub notifications.
They pull me in and consume hours of my time.
Responding to and working with OSS contributors is important to me, but that can happen later in the day.
So I wrote a little ViolentMonkey script to hide the notifications icon during these early morning hours.
<pre><code class="hljs language-javascript">// ==UserScript==
// @name Hide Notification Indicator
// @namespace Violentmonkey Scripts
// @match https://github.com/*
// @grant none
// @version 1.0
// @author Elijah Potter
// @description 1/29/2025, 8:16:11 AM
// ==/UserScript==

function hideEm() {
 const matches = document.getElementsByClassName(
 "AppHeader-button--hasIndicator",
 );
 for (const element of matches) {
 element.remove();
 }
}

new MutationObserver(hideEm).observe(document, {
 childList: true,
 subtree: true,
});
</code></pre>

Elijah Potter

Notifications

Other Stuff

Putting Harper in your Browser

Photography As Meditation

Footguns of the Rust Webassembly Target