Forem: Sby

Zed: The Editor I Wish I Liked

Sby — Wed, 19 Nov 2025 21:14:50 +0000

Searching for a Unicorn

I've been hearing about this shiny new code editor, Zed, for quite a while.

On paper it was everything I wanted: performant (written in Rust), minimalistic (unlike the IntelliJ bloat monsters), a GUI (I'm not a fan of TUI editors for many reasons). So when I heard it got an official Windows release I knew I had to try it.

Unfortunately, it wasn't as sunshine and rainbows as I had hoped and I'll be sticking to VSCodium for the foreseeable future. Not because Zed is bad, it was everything they said it is. But no more than that.

In this post I'm laying out my very opinionated view of what a code editor should and shouldn't be. I know most won't agree with half of this, which is why I'm putting it here instead of a feature request. Even though Zed is still in development their design choices are already different and they're not going to change just to fit me.

Don't Take It Harshly

The app is performant. Startup time is almost half of VSCodium's on my machine. IntelliJ never stood a chance.

It is a proper GUI. The devs stick to what's familiar, you won't have any trouble migrating from VS Code.

And it's functional out of the box. You never feel like it's unusable because of some missing feature or weird design quirk.

Wishlist for Santa

Which makes the death by a thousand cuts all the more unfortunate.

These things may be ironed out as time goes on - or may not. This is just the stuff I care about.

Minimap Is Useless

I've grown reliant on the minimap in VSCodium to quickly spot error lines. Often in the editor the squiggly underline is tiny but on the minimap the whole line is highlighted. It saves me from squinting searching for it or re-running the compiler/linter to print out the line number.

Without this one feature the minimap might as well be a very thick scrollbar. Understandable as it's actually hidden most of the time by default.

Shortcuts Slow You Down

Continuing with finding errors: for some reason the feature that lets you jump to a file from a relative path and the line number only works through a specific keyboard shortcut and is missing from the command palette.

An annoyingly common scenario: copy file link with the mouse -> open the file finder (which forces you to put both hands on the keyboard because P is quite far from Ctrl) -> move hand back to the mouse to start scrolling the file you just opened.

GUI matters to me which is why I'll never switch to keyboard-only editors like Neovim or Emacs. Keyboard shortcuts only speed up typing which takes less than half of the development time. The real speed comes from mouse-enabled functionality when you're only limited by how fast you can aim. As they say "programming is more about reading code than writing it".

Pointless Command Palette

There are only two commands I ever use in VSCodium's command palette, everything else has always felt like bloat. The first is Go to File which was found orphaned and the other is Restart Server when the language server doesn't rerun.

Somehow I've had to use the latter way more often in Zed for both TypeScript and Rust. And the command palette itself is also only accessible via a shortcut. It’s not even to save screen space, instead of being at the top like VS Code, there's just an empty bar.

In an ideal world I wouldn't touch the palette at all. I don’t know what half the commands do and probably never will.

Clunky Layout

I've never understood the trend of hiding the menu bar that IntelliJ started doing. It only adds extra clicks for basic tasks like opening a project. Sadly Zed does the same.

You can make the menu bar permanently visible but instead of replacing or moving the title bar buttons it creates a whole new bar. And the other bar doesn't disappear even if you disable all the buttons on it. So you just have two mostly-empty bars taking up space.

Search using the editor pane instead of the explorer pane was immediately annoying. When I'm searching I'm looking for a list of files so the explorer pane is just becomes wasted space while the search results steal the area I'm actually trying to use.

The tiny button to open the terminal pane being moved to the bottom right is understandable but the massive bar with the title the terminal window is taking up too much space. I've never felt the need to title my terminals but and you can change neither part of it the project name nor the shell name.

Zed doesn't have workspaces so the project name never changes and the only shell it supports is the default, which is powershell on Windows. What is the point of the title then?

No Workspaces

And no, Zed doesn't have workspaces. A GitHub comment notes and many agree: Zed is fast but what's the point of being fast if you can't open large workspaces where that speed matters.

OOne of the main reasons I'm trying to move away from VSCodium is that workspaces are finicky. Extensions and language servers break all the time since workspace support is not a priority. Zed "solves" that by not having workspaces at all. We'll see how the support for it goes in the future but I’m not holding my breath.

Everything Requires an Extension

Relying on extensions isn't a problem on itself but Zed tries to be both minimal and ready-to-go and as fails at both.

The first time I opened a project, Zed instantly started installing the language extension. There's no option to disable it if you just want to use Zed as a lightweight text editor for a moment.

At the same time every file prompts you to install a matching extension like the annoying VS Code notifications. Worse - all the suggested extension typically does is regular lexer low-awareness syntax highlighting.

Dull Design

I'm not into ricing and dislike vanity extensions as fluff in the way but the the built-in themes are incredibly bland. Everything is washed out and low-contrast, not nice to look at.

This lack of color variety has real impact. In VSCodium, const values in TypeScript have a different shade of blue than regular values and rust-analyzer marks mutable variables and methods with an underscore. Zed lacks this syntax highlighting clarity.

There's Still Bloat

The second biggest reason I want to move from VSCodium is the amount of features I'll never use. It's better than base VS Code without all the AI "features" it's been getting lately (which seem to be the only features it's getting nowadays) but it's still presented as an IDE while I just want a text editor.

Still A Very Fast Horse

At the end of the day, Zed is a solid editor. It's fast, polished, and pleasant enough to use. But it's also clearly designed for people who don't work the way I do and that's fine. I'm glad it exists and I hope it gets better but for now the search for my perfect editor goes on.

Unhinged JS Tooling Setups in 2025

Sby — Sun, 27 Jul 2025 18:13:50 +0000

State of JS tooling

As you may have heard, the JS ecosystem is trying to move away from tooling written in JavaScript like eslint, prettier and even tsc for more performant options.

There are lots of tools being developed, from compilers to metaframework plugins but today let's focus on only the formatters and linters offered.

The big names around are biome, oxc and an announced Microsoft-developed tsgo.

The trade-offs

However, none of these tools have matured enough to fully supercede their JS counterparts just yet.
Just look at all the downsides you're getting with any tool you choose

Tool	Shortcomings
`oxlint`	no type awareness no plugin ecosystem only lints the <script> part of .vue, .astro and .svelte files configuration is unintuitive
`biome`	lackluster plugin ecosystem only formats and lints the <script> part of .vue, .astro and .svelte files
`tsgolint`	an experimental prototype without dedicated movement for becoming a real tool
`prettier`	very slow
`eslint`	very slow no one actually uses type aware rules, and if your dependencies don't abide by them, neither can you configuartion is a pure mess, broke backwards compatability with a flat config and plugins take months and years to catch up

Minmaxing DX

So how can we take advantage of all this tooling without the downsides?

With lots of configuration. Here I present to you the setup you can modify for your needs.

package.json

We'll be using a single command script check that both lints and formats

{
  "scripts": {
    "check": "prettier -w . && biome check --write --unsafe . && oxlint -c .oxlintrc.json --fix . && eslint ."
  },
  "devDependencies": {
    "@biomejs/biome": "^2.1.2",
    "@prettier/plugin-oxc": "^0.0.4",
    "eslint": "^9.32.0",
    "eslint-config-prettier": "^10.1.8",
    "eslint-plugin-oxlint": "^1.8.0",
    "oxlint": "^1.8.0",
    "prettier": "^3.6.2",
    "typescript-eslint": "^8.38.0"
  }
}

.prettierrc

Using oxc parser to for a slight speed up

{
  "useTabs": false,
  "tabWidth": 2,
  "singleQuote": false,
  "plugins": ["@prettier/plugin-oxc"],
  "printWidth": 100
}

biome.json

Ignore files not in git

{
  "$schema": "https://biomejs.dev/schemas/2.1.2/schema.json",
  "vcs": {
    "enabled": true,
    "clientKind": "git",
    "useIgnoreFile": true
  },
  "files": {
    "ignoreUnknown": false
  },
  "formatter": {
    "enabled": true,
    "indentStyle": "space",
    "indentWidth": 2
  },
  "linter": {
    "enabled": true,
    "rules": {
      "recommended": true
    }
  },
  "javascript": {
    "formatter": {
      "quoteStyle": "double"
    }
  },
  "assist": {
    "enabled": true,
    "actions": {
      "source": {
        "organizeImports": "on"
      }
    }
  }
}

.oxlintrc.json

{
  "$schema": "../node_modules/oxlint/configuration_schema.json",
  "plugins": ["import", "typescript", "unicorn", "promise", "node"],
  "tsconfig": "./tsconfig.json",
  "env": {
    "browser": true
  },
  "settings": {}
}

eslint.config.mjs

Skip rules that oxlint already covers

import js from "@eslint/js";
import prettier from "eslint-config-prettier";
import oxlint from "eslint-plugin-oxlint";
import tseslint from "typescript-eslint";

export default tseslint.config(
  js.configs.recommended,
  ...tseslint.configs.recommendedTypeChecked,
  ...tseslint.configs.stylisticTypeChecked,
  {
    languageOptions: {
      parserOptions: {
        project: true,
        tsconfigRootDir: import.meta.dirname,
      },
    },
  },
  {
    ignores: [
      ".git/*",
      ".gitignore",
      "node_modules/*",
      "target/*",
      "**/bun.lock",
      "**/eslint.config.mjs",
    ],
  },
  prettier,
  oxlint.configs["flat/recommended"],
  ...oxlint.buildFromOxlintConfigFile("./.oxlintrc.json"),
);

Side note on Svelte

Svelte has its own tool it uses for linting, svelte-check, that comes with the svelte-kit template.
And as for the formatter, all it takes is prettier-plugin-svelte to get it working.
Those are slow and very basic but you'll die trying to set up anything else, don't even bother.

{
  "useTabs": false,
  "tabWidth": 2,
  "singleQuote": false,
  "plugins": ["@prettier/plugin-oxc", "prettier-plugin-svelte"],
  "printWidth": 100,
  "overrides": [{ "files": "*.svelte", "options": { "parser": "svelte" } }]
}

Conclusion

And that's it. Leave a comment if you know a way to optimize these further.
Though we all know, the real setup you'll end up using is no tooling at all LMAO.

Creating a Browser Extension

Sby — Fri, 07 Feb 2025 22:02:32 +0000

Important Note

This article describes a way of creating a web extension using vite-plugin-web-extension which has since been superseded by wxt framework.
Take a look at its docs instead!

The Modern (not anymore) Way

In this post we'll look at the modern way of making a browser extension.

The web ecosystem has evolved over the years and with it, the browser extensions.
As the regular web apps, the bundlers have gained massive popularity among developers.

Vite is a build tool that has risen in usage in the past years.
It accepts plugins in the config to modify its behaviour and there exists one for creating a browser extensions, Vite Plugin Web Extension.

This plugin helps a lot with development, including hot reloading the extension in the browser and building for multiple browsers from the same source.

Alongside we're using webextension-polyfill to simplify access to browser's APIs.

Project Structure

The file placement for a browser extension differs from a regular webapp.
It is mainly managed using required manifest.json file.

Rather than the conventional index.html, the entrypoint HTML file is typically called the popup (popup.html).
It is declared in the manifest under action (Chrome) or browser_action (Firefox) field.

Like a regular webpage it can load CSS, JS and even "web-unsafe" fonts bundled with your extension.

However, to actually interact with the webpages you visit in the browser, you need a content script, typically called content.js.
You have to declare them in the manifest under content_scripts field, which takes an array of objects with a required field matches, which specifies on what websites will the content script be loaded.

Note
For this you need to declare scripting permission in the permissions array of manifest.json

There is also background.js which is used as a web worker.

What this means in practice, however, is that extensions don't follow the typical webapp structure.
Unfortunately, full-stack frameworks like SvelteKit, Nuxt and SolidStart are not at all supported even though they're based on Vite.
That unforuntately also means no SSG, despite the extension being completely static.

How to Actually Do Something

The popup script and the content script need to communicate to actually perform work.
This is done using runtime messages browser API.

The content script is loaded on webpage load and starts listening for messages.

function listen(
  message: unknown,
  _sender: browser.Runtime.MessageSender,
  sendResponse: any,
): void {}

browser.runtime.onMessage.addListener(listen);

The popup script is loaded with the popup HTML and it sends the message to the content script.
But first it must identify which tab the script is loaded in and in this case we are querying the tabs API.

Note
For this query you need to declare activeTab permission in the permissions array of manifest.json

const tab: browser.Tabs.Tab = (
  await browser.tabs.query({ active: true, currentWindow: true })
)[0];

Then you pass the id of the active tab alongside your message.

interface Message {}
interface ExtensionResponse {
  data: string;
}

const resp: ExtensionResponse = await browser.tabs.sendMessage(id, {
  action: "getImages",
} as Message);

The content script responds by using the sendMessage callback passed to the listener

sendResponse({
  data, 
} satisfies ExtensionResponse);

And that's it for this exploration of the modern webextension landscape.
Feel free to share thoughts and questions in the comments

Random Useful Trivia

These are the basics to get you started with the development.
Here I would like to share some things you might find useful.

webextension-polyfill uses a synthetic import in

import browser from "webextension-polyfill";

so you have to allow it in tsconfig.json.
It's allowed by default but your linter may want to disallow it for tree-shaking.

If your content.js throws an error, it gets silenced by the webpage and doesn't show up in the DevTools console.
During development it's recommended to wrap your listener in a try {} catch (error) {} block.

When you install the extension locally after building it using unpacked load, the browser reads directly from the directory, it doesn't copy the files.
It does mean faster development cycle, however that also means the dev changes affect your release installation as vite-plugin-web-extension dev build directly overwrites the dist/ folder.
You may probably want to create a separate folder, with a script like this.

import { execSync } from "node:child_process";
import { cp, rm } from "node:fs/promises";

await rm("build", { recursive: true, force: true });
execSync("vite build");
await cp("dist", "build", { recursive: true });

Resources

Check out the docs
https://vite-plugin-web-extension.aklinker1.io/
https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions
https://developer.chrome.com/docs/extensions

How to Deserialize Internally Tagged JSON in C# with AoT compilation

Sby — Sun, 08 Dec 2024 13:56:00 +0000

In this quick tutorial we'll see how to set up JSON serialization and deserialization for an internally tagged object in C# System.Text.Json using AoT-friendly polymorhpism source generators.
Unlike reflection and writing a custom converter, source generators makes this both easy and performant.

1. Declare Context

First, you need a class holding the context for your serialization and deserialization for which source will be generated.
For that, you need to inherit from JsonSerializerContext and declare your options with JsonSourceGenerationOptions.

Then you need to declare which types you want to serialize and deserialize. Here we have ItemModel base class and TextItem and ImageItem derived classes. Using typeof(List<ItemModel>) will allow for deserializing both a single ItemModel object and a list of ItemModels.

[JsonSourceGenerationOptions(WriteIndented = false)]
[JsonSerializable(typeof(List<TextItem>))]
[JsonSerializable(typeof(List<ImageItem>))]
[JsonSerializable(typeof(List<ItemModel>))]
internal partial class SourceGenerationContext : JsonSerializerContext { }

2. Create Type Discriminators

You need a way to tell JSON deserializer that your base class has derived implementations.
For that we'll use JsonPolymorphic and JsonDerivedType metadata on the base class.

[JsonPolymorphic(TypeDiscriminatorPropertyName = "$type")]
[JsonDerivedType(typeof(TextItem), typeDiscriminator: "text")]
[JsonDerivedType(typeof(ImageItem), typeDiscriminator: "image")]
public abstract class ItemModel { }

C# uses type disciminator property "$type" by default but here we're declaring it explicitly.
Then we point to the derived types and give the type discriminator "text" and "image". However, you're not limited to using strings here and can use numbers to, for example, save on size.

2.1. Optional. Serializing Derived Types

While serializing and deserializing ItemModel will work as intended, serializing TextItem and ImageItem directly will not generate a type discriminator, which is something you may want to do.

For that we can simply configure the derived type to be considered derived from itself.

[JsonPolymorphic(TypeDiscriminatorPropertyName = "$type")]
[JsonDerivedType(typeof(TextItem), typeDiscriminator: "text")]
public class TextItem : ItemModel { }

Now we have repeating strings in base class and derived class, which can be refactored into constants.

internal static class Constants
{
    public const string Discriminator = "$type";
    public const string TextDiscriminator = "text";
    public const string ImageDiscriminator = "image";
}

[JsonPolymorphic(TypeDiscriminatorPropertyName = Constants.Discriminator)]
[JsonDerivedType(typeof(TextItem), typeDiscriminator: Constants.TextDiscriminator)]
[JsonDerivedType(typeof(ImageItem), typeDiscriminator: Constants.ImageDiscriminator)]
public abstract class ItemModel { }

3. Pass the Context

Now all we need to do is pass the generated context to the serializer/deserializer.

var items = await JsonSerializer.DeserializeAsync<List<ItemModel>>(
    stream,
    SourceGenerationContext.Default.ListItemModel
) ?? [];

await JsonSerializer.SerializeAsync(
    stream,
    images,
    SourceGenerationContext.Default.ListImageItem
);

Conclusion

And that's it for this tutorial on how to work with internally tagged polymorphic JSON objects in C#.
Feel free to share thoughts and questions in the comments

Syncing DOM State and Data without IDs

Sby — Sun, 17 Nov 2024 20:56:47 +0000

Problem: Managing Stateful DOM Elements in Dynamic Lists

Keeping stateful DOM elements in sync with a mutable list of data is one of those challenges that seems simple at first but quickly spirals into code spaghetti. This issue is present in almost every major JavaScript framework—whether you're working with React, Vue, or Svelte.

Let's Set the Scene

Picture this:
You have a list of labels and want to render a form input for each one. Seems easy enough, right? But now, what if these labels don't have unique identifiers.

At first, you may think:

"I'll just use the label itself as a key."

But when labels aren’t guaranteed to be unique, this approach quickly falls apart.

The Wrong Approach: Using Array Index as a Key

You might try using the array index as a key:

{rows.map((row, i) => (
    <Fragment key={i}>
        <label>{row.label}</label>
        <input placeholder={row.placeholder} />
    </Fragment>
))}

While this silences immediate errors, linting tools like biomejs (and others) will fill your terminal with errors for doing this—for good reason! Using indices as keys can lead to poor performance and cause state misalignment when your list changes (e.g., when adding or removing items).

Tip
Learn why JavaScript frameworks need keys to render arrays.
Also learn why SolidJS is an exception to that

What About Fully Managed State?

Another option might cross your mind:

"Why not manage the entire form state manually?"

Sure, you can try. But this means:

Shuffling state across multiple components on every change.
Writing complex handlers to manage every input interaction.
Running a small mountain of JavaScript just to maintain synchronization.

What If There's a Simpler Way?

What if I told you there's a simpler and faster way to avoid this dilemma?
Let me show you how to stop fighting your framework's rendering logic.

Solution: Simpler Than You Thought

Just change your state from this

const [rows, setRows] = useState<Row[]>(state);

to this

const [rows, setRows] = useState<[Row, number][]>(
  state.map((row, key) => [row, key]),
);

And that's it!
Now instead of unstable indicies you have stable keys that are nicely packed alongside with your data.

{rows.map(([row, key]) => (
    <Fragment key={key}>
        <label>{row.label}</label>
        <input placeholder={row.placeholder} />
    </Fragment>
))}

Examples: Usage in Practice

Here's how your remove and append functions may look like

const remove = (key: number) =>
  setRows((state) => state.filter((row) => row[1] !== key));
const append = () =>
  setRows((state) => [...state, [fourth, (state.at(-1)?.[1] ?? -1) + 1]]);


{rows.map(([row, key]) => (
  <Fragment key={key}>
    <label>{row.label}</label>
    <input placeholder={row.placeholder} />
    <button type="button" onClick={() => remove(key)}>
      Delete
    </button>
  </Fragment>
))}
<button type="button" onClick={append}>Append</button>

In Svelte

{#each rows as [row, key] (key)}
  <label>{row.label}</label>
  <input placeholder={row.placeholder} />
{/each}

And in Vue

<template v-for="[row, key] in rows" :key="key">
  <label>{{ row.label }}</label>
  <input :placeholder="row.placeholder" />
</template>

Conclusion

And that's it for this small JS trick you may use in your front-end projects.
Feel free to share thoughts and questions in the comments

How to and Should you use Bun FFI

Sby — Sun, 10 Nov 2024 22:33:43 +0000

What are we trying to achieve

Let's say you have a JavaScript application that runs in bun and you've identified some bottleneck that you'd like to optimize.
Rewriting it in a more performant language may just be the solution you need.

As a modern JS runtime, Bun supports Foreign Function Interface (FFI) to call libraries written in other languages that support exposing C ABIs, like C, C++, Rust and Zig.

In this post, we'll go over how one may use it, and conclude whether one can benefit from it.

How to link the library to JavaScript

This example is using Rust. Creating a shared library with C bindings looks differently in other languages but the idea remains the same.

From JS side

Bun exposes its FFI API through bun:ffi module.

The entrypoint is a dlopen function. It takes a path that's either absolute or relative to the current working directory to the library file (the build output with a .so extension for Linux, .dylib for macOS or .dll for Windows) and an object with the signatures of functions you want to import.
It returns an object with a close method which you may use to close the library once it's not needed anymore and symbols property which is an object containing the functions you chose.

import {
  dlopen,
  FFIType,
  read,
  suffix,
  toArrayBuffer,
  type Pointer,
} from "bun:ffi";

// Both your script and your library don't typically change their locations
// Use `import.meta.dirname` to make your script independent from the cwd
const DLL_PATH =
  import.meta.dirname + `/../../rust-lib/target/release/library.${suffix}`;

function main() {
  // Deconstruct object to get functions
  // but collect `close` method into object
  // to avoid using `this` in a wrong scope
  const {
    symbols: { do_work },
    ...dll
  } = dlopen(DLL_PATH, {
    do_work: {
      args: [FFIType.ptr, FFIType.ptr, "usize", "usize"],
      returns: FFIType.void,
    },
  });

  /* ... */

  // It is unclear whether it is required or recommended to call `close`
  // an example says `JSCallback` instances specifically need to be closed
  // Note that using `symbols` after calling `close` is undefined behaviour
  dll.close();
}

main();

Passing data through FFI boundary

As you may notice, the supported types that bun accepts through FFI are limited to numbers, including pointers.
Notably size_t or usize is missing from the list of supported types, even though the code for it exists as of bun version 1.1.34.

Bun doesn't offer any help in passing data more complex than a C string. That means you'll have to work with pointers yourself.

Let's see how to pass a pointer from JavaScript to Rust ...

{
  reconstruct_slice: {
    args: [FFIType.ptr, "usize"],
    returns: FFIType.void,
  },
}

const array = new BigInt64Array([0, 1, 3]);
// Bun automatically converts `TypedArray`s into pointers
reconstruct_slice(array, array.length);

/// Reconstruct a `slice` that was initialized in JavaScript
unsafe fn reconstruct_slice(
    array_ptr: *const i64,
    length: libc::size_t,
) -> &[i64] {
    // Even though here it's not null, it's good practice to check
    assert!(!array_ptr.is_null());
    // Unaligned pointer can lead to undefined behaviour
    assert!(array_ptr.is_aligned());
    // Check that the array doesn't "wrap around" the address space
    assert!(length < usize::MAX / 4);
    let _: &[i64] = unsafe { slice::from_raw_parts(array_ptr, length) };
}

... and how to return a pointer from Rust to JavaScript.

{
  allocate_buffer: {
    args: [],
    returns: FFIType.ptr,
  },
  as_pointer: {
    args: ["usize"],
    returns: FFIType.ptr,
  },
}

// Hardcoding this value for 64-bit systems
const BYTES_IN_PTR = 8;

const box: Pointer = allocate_buffer()!;
const ptr: number = read.ptr(box);
// Reading the value next to `ptr`
const length: number = read.ptr(box, BYTES_IN_PTR);
// Hardcoding `byteOffset` to be 0 because Rust guarantees that
// Buffer holds `i32` values which take 4 bytes
// Note how we need to call a no-op function `as_pointer` because
// `toArrayBuffer` takes a `Pointer` but `read.ptr` returns a `number`
const _buffer = toArrayBuffer(as_pointer(ptr)!, 0, length * 4);

#[no_mangle]
pub extern "C" fn allocate_buffer() -> Box<[usize; 2]> {
    let buffer: Vec<i32> = vec![0; 10];
    let memory: ManuallyDrop<Vec<i32>> = ManuallyDrop::new(buffer);
    let ptr: *const i32 = memory.as_ptr();
    let length: usize = memory.len();
    // Unlike a `Vec`, `Box` is FFI compatible and will not drop
    // its data when crossing the FFI
    // Additionally, a `Box<T>` where `T` is `Sized` will be a thin pointer
    Box::new([ptr as usize, length])
}

#[no_mangle]
pub const extern "C" fn as_pointer(ptr: usize) -> usize {
    ptr
}

Rust doesn't know JS is taking ownership of the data on the other side, so you have to explicitly tell it to not deallocate the data on the heap using ManuallyDrop. Other languages that manage memory will have to do something similar.

Memory management

As we can see, it's possible to allocate memory in both JS and Rust, and neither can safely manage others memory.

Let's choose where you should allocate your memory and how.

Allocate in Rust

There are 3 methods of delegating memory cleanup to Rust from JS and all have their pros and cons.

Use `FinalizationRegistry`

Use FinalizationRegistry to request a cleanup callback during garbage collection by tracking the object in JavaScript.

{
  drop_buffer: {
    args: [FFIType.ptr],
    returns: FFIType.void,
  },
}

const registry = new FinalizationRegistry((box: Pointer): void => {
  drop_buffer(box);
});
registry.register(buffer, box);

/// # Safety
///
/// This call assumes neither the box nor the buffer have been mutated in JS
#[no_mangle]
pub unsafe extern "C" fn drop_buffer(raw: *mut [usize; 2]) {
    let box_: Box<[usize; 2]> = unsafe { Box::from_raw(raw) };
    let ptr: *mut i32 = box_[0] as *mut i32;
    let length: usize = box_[1];
    let buffer: Vec<i32> = unsafe { Vec::from_raw_parts(ptr, length, length) };
    drop(buffer);
}

Pros

It's simple

Cons

Garbage collection is engine specific and non-deterministic
Cleanup callback is not guaranteed to be called at all

Use `toArrayBuffer`'s `finalizationCallback` parameter

Delegate garbage collection tracking to bun to call a cleanup callback.
When passing 4 parameters to toArrayBuffer, the 4th one must be a C function to be called on cleanup.
However, when passing 5 parameters, the 5th parameter is the function and the 4th parameter must be a context pointer that gets passed it.

{
  box_value: {
    args: ["usize"],
    returns: FFIType.ptr,
  },
  drop_box: {
    args: [FFIType.ptr],
    returns: FFIType.void,
  },
  drop_buffer: {
    args: [FFIType.ptr, FFIType.ptr],
    returns: FFIType.void,
  },
}

// Bun expects the context to specifically be a pointer
const finalizationCtx: Pointer = box_value(length)!;

// Note that despite the presence of these extra parameters in the docs,
// they're absent from `@types/bun`
//@ts-expect-error see above
const buffer = toArrayBuffer(
  as_pointer(ptr)!,
  0,
  length * 4,
  //@ts-expect-error see above
  finalizationCtx,
  drop_buffer,
);
// Don't leak the box used to pass buffer through FFI
drop_box(box);

#[no_mangle]
pub unsafe extern "C" fn box_value(value: usize) -> Box<usize> {
    Box::new(value)
}

/// # Safety
///
/// This call assumes the box hasn't been mutated in JS
#[no_mangle]
pub unsafe extern "C" fn drop_box(raw: *mut [usize; 2]) {
    let box_: Box<[usize; 2]> = unsafe { Box::from_raw(raw) };
    drop(box_);
}

/// As per bun docs, expected signature like in JavaScriptCore's `JSTypedArrayBytesDeallocator`
/// https://developer.apple.com/documentation/javascriptcore/jstypedarraybytesdeallocator?language=objc
///
/// # Safety
///
/// This call assumes the buffer hasn't been mutated in JS
#[no_mangle]
pub unsafe extern "C" fn drop_buffer(ptr: *mut i32, len: *mut usize) {
    // reconstruct the context box to not leak it
    let length: usize = unsafe { *Box::from_raw(len) };
    let buffer: Vec<i32> = unsafe { Vec::from_raw_parts(ptr, length, length) };
    drop(buffer);
}

Pros

Delegate logic out of JavaScript

Cons

A lot of boilerplate and chances to leak memory
Missing type annotation for toArrayBuffer
Garbage collection is engine specific and non-deterministic
Cleanup callback is not guaranteed to be called at all

Manage memory manually

Just drop the memory yourself after you don't need it anymore.
Luckily TypeScript has a very helpful Disposable interface for this and the using keyword.
It's an equivalent to Python's with or C#'s using keywords.

See the docs for it

{
  drop_box: {
    args: [FFIType.ptr],
    returns: FFIType.void,
  },
  drop_buffer: {
    args: [FFIType.ptr, "usize"],
    returns: FFIType.void,
  },
}

class RustVector implements Disposable {
  constructor(
    private inner: Int32Array,
    private dropBuffer: (ptr: Int32Array, len: number) => void,
  ) {}
  [Symbol.dispose](): void {
    this.dropBuffer(this.inner, this.inner.length);
  }
}

const buffer = new Int32Array(toArrayBuffer(as_pointer(ptr)!, 0, length * 4));
// Don't leak the box used to pass buffer through FFI
drop_box(box);
using wrapper = new RustVector(buffer, drop_buffer);

/// # Safety
///
/// This call assumes the box hasn't been mutated in JS
#[no_mangle]
pub unsafe extern "C" fn drop_box(raw: *mut [usize; 2]) {
    let box_: Box<[usize; 2]> = unsafe { Box::from_raw(raw) };
    drop(box_);
}

/// # Safety
///
/// This call assumes the buffer hasn't been mutated in JS
#[no_mangle]
pub unsafe extern "C" fn drop_buffer(ptr: *mut i32, length: usize) {
    let buffer: Vec<i32> = unsafe { Vec::from_raw_parts(ptr, length, length) };
    drop(buffer);
}

Pros

Cleanup is guaranteed to run
You have control of when you want to drop the memory

Cons

Boilerplate object for Disposable interface
Manually dropping memory is slower than using garbage collector
If you want to give away the ownership of the buffer you have to make a copy and drop the original

Allocate in JS

This is much simpler and safer as deallocating is handled for you.

However, there is a significant drawback.
Since you can't manage JavaScript's memory in Rust, you can't go over the buffer's capacity as that will cause a deallocation. That means you have to know buffer size before passing it to Rust.
Not knowing how many buffers you need beforehand will also incur a lot of overhead as you'll be going back and forth through FFI just to allocate.

const CAPACITY = 20;
// The buffer is initialized with zeroes
const buffer = new Int32Array(CAPACITY);
mutate_buffer(buffer, CAPACITY);

/// # Safety
///
/// Ensure that the length of the buffer is at least `capacity` size
#[no_mangle]
pub unsafe extern "C" fn mutate_buffer(ptr: *mut i32, capacity: usize) {
    assert!(!ptr.is_null());
    assert!(ptr.is_aligned());
    assert!(capacity < usize::MAX / 4);
    // Manually drop so that vec doesn't get cleaned up
    let mut buffer: ManuallyDrop<Vec<i32>> =
        ManuallyDrop::new(unsafe { Vec::from_raw_parts(ptr, 0, capacity) });
    let other: Vec<i32> = vec![/* ... */];
    assert!(buffer.len() + other.len() <= buffer.capacity());
    buffer.extend_from_slice(&other);
}

A sidenote on strings

If the output you're expecting from the library is a string you may have considered the microoptimization of returning a vector of u16 rather than a string since typically JavaScript engines use UTF-16 under the hood.

However, that would be a mistake because transforming your string to a C string and using bun's cstring type will be mildly faster.
Here's a benchmark done using a nice benchmark library mitata

function readStringU16(
  create_string_u16: (ptr: Uint16Array, len: number) => void,
): string {
  const length = 12;
  const buffer = new Uint16Array(length);
  create_string_u16(buffer, length)!;
  const decoder = new TextDecoder("utf-16");
  const copy = decoder.decode(buffer);
  return copy;
}

function readStringC(create_string_c: () => CString): string {
  const cstr = create_string_c();
  const copy = cstr.toString();
  return copy;
}

const readU16 = readStringU16.bind(null, create_string_u16);
const readC = readStringC.bind(null, create_string_c);
summary(() => {
  bench("read u16", readU16);
  bench("read c", readC);
});
await run({ colors: false });

const STRING: &str = "Hello, World";

#[no_mangle]
pub unsafe extern "C" fn create_string_u16(ptr: *mut u16, capacity: usize) {
    let buffer: &mut [u16] = unsafe { slice::from_raw_parts_mut(ptr, capacity) };
    let src: Vec<u16> = STRING.encode_utf16().collect::<Vec<u16>>();
    buffer.copy_from_slice(&src);
}

#[no_mangle]
pub extern "C" fn create_string_c() -> *const c_char {
    ManuallyDrop::new(CString::new(STRING).unwrap()).as_ptr()
}

benchmark              avg (min … max) p75   p99    (min … top 1%)
-------------------------------------- -------------------------------
read u16                  1.12 µs/iter   1.21 µs █▂
                 (905.96 ns … 1.83 µs)   1.79 µs ██▆▅▆▇▇▇▃▂▂▄▃▃▂▂▁▂▂▁▁
read c                  727.82 ns/iter 809.01 ns  █▂
                 (590.53 ns … 1.03 µs) 969.92 ns ▆███▆▆▇▃▆▄▄▆▃▄▆▆▃▂▃▂▂

summary
  read c
   1.54x faster than read u16

What about WebAssembly?

It's time to address the elephant in the room that is WebAssembly.
Should you choose nice existing WASM bindings over dealing with C ABI?

The answer is probably neither.

Is it actually worth it?

Introducing another language to your codebase will require more than just a single bottleneck to be worth it DX-wise and performance-wise.

Here is a benchmark for a simple range function in JS, WASM and Rust.

// rs.rs
#[no_mangle]
pub unsafe extern "C" fn rs_range(ptr: *mut i32, start: i32, end: i32) {
    let len: usize = usize::try_from(end - start).unwrap();
    let buffer: &mut [i32] = unsafe { slice::from_raw_parts_mut(ptr, len) };
    let src: Vec<i32> = (start..end).collect();
    buffer.copy_from_slice(&src);
}

// wasm.rs
#[wasm_bindgen]
pub fn wa_range(start: i32, end: i32) -> Vec<i32> {
    (start..end).collect()
}

function tsRange(start: number, end: number): number[] {
  return [...Array(end - start).keys()].map((x) => x + start);
}

function wrapWa(
  wa_range: (start: number, end: number) => Int32Array,
): (start: number, end: number) => number[] {
  return (start, end) => {
    return Array.from(wa_range(start, end));
  };
}

function wrapRs(
  rs_range: (ptr: Int32Array, start: number, end: number) => void,
): (start: number, end: number) => number[] {
  return (start, end) => {
    const buffer = new Int32Array(end - start);
    rs_range(buffer, start, end);
    return Array.from(buffer);
  };
}

await init();
const waRange = wrapWa(wa_range);
const rsRange = wrapRs(rs_range);

summary(() => {
  bench("ts", () => tsRange(100, 50000));
  bench("wa", () => waRange(100, 50000));
  bench("rs", () => rsRange(100, 50000));
});
await run({ colors: false });

benchmark              avg (min … max) p75   p99    (min … top 1%)
-------------------------------------- -------------------------------
ts                        1.33 ms/iter   1.25 ms  █                   
                 (802.90 µs … 5.29 ms)   4.22 ms ▂██▅▂▁▁▁▁▁▁▁▁▁▂▁▁▁▁▁▁
wa                        1.58 ms/iter   1.72 ms  █                   
                   (1.17 ms … 4.36 ms)   4.09 ms ██▄▃▄▃▂▁▁▁▁▁▁▁▁▁▁▁▁▁▁
rs                        1.47 ms/iter   1.43 ms ▂█                   
                   (1.17 ms … 4.11 ms)   3.84 ms ██▃▂▂▄▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁

summary
  ts
   1.1x faster than rs
   1.18x faster than wa

Native library barely beats out WASM and consistently loses to the pure TypeScript implementation.

And that's it for this tutorial for/exploration of bun:ffi module. Hopefully we all have walked away from this a little bit more educated.
Feel free to share thoughts and questions in the comments

Forem: Sby

Zed: The Editor I Wish I Liked

Searching for a Unicorn

Don't Take It Harshly

Wishlist for Santa

Minimap Is Useless

Shortcuts Slow You Down

Pointless Command Palette

Clunky Layout

No Workspaces

Everything Requires an Extension

Dull Design

There's Still Bloat

Still A Very Fast Horse

Unhinged JS Tooling Setups in 2025

State of JS tooling

The trade-offs

Minmaxing DX

package.json

.prettierrc

biome.json

.oxlintrc.json

eslint.config.mjs

Side note on Svelte

Conclusion

Creating a Browser Extension

Important Note

The Modern (not anymore) Way

Project Structure

How to Actually Do Something

Random Useful Trivia

Resources

How to Deserialize Internally Tagged JSON in C# with AoT compilation

1. Declare Context

2. Create Type Discriminators

2.1. Optional. Serializing Derived Types

3. Pass the Context

Conclusion

Syncing DOM State and Data without IDs

Problem: Managing Stateful DOM Elements in Dynamic Lists

Let's Set the Scene

The Wrong Approach: Using Array Index as a Key

What About Fully Managed State?

What If There's a Simpler Way?

Solution: Simpler Than You Thought

Examples: Usage in Practice

Conclusion

How to and Should you use Bun FFI

What are we trying to achieve

How to link the library to JavaScript

From JS side

Passing data through FFI boundary

Memory management

Allocate in Rust

Use FinalizationRegistry

Pros

Cons

Use toArrayBuffer's finalizationCallback parameter

Pros

Cons

Manage memory manually

Pros

Cons

Allocate in JS

A sidenote on strings

What about WebAssembly?

Is it actually worth it?

Use `FinalizationRegistry`

Use `toArrayBuffer`'s `finalizationCallback` parameter