Krzysztof Kowalczyk blog

Speeding up JavaScript function with AI help

2026-03-29T00:00:00Z

A new JavaScript library pretext for fast text measuring / layout popped up on social media.

Potentially interesting given its focus on speeding up text rendering in web apps and me writing web apps and liking them being fast.

I looked at the code and saw a function isCJK(). Given my 3 decades of programming and performance optimization, it looked like it could be sped up.

This is a story about ideas on making JavaScript faster and the process of quickly implementing and benchmarking them.

The code

export function isCJK(s: string): boolean {
  for (const ch of s) {
    const c = ch.codePointAt(0)!
    if ((c >= 0x4E00 && c <= 0x9FFF) ||
        (c >= 0x3400 && c <= 0x4DBF) ||
        (c >= 0x20000 && c <= 0x2A6DF) ||
        (c >= 0x2A700 && c <= 0x2B73F) ||
        (c >= 0x2B740 && c <= 0x2B81F) ||
        (c >= 0x2B820 && c <= 0x2CEAF) ||
        (c >= 0x2CEB0 && c <= 0x2EBEF) ||
        (c >= 0x30000 && c <= 0x3134F) ||
        (c >= 0xF900 && c <= 0xFAFF) ||
        (c >= 0x2F800 && c <= 0x2FA1F) ||
        (c >= 0x3000 && c <= 0x303F) ||
        (c >= 0x3040 && c <= 0x309F) ||
        (c >= 0x30A0 && c <= 0x30FF) ||
        (c >= 0xAC00 && c <= 0xD7AF) ||
        (c >= 0xFF00 && c <= 0xFFEF)) {
      return true
    }
  }
  return false
}

My spider sense tingling

To make code run fast you have to have mechanical sympathy. You need a good mental model of how CPUs and programming languages work, at the low level.

Because I have mechanical sympathy, I know that to evaluate multiple || statements, the program has to check every statement until it finds one that is true.

For the case of not matching any range, it has to do all 15 comparisons.

My immediate thought was that most characters are ascii (non-cjk) and therefore require 15 comparisons.

An early exit should speed things up: if (c < 0x300) continue;. It adds 1 comparison for matching cases but removes 14 (15 - 1) for the most common case of ascii characters.

Hunch is good, benchmark is better

Micro-benchmarking is subtle. In the past I would google for a JavaScript benchmarking library and trust that it’s sound.

Claude wrote a sound, simple benchmark function:

function bench(name, fn, iterations = 1_000_000) {
  for (let i = 0; i < 10_000; i++) fn(); // warmup
  const start = performance.now();
  for (let i = 0; i < iterations; i++) fn();
  const elapsed = performance.now() - start;
  const opsPerSec = ((iterations / elapsed) * 1000).toFixed(0);
  console.log(`${name}: ${elapsed.toFixed(2)} ms (${opsPerSec} ops/sec)`);
}

// to call:
bench("isCJKRegex       ", () => isCJKRegex(input));

The subtle part is warmup phase.

JavaScript JIT engines that you’re likely to use (v8 in Chrome, JavaScriptCore in Safari, SpiderMonkey in FireFox) have several optimization tiers and only do most aggressive optimization for frequently called functions.

The warmup phase forces JIT to compile fn with most aggressive settings.

This is only fair - I assume isCJK is called frequently. If it wasn’t, there’s no point sweating to optimize it.

The new AI normal

In the past I would have to manually implement each optimization idea.

With AI I can delegate the coding and therefore test more ideas.

The following was done with Claude 4.6.

100% vibe coding

There are levels of delegating things to AI. On the extreme side of giving up control is 100% vibe coding.

I had 2 ideas for performance optimization:

early exit
replace 15 linear checks with binary search

But what if I didn’t? What if I just ask AI to come up with ideas?

The following is my conversation with Claude 4.6 and what I’ve learned.

I created is_cjk.js file and pasted the original function.

look at is_cjk.js. come up with 2 ideas for how to speed up isCJK(). Implement those as separate functions and write a javascript micro-benchmark that compares those 2 new implementations against isCJK

Two ideas:

Pre-compiled regex — push the entire check into the native regex engine, avoiding JS-level for…of iteration and codePointAt() overhead.

Typed array bitmap for BMP — for BMP characters (the vast majority of real text), a Uint8Array bitmap gives O(1) lookup with a single array access. Fall back to range checks only for supplementary plane characters.

I have to admit: I recognize those as valid optimization ideas but they didn’t immediately occur to me.

Regex works because regex implementations in JavaScript engines are insanely optimized.

Bitmap is a known optimization for doing true/false lookup for numbers. Let’s say you have total range 0-255 and you want a function that checks if a number is in range 1-10, 20-30, 40-50, 60-70, 80-90. That’s 5 if statements, each doing 2 comparisons.

You can instead use 1 bit for each of the 256 numbers (i.e. ²⁵⁶⁄₈ = 32 bytes), pre-compute the array of bytes and set the bit for the ranges.

Then lookup is just math to get byte offset and bit, load the byte, check the bit. Super fast.

Claude not only wrote the benchmark function, 2 new implementations but also ran the benchmarks using node and showed me results in a readable way.

The bitmap approach was significantly faster.

Human assisted coding

Bitmap was the fastest and yet I discarded it using my human judgement.

The bitmap needed 65kB of memory and that’s just too much for this function.

That’s where human judgement comes in to improve collaboration with AI.

I didn’t specify that I also care about memory usage so AI wrote fast code that was using too much memory.

You’re benchmarking what?

Here’s another tricky part of benchmarking: knowing what you benchmark.

There are 3 popular JavaScript engines. Claude ran benchmarks using node which uses Chrome’s v8.

That’s good because that’s the most popular browser and therefore most popular JavaScript JIT engine.

It’s also good to sanity-check with at least one other JavaScript engine. bun uses Safari’s JavaScriptCore so I asked Claude:

run the tests using bun

The results were similar, which is good. We don’t want code that is fast in one engine but slow in another. We don’t control which browser the user of our code is running.

Continuing collaboration with AI

I had some more ideas so here’s the rest of my conversation with Claude.

don’t benchmark bitmap, it uses too much memory; write a variant of isCJK that does an early false exit if char is less than smallest

Early exit is my first insight I wanted to test.

As expected, early exit is good 2x speedup for latin strings, although regex beats it on cjk strings.

That is the curse of engineering trade-offs: you have to decide if you want to optimize for cjk strings or non-cjk strings.

now implement a variant that does inline bisect / binary search

That was my second idea: do a binary search instead of sequential if comparisons.

It was faster than original but slower than regex / early exit.

Also, Claude didn’t do what I meant. It stored the ranges as array:

// Flat array: [lo0, hi0, lo1, hi1, ...] sorted by lo
const cjkRanges = new Uint32Array([
  0x3000, 0x303f,
  0x3040, 0x309f,
  ...

That’s what I meant:

implement a variant isCJBisect that doesn’t use array but unrolls binary search logic into if statements

The implementation is gnarly:

function inCJKUnrolled(c) {
  if (c < 0x3000) return false;
  if (c < 0xff00) {
    if (c < 0x3400) {
      if (c < 0x3040) {
        return c <= 0x303f;
      } else if (c > 0x309f) {
        return c >= 0x30a0 && c <= 0x30ff;
      }
      return true;
  // ... more gnarly code

But what do I care? Claude wrote it. Arguably it’s hard for me to review for correctness but it’s perfectly testable. We can write a test to compare if it returns the same result as original function for every possible input.

As expected, unrolled version was faster than array-based but not always faster than regex or early exit.

But Claude wrote something that caught my eye:

The for…of + codePointAt iterator overhead remains the bottleneck shared by all non-regex variants on long strings.

It’s well known that for ... of loop is slower than for (let i = 0; i < n; i++). It’s one of those things that you need to know.

I knew this but I didn’t connect the dots in this particular case.

write variant of isCJKEarly which replaces for of with a faster loop

Result:

isCJKEarlyFast crushes everything across the board on both runtimes

The code for isCKJEarlyFast.

Looks like we have a winner:

Replacing for…of + codePointAt() with charCodeAt() + index loop eliminates the iterator overhead, which was the main bottleneck. The early c < 0x3000 bail then skips all range checks for ASCII/latin characters cheaply. Only regex still wins on Node’s long latin miss case thanks to V8’s native string scanning.

There’s a subtlety that makes the rewrite of for .. of into for (let i = 0; i < n; i++) tricky.

Logically JavaScript strings are composed from 16-bit numbers (characters). Some Unicode code-points are bigger than 16-bit and are stored as 2 16-bit numbers, called surrogate pairs.

So writing a loop over unicode codepoints needs to take this into account.

It’s tricky code but again, what do I care? Claude wrote it and it’s perfectly testable.

Pressing on

The good thing about claude writing most of the code and removing other tedium like running the benchmarks is that we can do more in the same amount of time.

So I explored even more.

I noticed:

export function isCJKUnrolled(s) {
  for (const ch of s) {
    if (inCJKUnrolled(ch.codePointAt(0))) return true;
  }
  return false;
}

What happens when inCJKUnrolled is inlined?

inline inCJKUnrolled into isCJKUnrolled

Result:

Done. Inlining didn’t help — it actually got slightly slower in most cases (the engine was already inlining the small function). No change in rankings; EarlyFast remains the winner.

Turns out it’s not faster, which was surprising. Inlining is supposed to remove overhead of function calls, which matters in loops.

Surprising isn’t bad. We run benchmarks to validate our hunches.

For completness, I wanted to compare with original where for .. of was rewritten.

also write original with for of replaced by standard for loop and bench all and give results as markdown table

Claude was nice enough to show benchmark results in a nicely formatted table, without me even asking. It just knows things.

But as you can see above, you can ask it for results in markdown table to e.g. include in a GitHub bug report.

Here are final results. The number is operations/second in millions. Higher is better.

Bun

Scenario	Original	Regex	Early	Bisect	Unrolled	EarlyFast	ForLoop
Single CJK	11M	22M	12M	12M	16M	79M	57M
Single latin	20M	24M	49M	21M	22M	40M	36M
CJK string	12M	18M	17M	12M	14M	42M	42M
Latin string	1.5M	4.7M	3.6M	3.0M	3.5M	17M	6.5M
Mixed string	6.5M	5.9M	9.9M	8.6M	13M	62M	34M

Node

Scenario	Original	Regex	Early	Bisect	Unrolled	EarlyFast	ForLoop
Single CJK	85M	54M	51M	44M	56M	112M	110M
Single latin	59M	72M	83M	55M	74M	115M	103M
CJK string	79M	55M	60M	55M	64M	90M	129M
Latin string	4.2M	57M	4.3M	2.8M	4.5M	12M	8.3M
Mixed string	14M	15M	16M	10M	15M	41M	38M

Conclusions

AI is a big unlock. It took me under 30 minutes to test various hypotheses and find out a significant speed up.

Without Claude it would take several hours and I would likely not do it at all. It’s just not important enough to spend a working day on it.

To get best results we still need to apply human judgement and guide the AI.

Programming expert knowledge

An expert is simply someone who knows things. We know things because we learn them.

If you were paying attention you might have learned the following things:

importance of warmup phase when benchmarking JIT compilers
for .. of is slower than for (let i = 0; i < n; i++)
regex matching in JavaScript engines is fast
subtlety of surrogate pairs in JavaScript strings
using bitmaps to speed up range lookups

Resources

All the code is in https://gist.github.com/kjk/bdbea9d90c3bb0454fbe26353c521bfd

I like to write fast code.

If you want a fast bookmark manager / note taker, try MarkLexis.

If you want a fast PDF / ebook / comic book reader for Windows, try SumatraPDF.

How to run msvc cl.exe from command-line (powershell)

2026-01-16T00:00:00Z

So you’ve installed Visual Studio and you want to run the compiler cl.exe from command-line. Microsoft makes it surprisingly hard.

They give you a shortcut which opens a terminal window with cmd.exe setup for compilation. But I don’t want a separate window, I want to use the terminal app.

You can run:

cmd.exe /k "C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Auxiliary\Build\vcvarsall.bat" x64 for VS 2022
cmd.exe /k "C:\Program Files\Microsoft Visual Studio\18\Community\VC\Auxiliary\Build\vcvarsall.bat" x64 for VS 2026

Your location can be different.

But I don’t want to run inside cmd.exe. I want to use powershell.

What does vcvarsall.bat do? Not much: it just sets some env variables and updates PATH env variable.

We can reverse-engineer what it does:

cmd.exe
set >before.txt
cmd.exe /k "C:\Program Files\Microsoft Visual Studio\18\Community\VC\Auxiliary\Build\vcvarsall.bat" x64
set >after.txt

Now compare before.txt and after.txt to see what changed. I asked AI to do it for me and here’s the beginning of what I found:

CommandPromptType=Native
DevEnvDir=C:\Program Files\Microsoft Visual Studio\2022\Community\Common7\IDE\
ExtensionSdkDir=C:\Program Files (x86)\Microsoft SDKs\Windows Kits\10\ExtensionSDKs
EXTERNAL_INCLUDE=C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.44.35207\include;C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.44.35207\ATLMFC\include;C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Auxiliary\VS\include;C:\Program Files (x86)\Windows Kits\10\include\10.0.26100.0\ucrt;C:\Program Files (x86)\Windows Kits\10\\include\10.0.26100.0\\um;C:\Program Files (x86)\Windows Kits\10\\include\10.0.26100.0\\shared;C:\Program Files (x86)\Windows Kits\10\\include\10.0.26100.0\\winrt;C:\Program Files (x86)\Windows Kits\10\\include\10.0.26100.0\\cppwinrt;C:\Program Files (x86)\Windows Kits\NETFXSDK\4.8\include\um
Framework40Version=v4.0
FrameworkDir=C:\Windows\Microsoft.NET\Framework64\
FrameworkDir64=C:\Windows\Microsoft.NET\Framework64\
... more stuff

I saved that to diff.txt file.

Now that we have that we can ask our friendly AI to convert this to a powershell function:

write powershell function that sets variables as seen in @diff.txt

I get something like this:

function set-msvc {
    <#
    .SYNOPSIS
        Sets Visual Studio Developer Command Prompt environment variables.
    .DESCRIPTION
        This function sets all the environment variables needed for Visual Studio 2022
        native x64 development, equivalent to running vcvars64.bat.
    .EXAMPLE
        Set-VsDevEnv
    #>
    [CmdletBinding()]
    param()

    $env:CommandPromptType = "Native"
    $env:DevEnvDir = "C:\Program Files\Microsoft Visual Studio\2022\Community\Common7\IDE\"

    ... more stuff

We need to change one thing: $env:PATH from absolute to just adding paths to current $env:PATH so that it’ll adapt to future changes in PATH.

Now add that to $PROFILE and you can type set-msvc to setup powershell to have access to cl.exe, msbuild and other tools.

Below is the whole function but note that this is only for amd64 toolset. For 32-bit or arm setup would be different. You can get by re-running the above logic for vcvarsall.bat with different arguments.

This is for VS 2026

function set-msvc {
    <#
    .SYNOPSIS
        Sets Visual Studio Developer Command Prompt environment variables.
    .DESCRIPTION
        This function sets all the environment variables needed for Visual Studio 18
        native x64 development, equivalent to running vcvars64.bat.
    .EXAMPLE
        Set-VsDevEnv
    #>
    [CmdletBinding()]
    param()

    $env:CommandPromptType = "Native"
    $env:DevEnvDir = "C:\Program Files\Microsoft Visual Studio\18\Community\Common7\IDE\"
    $env:ExtensionSdkDir = "C:\Program Files (x86)\Microsoft SDKs\Windows Kits\10\ExtensionSDKs"
    $env:EXTERNAL_INCLUDE = "C:\Program Files\Microsoft Visual Studio\18\Community\VC\Tools\MSVC\14.44.35207\include;C:\Program Files\Microsoft Visual Studio\18\Community\VC\Tools\MSVC\14.44.35207\ATLMFC\include;C:\Program Files\Microsoft Visual Studio\18\Community\VC\Auxiliary\VS\include;C:\Program Files (x86)\Windows Kits\10\include\10.0.26100.0\ucrt;C:\Program Files (x86)\Windows Kits\10\\include\10.0.26100.0\\um;C:\Program Files (x86)\Windows Kits\10\\include\10.0.26100.0\\shared;C:\Program Files (x86)\Windows Kits\10\\include\10.0.26100.0\\winrt;C:\Program Files (x86)\Windows Kits\10\\include\10.0.26100.0\\cppwinrt;C:\Program Files (x86)\Windows Kits\NETFXSDK\4.8\include\um"
    $env:Framework40Version = "v4.0"
    $env:FrameworkDir = "C:\Windows\Microsoft.NET\Framework64\"
    $env:FrameworkDir64 = "C:\Windows\Microsoft.NET\Framework64\"
    $env:FrameworkVersion = "v4.0.30319"
    $env:FrameworkVersion64 = "v4.0.30319"
    $env:FSHARPINSTALLDIR = "C:\Program Files\Microsoft Visual Studio\18\Community\Common7\IDE\CommonExtensions\Microsoft\FSharp\Tools"
    $env:HTMLHelpDir = "C:\Program Files (x86)\HTML Help Workshop"
    $env:INCLUDE = "C:\Program Files\Microsoft Visual Studio\18\Community\VC\Tools\MSVC\14.44.35207\include;C:\Program Files\Microsoft Visual Studio\18\Community\VC\Tools\MSVC\14.44.35207\ATLMFC\include;C:\Program Files\Microsoft Visual Studio\18\Community\VC\Auxiliary\VS\include;C:\Program Files (x86)\Windows Kits\10\include\10.0.26100.0\ucrt;C:\Program Files (x86)\Windows Kits\10\\include\10.0.26100.0\\um;C:\Program Files (x86)\Windows Kits\10\\include\10.0.26100.0\\shared;C:\Program Files (x86)\Windows Kits\10\\include\10.0.26100.0\\winrt;C:\Program Files (x86)\Windows Kits\10\\include\10.0.26100.0\\cppwinrt;C:\Program Files (x86)\Windows Kits\NETFXSDK\4.8\include\um"
    $env:is_x64_arch = "true"
    $env:LIB = "C:\Program Files\Microsoft Visual Studio\18\Community\VC\Tools\MSVC\14.44.35207\ATLMFC\lib\x64;C:\Program Files\Microsoft Visual Studio\18\Community\VC\Tools\MSVC\14.44.35207\lib\x64;C:\Program Files (x86)\Windows Kits\NETFXSDK\4.8\lib\um\x64;C:\Program Files (x86)\Windows Kits\10\lib\10.0.26100.0\ucrt\x64;C:\Program Files (x86)\Windows Kits\10\\lib\10.0.26100.0\\um\x64"
    $env:LIBPATH = "C:\Program Files\Microsoft Visual Studio\18\Community\VC\Tools\MSVC\14.44.35207\ATLMFC\lib\x64;C:\Program Files\Microsoft Visual Studio\18\Community\VC\Tools\MSVC\14.44.35207\lib\x64;C:\Program Files\Microsoft Visual Studio\18\Community\VC\Tools\MSVC\14.44.35207\lib\x86\store\references;C:\Program Files (x86)\Windows Kits\10\UnionMetadata\10.0.26100.0;C:\Program Files (x86)\Windows Kits\10\References\10.0.26100.0;C:\Windows\Microsoft.NET\Framework64\v4.0.30319"
    $env:NETFXSDKDir = "C:\Program Files (x86)\Windows Kits\NETFXSDK\4.8\"
    $env:Path = "C:\Program Files\Microsoft Visual Studio\18\Community\VC\Tools\MSVC\14.44.35207\bin\HostX64\x64;C:\Program Files\Microsoft Visual Studio\18\Community\Common7\IDE\VC\VCPackages;C:\Program Files\Microsoft Visual Studio\18\Community\Common7\IDE\CommonExtensions\Microsoft\TestWindow;C:\Program Files\Microsoft Visual Studio\18\Community\Common7\IDE\CommonExtensions\Microsoft\TeamFoundation\Team Explorer;C:\Program Files\Microsoft Visual Studio\18\Community\MSBuild\Current\bin\Roslyn;C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.8 Tools\x64\;C:\Program Files (x86)\HTML Help Workshop;C:\Program Files\Microsoft Visual Studio\18\Community\Common7\IDE\CommonExtensions\Microsoft\FSharp\Tools;C:\Program Files\Microsoft Visual Studio\18\Community\Team Tools\DiagnosticsHub\Collector;C:\Program Files\Microsoft Visual Studio\18\Community\VC\Tools\Llvm\x64\bin;C:\Program Files (x86)\Windows Kits\10\bin\10.0.26100.0\\x64;C:\Program Files (x86)\Windows Kits\10\bin\\x64;C:\Program Files\Microsoft Visual Studio\18\Community\\MSBuild\Current\Bin\amd64;C:\Windows\Microsoft.NET\Framework64\v4.0.30319;C:\Program Files\Microsoft Visual Studio\18\Community\Common7\IDE\;C:\Program Files\Microsoft Visual Studio\18\Community\Common7\Tools\;" + $env:Path + ";C:\Program Files\Microsoft Visual Studio\18\Community\Common7\IDE\CommonExtensions\Microsoft\CMake\CMake\bin;C:\Program Files\Microsoft Visual Studio\18\Community\Common7\IDE\CommonExtensions\Microsoft\CMake\Ninja;C:\Program Files\Microsoft Visual Studio\18\Community\Common7\IDE\VC\Linux\bin\ConnectionManagerExe;C:\Program Files\Microsoft Visual Studio\18\Community\VC\vcpkg"
    $env:Platform = "x64"
    $env:UCRTVersion = "10.0.26100.0"
    $env:UniversalCRTSdkDir = "C:\Program Files (x86)\Windows Kits\10\"
    $env:VCIDEInstallDir = "C:\Program Files\Microsoft Visual Studio\18\Community\Common7\IDE\VC\"
    $env:VCINSTALLDIR = "C:\Program Files\Microsoft Visual Studio\18\Community\VC\"
    $env:VCPKG_ROOT = "C:\Program Files\Microsoft Visual Studio\18\Community\VC\vcpkg"
    $env:VCToolsInstallDir = "C:\Program Files\Microsoft Visual Studio\18\Community\VC\Tools\MSVC\14.44.35207\"
    $env:VCToolsRedistDir = "C:\Program Files\Microsoft Visual Studio\18\Community\VC\Redist\MSVC\14.44.35112\"
    $env:VCToolsVersion = "14.44.35207"
    $env:VisualStudioVersion = "17.0"
    $env:VS170COMNTOOLS = "C:\Program Files\Microsoft Visual Studio\18\Community\Common7\Tools\"
    $env:VSCMD_ARG_app_plat = "Desktop"
    $env:VSCMD_ARG_HOST_ARCH = "x64"
    $env:VSCMD_ARG_TGT_ARCH = "x64"
    $env:VSCMD_VER = "17.14.24"
    $env:VSINSTALLDIR = "C:\Program Files\Microsoft Visual Studio\18\Community\"
    $env:WindowsLibPath = "C:\Program Files (x86)\Windows Kits\10\UnionMetadata\10.0.26100.0;C:\Program Files (x86)\Windows Kits\10\References\10.0.26100.0"
    $env:WindowsSdkBinPath = "C:\Program Files (x86)\Windows Kits\10\bin\"
    $env:WindowsSdkDir = "C:\Program Files (x86)\Windows Kits\10\"
    $env:WindowsSDKLibVersion = "10.0.26100.0\"
    $env:WindowsSdkVerBinPath = "C:\Program Files (x86)\Windows Kits\10\bin\10.0.26100.0\"
    $env:WindowsSDKVersion = "10.0.26100.0\"
    $env:WindowsSDK_ExecutablePath_x64 = "C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.8 Tools\x64\"
    $env:WindowsSDK_ExecutablePath_x86 = "C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.8 Tools\"
    $env:__DOTNET_ADD_64BIT = "1"
    $env:__DOTNET_PREFERRED_BITNESS = "64"
    $env:__VSCMD_PREINIT_PATH = "C:\Program Files\PowerShell\7;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Windows\System32\OpenSSH\;C:\Program Files\Microsoft VS Code\bin;c:\Users\kjk\AppData\Local\Programs\cursor\resources\app\bin;C:\Program Files\gs\gs10.03.1\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\;C:\WINDOWS\System32\OpenSSH\;C:\Program Files\GitHub CLI\;C:\Program Files (x86)\Windows Kits\10\Windows Performance Toolkit\;C:\Program Files\Rust stable MSVC 1.88\bin;C:\Program Files\PowerShell\7\;C:\Program Files\nodejs\;C:\Program Files\dotnet\;C:\Program Files\CMake\bin;C:\Program Files\Go\bin;C:\Program Files\RedHat\Podman\;C:\Program Files\Tailscale\;C:\Program Files\Git\cmd;C:\Program Files\Docker\Docker\resources\bin;C:\Users\kjk\AppData\Local\Microsoft\WindowsApps;C:\Users\kjk\AppData\Local\Microsoft\WinGet\Links;C:\Users\kjk\.bun\bin;C:\Users\kjk\.dotnet\tools;C:\Users\kjk\go\bin;C:\Users\kjk\AppData\Local\Programs\superfile\;C:\Users\kjk\AppData\Local\Microsoft\WindowsApps;C:\Users\kjk\AppData\Local\GitHubDesktop\bin;C:\Users\kjk\AppData\Local\Programs\cursor\resources\app\bin;C:\Users\kjk\AppData\Roaming\npm;C:\Users\kjk\.dotnet\tools;C:\Users\kjk\AppData\Local\Programs\Antigravity\bin;C:\Users\kjk\AppData\Local\Programs\Zed\bin;C:\Users\kjk\go\bin;C:\Users\kjk\OneDrive\bin;C:\Users\kjk\.bin\jai\bin;C:\Users\kjk\.bin\mupdf-1.27.0;C:\Users\kjk\.local\bin;C:\Users\kjk\AppData\Local\Programs\WinMerge;C:\Users\kjk\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.12_qbz5n2kfra8p0\LocalCache\local-packages\Python312\Scripts;C:\Users\kjk\OneDrive\bin\sublime_text"

    Write-Host "Visual Studio 2026 Developer Environment configured for x64." -ForegroundColor Green
}

This is for VS 2022:

function set-msvc {
    <#
    .SYNOPSIS
        Sets Visual Studio Developer Command Prompt environment variables.
    .DESCRIPTION
        This function sets all the environment variables needed for Visual Studio 2022
        native x64 development, equivalent to running vcvars64.bat.
    .EXAMPLE
        Set-VsDevEnv
    #>
    [CmdletBinding()]
    param()

    $env:CommandPromptType = "Native"
    $env:DevEnvDir = "C:\Program Files\Microsoft Visual Studio\2022\Community\Common7\IDE\"
    $env:ExtensionSdkDir = "C:\Program Files (x86)\Microsoft SDKs\Windows Kits\10\ExtensionSDKs"
    $env:EXTERNAL_INCLUDE = "C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.44.35207\include;C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.44.35207\ATLMFC\include;C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Auxiliary\VS\include;C:\Program Files (x86)\Windows Kits\10\include\10.0.26100.0\ucrt;C:\Program Files (x86)\Windows Kits\10\\include\10.0.26100.0\\um;C:\Program Files (x86)\Windows Kits\10\\include\10.0.26100.0\\shared;C:\Program Files (x86)\Windows Kits\10\\include\10.0.26100.0\\winrt;C:\Program Files (x86)\Windows Kits\10\\include\10.0.26100.0\\cppwinrt;C:\Program Files (x86)\Windows Kits\NETFXSDK\4.8\include\um"
    $env:Framework40Version = "v4.0"
    $env:FrameworkDir = "C:\Windows\Microsoft.NET\Framework64\"
    $env:FrameworkDir64 = "C:\Windows\Microsoft.NET\Framework64\"
    $env:FrameworkVersion = "v4.0.30319"
    $env:FrameworkVersion64 = "v4.0.30319"
    $env:FSHARPINSTALLDIR = "C:\Program Files\Microsoft Visual Studio\2022\Community\Common7\IDE\CommonExtensions\Microsoft\FSharp\Tools"
    $env:HTMLHelpDir = "C:\Program Files (x86)\HTML Help Workshop"
    $env:INCLUDE = "C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.44.35207\include;C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.44.35207\ATLMFC\include;C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Auxiliary\VS\include;C:\Program Files (x86)\Windows Kits\10\include\10.0.26100.0\ucrt;C:\Program Files (x86)\Windows Kits\10\\include\10.0.26100.0\\um;C:\Program Files (x86)\Windows Kits\10\\include\10.0.26100.0\\shared;C:\Program Files (x86)\Windows Kits\10\\include\10.0.26100.0\\winrt;C:\Program Files (x86)\Windows Kits\10\\include\10.0.26100.0\\cppwinrt;C:\Program Files (x86)\Windows Kits\NETFXSDK\4.8\include\um"
    $env:is_x64_arch = "true"
    $env:LIB = "C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.44.35207\ATLMFC\lib\x64;C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.44.35207\lib\x64;C:\Program Files (x86)\Windows Kits\NETFXSDK\4.8\lib\um\x64;C:\Program Files (x86)\Windows Kits\10\lib\10.0.26100.0\ucrt\x64;C:\Program Files (x86)\Windows Kits\10\\lib\10.0.26100.0\\um\x64"
    $env:LIBPATH = "C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.44.35207\ATLMFC\lib\x64;C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.44.35207\lib\x64;C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.44.35207\lib\x86\store\references;C:\Program Files (x86)\Windows Kits\10\UnionMetadata\10.0.26100.0;C:\Program Files (x86)\Windows Kits\10\References\10.0.26100.0;C:\Windows\Microsoft.NET\Framework64\v4.0.30319"
    $env:NETFXSDKDir = "C:\Program Files (x86)\Windows Kits\NETFXSDK\4.8\"
    $env:Path = "C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.44.35207\bin\HostX64\x64;C:\Program Files\Microsoft Visual Studio\2022\Community\Common7\IDE\VC\VCPackages;C:\Program Files\Microsoft Visual Studio\2022\Community\Common7\IDE\CommonExtensions\Microsoft\TestWindow;C:\Program Files\Microsoft Visual Studio\2022\Community\Common7\IDE\CommonExtensions\Microsoft\TeamFoundation\Team Explorer;C:\Program Files\Microsoft Visual Studio\2022\Community\MSBuild\Current\bin\Roslyn;C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.8 Tools\x64\;C:\Program Files (x86)\HTML Help Workshop;C:\Program Files\Microsoft Visual Studio\2022\Community\Common7\IDE\CommonExtensions\Microsoft\FSharp\Tools;C:\Program Files\Microsoft Visual Studio\2022\Community\Team Tools\DiagnosticsHub\Collector;C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\Llvm\x64\bin;C:\Program Files (x86)\Windows Kits\10\bin\10.0.26100.0\\x64;C:\Program Files (x86)\Windows Kits\10\bin\\x64;C:\Program Files\Microsoft Visual Studio\2022\Community\\MSBuild\Current\Bin\amd64;C:\Windows\Microsoft.NET\Framework64\v4.0.30319;C:\Program Files\Microsoft Visual Studio\2022\Community\Common7\IDE\;C:\Program Files\Microsoft Visual Studio\2022\Community\Common7\Tools\;" + $env:Path + ";C:\Program Files\Microsoft Visual Studio\2022\Community\Common7\IDE\CommonExtensions\Microsoft\CMake\CMake\bin;C:\Program Files\Microsoft Visual Studio\2022\Community\Common7\IDE\CommonExtensions\Microsoft\CMake\Ninja;C:\Program Files\Microsoft Visual Studio\2022\Community\Common7\IDE\VC\Linux\bin\ConnectionManagerExe;C:\Program Files\Microsoft Visual Studio\2022\Community\VC\vcpkg"
    $env:Platform = "x64"
    $env:UCRTVersion = "10.0.26100.0"
    $env:UniversalCRTSdkDir = "C:\Program Files (x86)\Windows Kits\10\"
    $env:VCIDEInstallDir = "C:\Program Files\Microsoft Visual Studio\2022\Community\Common7\IDE\VC\"
    $env:VCINSTALLDIR = "C:\Program Files\Microsoft Visual Studio\2022\Community\VC\"
    $env:VCPKG_ROOT = "C:\Program Files\Microsoft Visual Studio\2022\Community\VC\vcpkg"
    $env:VCToolsInstallDir = "C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.44.35207\"
    $env:VCToolsRedistDir = "C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Redist\MSVC\14.44.35112\"
    $env:VCToolsVersion = "14.44.35207"
    $env:VisualStudioVersion = "17.0"
    $env:VS170COMNTOOLS = "C:\Program Files\Microsoft Visual Studio\2022\Community\Common7\Tools\"
    $env:VSCMD_ARG_app_plat = "Desktop"
    $env:VSCMD_ARG_HOST_ARCH = "x64"
    $env:VSCMD_ARG_TGT_ARCH = "x64"
    $env:VSCMD_VER = "17.14.24"
    $env:VSINSTALLDIR = "C:\Program Files\Microsoft Visual Studio\2022\Community\"
    $env:WindowsLibPath = "C:\Program Files (x86)\Windows Kits\10\UnionMetadata\10.0.26100.0;C:\Program Files (x86)\Windows Kits\10\References\10.0.26100.0"
    $env:WindowsSdkBinPath = "C:\Program Files (x86)\Windows Kits\10\bin\"
    $env:WindowsSdkDir = "C:\Program Files (x86)\Windows Kits\10\"
    $env:WindowsSDKLibVersion = "10.0.26100.0\"
    $env:WindowsSdkVerBinPath = "C:\Program Files (x86)\Windows Kits\10\bin\10.0.26100.0\"
    $env:WindowsSDKVersion = "10.0.26100.0\"
    $env:WindowsSDK_ExecutablePath_x64 = "C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.8 Tools\x64\"
    $env:WindowsSDK_ExecutablePath_x86 = "C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.8 Tools\"
    $env:__DOTNET_ADD_64BIT = "1"
    $env:__DOTNET_PREFERRED_BITNESS = "64"
    $env:__VSCMD_PREINIT_PATH = "C:\Program Files\PowerShell\7;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Windows\System32\OpenSSH\;C:\Program Files\Microsoft VS Code\bin;c:\Users\kjk\AppData\Local\Programs\cursor\resources\app\bin;C:\Program Files\gs\gs10.03.1\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\;C:\WINDOWS\System32\OpenSSH\;C:\Program Files\GitHub CLI\;C:\Program Files (x86)\Windows Kits\10\Windows Performance Toolkit\;C:\Program Files\Rust stable MSVC 1.88\bin;C:\Program Files\PowerShell\7\;C:\Program Files\nodejs\;C:\Program Files\dotnet\;C:\Program Files\CMake\bin;C:\Program Files\Go\bin;C:\Program Files\RedHat\Podman\;C:\Program Files\Tailscale\;C:\Program Files\Git\cmd;C:\Program Files\Docker\Docker\resources\bin;C:\Users\kjk\AppData\Local\Microsoft\WindowsApps;C:\Users\kjk\AppData\Local\Microsoft\WinGet\Links;C:\Users\kjk\.bun\bin;C:\Users\kjk\.dotnet\tools;C:\Users\kjk\go\bin;C:\Users\kjk\AppData\Local\Programs\superfile\;C:\Users\kjk\AppData\Local\Microsoft\WindowsApps;C:\Users\kjk\AppData\Local\GitHubDesktop\bin;C:\Users\kjk\AppData\Local\Programs\cursor\resources\app\bin;C:\Users\kjk\AppData\Roaming\npm;C:\Users\kjk\.dotnet\tools;C:\Users\kjk\AppData\Local\Programs\Antigravity\bin;C:\Users\kjk\AppData\Local\Programs\Zed\bin;C:\Users\kjk\go\bin;C:\Users\kjk\OneDrive\bin;C:\Users\kjk\.bin\jai\bin;C:\Users\kjk\.bin\mupdf-1.27.0;C:\Users\kjk\.local\bin;C:\Users\kjk\AppData\Local\Programs\WinMerge;C:\Users\kjk\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.12_qbz5n2kfra8p0\LocalCache\local-packages\Python312\Scripts;C:\Users\kjk\OneDrive\bin\sublime_text"

    Write-Host "Visual Studio 2022 Developer Environment configured for x64." -ForegroundColor Green
}

Novel login system for web apps

2025-12-22T00:00:00Z

Anna’s Archive implements an interesting, anonymous way to create an account for web applications.

They don’t use e-mail, Google or GitHub logins. When you create an account, they generate a secret key. That secret key is used to login.

The downside is that if you loose they, you loose access to the account.

The interesting thing is anonymity: the operator of the web app doesn’t even have your e-mail address.

This is one of those things that are obvious once you learn it but would be very hard to come up on your own because thinking outside of the box is very hard.

Benchmarking JSON vs TOON in Go

2025-12-15T00:00:00Z

Since I’ve decided to use TOON instead of JSON, I’ve benchmarked the performance of serialization of 2 Go TOON libraries compared to JSON built-in serialization.

Here are the results using current version of the libraries and go 1.25:

% go run .
goos: darwin
goarch: arm64
pkg: bench_toon
cpu: Apple M3 Pro
BenchmarkJSONMarshalCompact-11    	 3488496	       322.3 ns/op
BenchmarkJSONMarshal-11           	  767379	      1546 ns/op
BenchmarkToonMarshal-11           	  669687	      1782 ns/op
BenchmarkGotoonEncode-11          	  161412	      7506 ns/op
PASS
ok  	bench_toon	5.143s

The code is here.

Benchmarks:

What we learned is:

github.com/toon-format/toon-go is comparable to pretty-printed JSON, which is fair because TOON format is also pretty-printed (and can’t be compacted)
github.com/alpkeskin/gotoon is significantly slower than github.com/toon-format/toon-go
JSON compact is way faster than everything else

What it means to me is that speed of TOON serialization in Go is not deal breaker. Program would have to spend most of the time serializing for the speed difference to matter.

The readibility of TOON format justifies using it in most cases instead of JSON.

Using github.com/toon-format/toon-go:

import (
	"github.com/toon-format/toon-go"
)

type Foo struct {
  Data string
}

v := Foo{Data: "hello"}
data, err := toon.Marshal(v)
if err != nil {
	log.Fatal(err)
  return
}
fmt.Println(string(data))

From JSON to TOON

2025-12-15T00:00:00Z

TOON stands for a Token-Oriented Object Notation.

It’s a new text format that has the same capability as JSON but uses less space.

It was invented to lower costs of sending data (tokens) to LLM AIs but it has 2 advantages over JSON:

smaller than JSON
more readable than JSON

It has implementation in many programming languages, including those I care about: JavaScript and Go.

Therefore it’s a good use for non-AI cases e.g.:

logging structured data
sending data from server to client

Here’s an example of JSON and TOON formats:

{
  "table": "A",
  "currency": "dolaramerykański",
  "code": "USD",
  "rates": [
    {
      "no": "001/A/NBP/2024",
      "effectiveDate": "2024-01-02",
      "mid": 3.9432
    },
    {
      "no": "002/A/NBP/2024",
      "effectiveDate": "2024-01-03",
      "mid": 3.9909
    },
  ]
}

table: A
currency: dolaramerykański
code: USD
rates[252]{no,effectiveDate,mid}:
  001/A/NBP/2024,2024-01-02,3.9432
  002/A/NBP/2024,2024-01-03,3.9909

As a result, I’m switching to using TOON whenever possible.

Fixing Zed's debugger keybindings

2025-07-22T00:00:00Z

Zed has a good debugger built-in but their keybindings are crazy. Thankfully, you can remap them by opening menu Zed / Settings / Open key bindings and adding this to the file:

  {
    "use_key_equivalents": true,
    "bindings": {
      "f11": "debugger::StepInto",
      "f10": "debugger::StepOver"
      // "shift shift": "file_finder::Toggle"
    }
  },

Those are standard Windows debugging keybindings. F7 and Ctrl + F11 just don’t make sense to me.

Ideas for faster web dev cycle

2025-07-22T00:00:00Z

I strongly believe that fast iteration cycle is important for productivity. In programming fast iteration means: how quickly can I go from finishing writing the code to testing it. That’s why I don’t like languages that compile slowly: slow compilation puts a hard limit on your iteration cycle.

That’s a general principle. How does it translate to actions?

I’m glad you asked.

Simulated errors

I’m writing a web app and some code paths might fail e.g. server returns an error response.

When that happens I want to display an error message to the user. I want to test that but server doesn’t typically return errors.

I can modify the server to return error and restart it but in a compiled language like Go it’s a whole thing.

Instead I can force error condition in the code. Because web dev typically offers hot reload of code, I can modify the code to pretend the request failed, save the code, reload the app and I’m testing the error handling.

To make it less ad-hoc another strategy is to have debug flags on window object e.g.:

window.debug.simulateError = false

Then the code will have:

try {
	if (window.debug.simulateError) {
		throw Error("fetch failed");
	}
	let rsp = await fetch(...);
}

That way I can toggle window.debug.simulateError in dev tools console, without changing the code.

I have to repeat this code for every fetch(). More principled approach is:

async function myFetch(uri, opts) {
	if (window.debug.simulateError) {
		throw new Error("featch failed");
	}
	return await fetch(uri, opts);
}

To go even further, we could simulate different kinds of network errors:

Response.ok is false
response is 404 or 500
failed to reach the server

We can change simulateError from bool to a number and have:

async function myFetch(uri, opts) {
	let se = window.debug.simulateError;
	if (se === 1) {
		// simulate Response.ok is false
		return ...;
	}
	if (se === 2) {
		// simulate 404 response
		return;
	}
	if (se === 3) {
		// simulate network offline
	}
	return await fetch(uri, opts);	
}

Start by show dialog

Let’s say I’m working on a new dialog e.g. rename dialog. To get to that dialog I have to perform some UI action e.g. use context menu and click the Rename note menu item.

Not a big deal but I’m still working on the dialog so it’s a bit annoying to repeat that UI action every time I move the button to the right, to see how it’ll look.

In Svelte we do:

let showingRenameDialog = $state(false);
function showRenameDialog() { showingRenameDialog = true; }
{#if showingRenameDialog}
	<RenameDialog ...></RenameDialog>
{'if}

To speed up dev cycle:

let showingRenameDialog = $state(true); // show while we're working ont

While I’m still designing and writing code for the dialog, show it by default. That way app reloads due to changing code won’t require you to manually redo UI actions to trigger the dialog.

Ad-hoc test code

Let’s say you’re writing a non-trivial code server code to process a request. Let’s say the request is a POST with body containing zip file with images which the server needs to unzip, resize the files, save them to a file system.

You want to test it as you implement the logic but iteration cycle is slow:

you write the code
recompile and restart the server
go through UI actions to send the request

Most of the code (unpacking zip file, resizing images) can be tested without doing the request. So you isolate the function:

func resizeImagesInZip(zipData []byte) error {
	// the code you're writing on
}

Now you have to trigger it easily. The simplest way is ad-hoc test code:

func main() {
	if true {
		zipData := loadTestZipFileMust()
		resizeImagesInZip(zipData);
		return;
	}
}

While you’re working on the code, the server just runs the test code. When you’re done, you switch it off:

func main() {
	if false {
		// leave the code so that you can re-enable it
		// easily in the future
		zipData := loadTestZipFileMust()
		resizeImagesInZip(zipData);
		return;
	}
}

Those are few tactical tips to increase dev cycles.

You can come up with more such ideas by asking yourself: how can I speed iteration cycle?

Zed debug setup for go server / Svelte web app

2025-07-21T00:00:00Z

Today I figured out how to setup Zed to debug, at the same time, my go server and Svelte web app.

My dev setup for working on my web app is:

go server is run with -run-dev arg
go server provides backend apis and proxies requests it doesn’t handle to a vite dev server that does the serving of JavaScript etc. files from my Svelte code
go server in -run-dev mode automatically launches vite dev
go server runs on port 9339

It’s possible to setup Zed to debug both server and frontend JavaScript code. In retrospect it’s simple, but took me a moment to figure out.

I needed to create the following .zed/debug.json:

// Project-local debug tasks
//
// For more documentation on how to configure debug tasks,
// see: https://zed.dev/docs/debugger
[
  {
    "adapter": "Delve",
    "label": "run go server",
    "request": "launch",
    "mode": "debug",
    "program": ".",
    "cwd": "${ZED_WORKTREE_ROOT}",
    "args": ["-run-dev", "-no-open"],
    "buildFlags": [],
    "env": {}
  },
  {
    "adapter": "JavaScript",
    "label": "Debug in Chrome",
    "type": "chrome",
    "request": "launch",
    "url": "http://localhost:9339/",
    "webRoot": "$ZED_WORKTREE_ROOT/src",
    "console": "integratedTerminal",
    "skipFiles": ["<node_internals>/**"]
  }
]

It’s mostly self-exploratory.

First entry tells Zed to build go program with go build . and run the resulting executable under the debugger with -run-dev -no-open args.

Second entry tells to launch Chrome in debug mode with http://localhost:9339/ and that files seen by Chrome come from src/ directory i.e. if browser loads /foo.js the source file is src/foo.js. This is necessary to be able to set breakpoints in Zed and have them propagate to Chrome.

This eliminates the need for terminal so I can edit and debug with just Zed and Chrome.

This is a great setup. I’m impressed with Zed.

Stage manager in Mac OS

2025-07-21T00:00:00Z

Stage Manager in Mac OS is not a secret, but I’ve only learned about it recently.

It’s off by default so you have to enable it in system settings: It’s hard to describe in words, so you’ll have to try it. And experiment a bit because I didn’t get in the first hour.

It’s a certain way to manage windows for less clutter. Imagine you have a browser, an editor and a terminal i.e. 3 windows. Might be annoying to have them all shown on screen.

When Stage Manager is enabled, thumbnails of windows are on the left edge of the screen and you can switch to the window by clicking the thumbnail.

By default Stage Manager shows each window by itself on screen. You can group them by dragging thumbnail onto screen. For example, when I’m developing, I’m using text editor and terminal so I will group them so they are both visible on screen at the same time, but not the other apps.

So far I’m enjoying using Stage Manager.

AltTab for Mac OS

2025-07-21T00:00:00Z

AltTab solves a simple problem really well: it brings Windows-style Alt + Tab window switching to Mac OS.

That’s it. That’s all there is to it.

I think Windows way of Alt - tabbing windows is better than Mac’s.

It’s a must for someone like me, who switches between using Windows and Mac OS. That small difference drove me mad when using Mac so super thankful someone wrote an app that fixes it.

It’s free and open source so no excuse to not to use it.

lazy import of JavaScript modules

2025-07-20T00:00:00Z

When working on big JavaScript web apps, you can split the bundle in multiple chunks and import selected chunks lazily, only when needed. That makes the main bundle smaller, faster to load and parse.

How to lazy import a module?

let hljs = await import("highlight.js").default;

is equivalent of:

import hljs from "highlight.js";

Now:

let libZip = await import("@zip.js/zip.js");
let blobReader = new libZip.BlobReader(blob);

Is equivalent to:

import { BlobReader } from "@zip.js/zip.js";

It’s simple if we call it from async function but sometimes we want to lazy load from non-async function so things might get more complicated:

let isLazyImportng = false;
let hljs;
let markdownIt;
let markdownItAnchor;
async function lazyImports() {
if (isLazyImportng) return;
isLazyImportng = true;
let promises = await Promise.all([
  import("highlight.js"),
  import("markdown-it"),
  import("markdown-it-anchor"),
]);

hljs = promises[0].default;
markdownIt = promises[1].default;
markdownItAnchor = promises[2].default;
}

We can run it from non-async function:


function doit() {
	lazyImports().then( () => {
		if (hljs) {
			// use hljs to do something
		}
	})
}

I’ve included protection against kicking of lazy import more than once. That means on second and n-th call we might not yet have the module loaded so hljs will be still undefined.

Using await in Svelte 5 components

2025-07-20T00:00:00Z

Svelte 5 just added a way to use async function in components. This is from Rich Harris talk

The simplest component

<script>
async function multiply(x, y) {
	let uri = `/multiply?x=${x}&y=${y}`
	let rsp = await fetch(uri)
	let resp = await rsp.text();
	return parseInt(resp);
}
let n = $state(2)
</script>

<div>{n} * 2 = {await multiply(n, 2)}</div>

Previously you couldn’t do {await multiply(n, 2) because Svelte didn’t understand promises. Now you can.

Aborting outdated requests

Imagine getting search results from a server based on what you type in an input box.

If you type foo, we first send request for f, then for fo then for foo at which point we don’t care about the results for f and fo. Svelte 5 can handle aborting outdated requests:

<script>
import { getAbortSignal } from "svelte";
let search = $state("")
const API = "https://dummyjson.com/product/search";
const response = $derived(await fetch(`${API}?q=${search}`), {
	signal: getAbortSignal()
})
</script>

<input bind:value={search}>

<svelte:boundary>
<ul>
	{#each (await response.json().products as product)}
		<li>{product.title}</li>
	{/each}
</ul>

vite /rollup manualChunks

2025-07-19T00:00:00Z

In MS-DOS days programmers were limited to 640 kB of code. When their programs became bigger than that they had to implement tricky code to load / unload code chunks on demand.

In web apps we’re not limited by size but it’s still a good idea to strive for the smallest possible JavaScript bundle. We can do it by extracting rarely used pieces of functionality into separate JavaScript chunks and import them lazily. This makes the app faster to load, faster to parse and run.

For example, in Edna I use markdown-it and highlight.js library only in a certain scenario. By putting it in it’s separate chunk, I save almost 1 MB of uncompressed JavaScript in main bundle. Faster to download, faster to run.

../dist/assets/markdownit-hljs-DbctGXX9.js          1,087.33 kB │ gzip: 358.42 kB

To split in chunks you configure rollup in vite.config.js:


function manualChunks(id) {
	// partition files into chunks
}

export default defineConfig({
	build: {
		rollupOptions: {
			output: {
				manualChunks: manualChunks,
			}
		}
	}
}

manualChunks() functions takes a path of the file (don’t know why everyone calls it an id). If you return a string for a given path, you tell rollup to bundle that file in a given chunk. If you return nothing (i.e. undefined) rollup will decide on how to chunk automatically, most likely putting everything into a single chunk

It gets called for .css files, .js files and probably others.

Here’s my hard won wisdom:

console.log(id) when working on manualChunks() to see what files are processed
chunk specific modules from node_modules to be lazy loaded
everything else from node_modules goes into vendor chunk
the rest is my own code and goes into lmain chunk as decided by rollup

Seems simple enough:

function manualChunks(id) {
  console.log(id);

  const chunksDef = [
    ["/@zip.js/zip.js/", "zipjs"],
    ["/prettier/", "prettier"],
    // markdown-it and highlight.js are used together in askai.svelte
    [
      "/markdown-it/",
      "/markdown-it-anchor/",
      "/highlight.js/",

	  "/entities/",
      "/linkify-it/",
      "/mdurl/",
      "/punycode.js/",
      "/uc.micro/",

      "markdownit-hljs",
    ],
  ];
  for (let def of chunksDef) {
    let n = def.length;
    for (let i = 0; i < n - 1; i++) {
      if (id.includes(def[i])) {
        return def[n - 1];
      }
    }
  }

  // bundle all other 3rd-party modules into a single vendor.js module
  if (id.includes("/node_modules/")) {
    return "vendor";
  }
  // when we return undefined, rollup will decide
}

This is real example from Edna. I’ve put zip.js, prettier and markdown-it + markdown-it-anchor + highlight.js into their own chunks, which I lazily import.

Things to note:

order is important. If I match /node_modules/ first, then everything would end up in vendor bundle
id is a full path of bundled file in Unix format e.g. C:/Users/kjk/src/elaris/node_modules/prettier/standalone.mjs. People seem to match the path against just package name like prettier. I match against /prettier/ so that if some file has string prettier in it, it won’t be accidentally put in prettier chunk
/entities/, /mdurl/ etc. are used by markdown-it so they should be included in its chunk. That’s where console.log(id) is helpful. I saw modules that I didn’t explicitly put in package.json which means they are implicit dependencies. I used bun.lock to see which package depends on those mysterious packages and that’s how I found what is used by markdown-it

There were 2 remaining problems.

I also had this in my code:

import "highlight.js/styles/github.css";

manualChunks was called for "highlight.js/styles/github.css" to which I returned markdownit-hljs so it was put in its own chunk. Which was too much because I didn’t want to lazy import a small CSS file, so I told rollup to put all .css files in main CSS chunk:

function manualChunks(id) {
  // pack all .css files in the same chunk
  if (id.endsWith(".css")) {
    return;
  }

  // ... rest of the code
}

There was one more thing that was a big pain in the ass to debug.

To verify things are properly chunked I opened Dev Tools in Chrome and looked at network tab. To my surprise, markdownit-hljs was loaded immediately.

After lots of debugging and research: turns out that vite bundles some helper functions. Because I didn’t specify explicitly which chunk they should go into, rollup decided to put them in markdownit-hljs chunk. Because main chunk was using that function, it had to import it, defeating my cunning plan to load it lazily later.

The fix was to direct those known helper function into vendor bundle:

function manualChunks(id) {
	// ... other code
	// bundle all other 3rd-party modules into a single vendor.js module
	if (
		id.includes("/node_modules/") ||
		ROLLUP_COMMON_MODULES.some((commonModule) => id.includes(commonModule))
	) {
		return "vendor";
	}
	// ... rest of the code
}

You can read more at:

Things might still go wrong. I got one invalid build that created a chunk that wouldn’t parse in the browser.

For that reason I suggest to start simple: empty manualChunks() function that packs everything in one chunk. Then add desired chunks one by one and after each change.

And how to lazy import things?

let markdownIt = (await import("markdown-it")).default;

is equivalent to static import:

import markdownIt from "markdown-it";

Increase software sales by 50% or more

2025-07-18T00:00:00Z

This is re-post of How to Permanently Increase Your Sales by 50% or More in Only One Day article by Steve Pavlina

Of all the things you can do to increase your sales, one of the highest leverage activities is attempting to increase your products’ registration rate. Increasing your registration rate from 1.0% to 1.5% means that you simply convince one more downloader out of every 200 to make the decision to buy. Yet that same tiny increase will literally increase your sales by a full 50%. If you’re one of those developers who simply slapped the ubiquitous 30-day trial incentive on your shareware products without going any further than that, then I think a 50% increase in your registration rate is a very attainable goal you can achieve if you spend just one full day of concentrated effort on improving your product’s ability to sell. My hope is that this article will get you off to a good start and get you thinking more creatively. And even if you fail, your result might be that you achieve only a 25% or a 10% increase. How much additional money would that represent to you over the next five years of sales?

What influence, if any, did the title of this article have on your decision to read it? If I had titled this article, “Registration Incentives,” would you have been more or less likely to read it now? Note that the title expresses a specific and clear benefit to you. It tells you exactly what you can expect to gain by reading it. Effective registration incentives work the same way. They offer clear, specific benefits to the user if a purchase is made.

In order to improve your registration incentives, the first thing you need to do is to adopt some new beliefs that will change your perspective. I’m going to introduce you to what I call the “lies of success” in the shareware industry. These are statements that are not true at all, but if you accept them as true anyway, you’ll achieve far better results than if you don’t.

Rule 1: What you are selling is merely the difference between the shareware and the registered versions, not the registered version itself.

Note that this is not a true statement, but if you accept it as true, you’ll immediately begin to see the weaknesses in your registration incentives. If there are few additional benefits for buying the full version vs. using the shareware version, then you aren’t offering the user strong enough incentives to make the full purchase.

Rule 2: The sole purpose of the shareware version is to close the sale.

This is our second lie of success. Note the emphasis on the word “close.” Your shareware version needs to act as a direct sales vehicle. It must be able to take the user all the way to the point of purchase, i.e. your online order form, ideally with nothing more than a few mouse clicks. Anything that detracts from achieving a quick sale is likely to hurt sales.

Rule 3: The customer’s perspective is the only one that matters.

Defy this rule at your peril. Customers don’t care that you spent 2000 hours creating your product. Customers don’t care that you deserve the money for your hard work. Customers don’t care that you need to do certain things to prevent piracy. All that matters to them are their own personal wants and needs. Yes, these are lies of success. Some customers will care, but if you design your registration incentives assuming they only care about their own self-interests, your motivation to buy will be much stronger than if you merely appeal to their sense of honesty, loyalty, or honor. Assume your customers are all asking, “What’s in it for me if I choose to buy? What will I get? How will this help me?” I don’t care if you’re selling to Fortune 500 companies. At some point there will be an individual responsible for causing the purchase to happen, and that individual is going to consider how the purchase will affect him/her personally: “Will this purchase get me fired? Will it make me look good in front of my peers? Will this make my job easier or harder?”

Many shareware developers get caught in the trap of discriminating between honest and dishonest users, believing that honest users will register and dishonest ones won’t. This line of thinking will ultimately get you nowhere, and it violates the third lie of success. When you make a purchase decision, how often do you use honesty as the deciding factor? Do you ever say, “I will buy this because I’m honest?” Or do you consider other more selfish factors first, such as how it will make you feel to purchase the software? The truth is that every user believes s/he is honest, so no user applies the honesty criterion when making a purchase decision. Thinking of your users in terms of honest ones vs. dishonest ones is a complete waste of time because that’s not how users primarily view themselves.

Rule 4: Customers buy on emotion and justify with fact.

If you’re honest with yourself, you’ll see that this is how you make most purchase decisions. Remember the last time you bought a computer. Is it fair to say that you first became emotionally attached to the idea of owning a new machine? For me, it’s the feeling of working faster, owning the latest technology, and being more productive that motivates me to go computer shopping. Once I’ve become emotionally committed, the justifications follow: “It’s been two years since I’ve upgraded, it will pay for itself with the productivity boost I gain, I can easily afford it, I’ve worked hard and I deserve a new machine, etc.” You use facts to justify the purchase. Once you understand how purchase decisions are made, you can see that your shareware products need to first get the user emotionally invested in the purchase, and then you give them all the facts they need to justify it.

Now that we’ve gotten these four lies of success out of the way, let’s see how we might apply them to create some compelling registration incentives. Let’s start with Rule 1. What incentives can be spawned from this rule? The common 30-day trial is one obvious derivative. If you are only selling the difference between the shareware and registered versions, then a 30-day trial implies that you are selling unlimited future days of usage of the program after the trial period expires. This is a powerful incentive, and it’s been proven effective for products that users will continue to use month after month. 30-day trials are easy for users to understand, and they’re also easy to implement. You could also experiment with other time periods such as 10 days, 14 days, or 90 days. The only way of truly knowing which will work best for your products is to experiment.

But let’s see if we can move a bit beyond the basic 30-day trial here by mixing in a little of Rule 3. How would the customer perceive a 30-day trial? In most cases 30 days is plenty of time to evaluate a product. But in what situations would a 30-day trial have a negative effect? A good example is when the user downloads, installs, and briefly checks out a product s/he may not have time to evaluate right away. By the time the user gets around to fully evaluating it, the shareware version has already expired, and a sale may be lost as a result. To get around this limitation, many shareware developers have started offering 30 days of actual program usage instead of 30 consecutive days. This allows the user plenty of time to try out the program at his/her convenience. Another possibility would be to limit the number of times the program can be run. The basic idea is that you are giving away limited usage and selling unlimited usage of the program. This incentive definitely works if your product is one that will be used frequently over a long period of time (much longer than the trial period).

The flip side of usage limitation is to offer an additional bonus for buying within a certain period of time. For instance, in my game Dweep, I offer an extra 5 free bonus levels to everyone who buys within the first 10 days. In truth I give the bonus levels to everyone who buys, but the incentive is real from the customer’s point of view. Remember Rule 3 - it doesn’t matter what happens on my end; it only matters what the customer perceives. Any customer that buys after the first 10 days will be delighted anyway to receive a bonus they thought they missed.

So if your product has no time-based incentives at all, this is the first place to start. When would you pay your bills if they were never due, and no interest was charged on late payments? Use time pressure to your advantage, either by disabling features in the shareware version after a certain time or by offering additional bonuses for buying sooner rather than later. If nothing else and if it’s legal in your area, offer a free entry in a random monthly drawing for a small prize, such as one of your other products, for anyone who buys within the first X days.

Another logical derivative of Rule 1 is the concept of feature limitation. On the crippling side, you can start with the registered version and begin disabling functionality to create the shareware version. Disabling printing in a shareware text editor is a common strategy. So is corrupting your program’s output with a simple watermark. For instance, your shareware editor could print every page with your logo in the background. Years ago the Association of Shareware Professionals had a strict policy against crippling, but that policy was abandoned, and crippling has been recognized as an effective registration incentive.

It is certainly possible to apply feature limitation without having it perceived as crippling. This is especially easy for games, which commonly offer a limited number of playable levels in the shareware version with many more levels available only in the registered version. In this situation you offer the user a seemingly complete experience of your product in the shareware version, and you provide additional features on top of that for the registered version.

Time-based incentives and feature-based incentives are perhaps the two most common strategies used by shareware developers for enticing users to buy. Which will work best for you? You will probably see the best results if you use both at the same time. Imagine you’re the end user for a moment. Would you be more likely to buy if you were promised additional features and given a deadline to make the decision? I’ve seen several developers who were using only one of these two strategies increase their registration rates dramatically by applying the second strategy on top of the first. If you only use time-based limitations, how could you apply feature limitation as well? Giving the user more reasons to buy will translate to more sales per download.

One you have both time-based and feature-based incentives to buy, the next step is to address the user’s perceived risk by applying a risk-reversal strategy. Fortunately, the shareware model already reduces the perceived risk of purchasing significantly, since the user is able to try before buying. But let’s go a little further, keeping Rule 3 in mind. What else might be a perceived risk to the user? What if the user reaches the end of the trial period and still isn’t certain the product will do what s/he needs? What if the additional features in the registered version don’t work as the user expects? What can we do to make the decision to purchase safer for the user?

One approach is to offer a money-back guarantee. I’ve been offering a 60-day unconditional money-back guarantee on all my products since January 2000. If someone asks for their money back for any reason, I give them a full refund right away. So what is my return rate? Well, it’s about 8%. Just kidding! Would it surprise you to learn that my return rate at the time of this writing is less than 0.2%? Could you handle two returns out of every 1000 sales? My best estimate is that this one technique increased my sales by 5-10%, and it only took a few minutes to implement. When I suggest this strategy to other shareware developers, the usual reaction is fear. “But everyone would rip me off,” is a common response. I suggest trying it for yourself on an experimental basis; a few brave souls have already tried it and are now offering money-back guarantees prominently. Try putting it up on your web site for a while just to convince yourself it works. You can take it down at any time. After a few months, if you’re happy with the results, add the guarantee to your shareware products as well. I haven’t heard of one bad outcome yet from those who’ve tried it.

If you use feature limitation in your shareware products, another important component of risk reversal is to show the user exactly what s/he will get in the full version. In Dweep I give away the first five levels in the demo version, and purchasing the full version gets you 147 more levels. When I thought about this from the customer’s perspective (Rule 3), I realized that a perceived risk is that s/he doesn’t know if the registered version levels will be as fun as the demo levels. So I released a new demo where you can see every level but only play the first five. This lets the customer see all the fun that awaits them. So if you have a feature-limited product, show the customer how the feature will work. For instance, if your shareware version has printing disabled, the customer could be worried that the full version’s print capability won’t work with his/her printer or that the output quality will be poor. A better strategy is to allow printing, but to watermark the output. This way the customer can still test and verify the feature, and it doesn’t take much imagination to realize what the output will look like without the watermark.

Our next step is to consider Rule 2 and include the ability close the sale. It is imperative that you include an “instant gratification” button in your shareware products, so the customer can click to launch their default web browser and go directly to your online order form.

If you already have a “buy now” button in your products, go a step further. A small group of us have been finding that the more liberally these buttons are used, the better. If you only have one or two of these buttons in your shareware program, you should increase the count by at least an order of magnitude. The current Dweep demo now has over 100 of these buttons scattered throughout the menus and dialogs. This makes it extremely easy for the customer to buy, since s/he never has to hunt around for the ordering link.

What should you label these buttons? “Buy now” or “Register now” are popular, so feel free to use one of those. I took a slightly different approach by trying to think like a customer (Rule 3 again). As a customer the word “buy” has a slightly negative association for me. It makes me think of parting with my cash, and it brings up feelings of sacrifice and pressure. The words “buy now” imply that I have to give away something. So instead, I use the words, “Get now.” As a customer I feel much better about getting something than buying something, since “getting” brings up only positive associations. This is the psychology I use, but at present, I don’t know of any hard data showing which is better. Unless you have a strong preference, trust your intuition.

Make it as easy as possible for the willing customer to buy. The more methods of payment you accept, the better your sales will be. Allow the customer to click a button to print an order form directly from your program and mail it with a check or money order. On your web order form, include a link to a printable text order form for those who are afraid to use their credit cards online. If you only accept two or three major credit cards, sign up with a registration service to handle orders for those you don’t accept.

So far we’ve given the customer some good incentives to buy, minimized perceived risk, and made it easy to make the purchase. But we haven’t yet gotten the customer emotionally invested in making the purchase decision. That’s where Rule 4 comes in. First, we must recognize the difference between benefits and features. We need to sell the sizzle, not the steak. Features describe your product, while benefits describe what the user will get by using your product. For instance, a personal information manager (PIM) program may have features such as daily, weekly, and monthly views; task and event timers; and a contact database. However, the benefits of the program might be that it helps the user be more organized, earn more money, and enjoy more free time. For a game, the main benefit might be fun. For a nature screensaver, it could be relaxation, beauty appreciation, or peace. Features are logical; benefits are emotional. Logical features are an important part of the sale, but only after we’ve engaged the customer’s emotions.

Many products do a fair job of getting the customer emotionally invested during the trial period. If you have an addictive program or one that’s fun to use, such as a game, you may have an easy time getting the customer emotionally attached to using it because the experience is already emotional in nature. But whatever your product is, you can increase your sales by clearly illustrating the benefits of making the purchase. A good place to do this is in your nag screens. I use nag screens both before and after the program runs to remind the user of the benefits of buying the full version. At the very least, include a nag screen when the customer exits the program, so the last thing s/he sees will be a reminder of the product’s benefits. Take this opportunity to sell the user on the product. Don’t expect features like “customizable colors” to motivate anyone to buy. Paint a picture of what benefits the user will obtain with the full version. Will I save time? Will I have more fun? Will I live longer, save money, or feel better? The simple change from feature-oriented selling to benefit-oriented selling can easily double or triple your sales. Be sure to use this approach on your web site as well if you don’t already. Developers who’ve recently made the switch have been reporting some amazing results.

If you’re drawing a blank when trying to come up with benefits for your products, the best thing you can do is to email some of your old customers and ask them why they bought your program. What did it do for them? I’ve done this and was amazed at the answers I got back. People were buying my games for reasons I’d never anticipated, and that told me which benefits I needed to emphasize in my sales pitch.

The next key is to make your offer irresistible to potential customers. Find ways to offer the customer so much value that it would be harder to say no than to say yes. Take a look at your shareware product as if you were a potential customer who’d never seen it before. Being totally honest with yourself, would you buy this program if someone else had written it? If not, don’t stop here. As a potential customer, what additional benefits or features would put you over the top and convince you to buy? More is always better than less. In the original version of Dweep, I offered ten levels in the demo and thirty in the registered version. Now I offer only five demo levels and 152 in the full version, plus a built-in level editor. Originally, I offered the player twice the value of the demo; now I’m offering over thirty times the value. I also offer free hints and solutions to every level; the benefit here is that it minimizes player frustration. As I keep adding bonuses for purchasing, the offer becomes harder and harder to resist.

What clever bonuses can you throw in for registering? Take the time to watch an infomercial. Notice that there is always at least one “FREE” bonus thrown in. Consider offering a few extra filters for an image editor, ten extra images for a screensaver, or extra levels for a game. What else might appeal to your customers? Be creative. Your bonus doesn’t even have to be software-based. Offer a free report about building site traffic with your HTML editor, include an essay on effective time management with your scheduling program, or throw in a small business success guide with your billing program. If you make such programs, you shouldn’t have too much trouble coming up with a few pages of text that would benefit your customers. Keep working at it until your offer even looks irresistible to you. If all the bonuses you offer can be delivered electronically, how many can you afford to include? If each one only gains one more customer in a thousand (0.1%), would it be worth the effort over the lifetime of your sales?

So how do you know if your registration incentives are strong enough? And how do you know if your product is over-crippled? Where do you draw the line? These are tough issues, but there is a good way to handle them if your product is likely to be used over a long period of time, particularly if it’s used on a daily basis. Simply make your program gradually increase its registration incentives over time. One easy way to do this is with a delay timer on your nag screens that increases each time the program is run. Another approach is to disable certain features at set intervals. You begin by disabling non-critical features and gradually move up to disabling key functionality. The program becomes harder and harder to continue using for free, so the benefits of registering become more and more compelling. Instead of having your program completely disable itself after your trial period, you gradually degrade its usability with additional usage.

This approach can be superior to a strict 30-day trial, since it allows your program to still be used for a while, but after prolonged usage it becomes effectively unusable. However, you don’t simply shock the user by taking away all the benefits s/he has become accustomed to on a particular day. Instead, you begin with a gentle reminder that becomes harder and harder to ignore. There may be times when your 30-day trial shuts off at an inconvenient time for the user, and you may lose a sale as a result. For instance, the user may not have the money at the time, or s/he may be busy at the trial’s end and forget to register. In that case s/he may quickly replace what was lost with a competitor’s trial version. The gradual degradation approach allows the user to continue using your product, but with increasing difficulty over time. Eventually, there is a breaking point where the user either decides to buy or to stop using the program completely, but this can be done within a window of time at the user’s convenience.

Hopefully this article has gotten you thinking creatively about all the overlooked ways you can entice people to buy your shareware products. The most important thing you can do is to begin seeing your products through your customers’ eyes. What additional motivation would convince you to buy? What would represent an irresistible offer to you? There is no limit to how many incentives you can add. Don’t stop at just one or two; instead, give the customer a half dozen or more reasons to buy, and you’ll see your registration rate soar. Is it worth spending a day to do this? I think so.

File sync is very slow

2025-07-17T00:00:00Z

I’m working on a Go library appendstore for append-only store of lots of things in a single file.

To make things as robust as possible I was calling os.File.Sync() after each append. Sync() is waiting until the data is acknowledged as truly, really written to disk (as opposed to maybe floating somewhere in disk drive’s write buffer).

Oh boy, is it slow. A test of appending 1000 records would take over 5 seconds.

After removing the Sync() it would drop to 5 milliseconds. 1000x faster.

I made sync optional - it’s now up to the user of the library to pick it, defaults to non-sync.

Is it unsafe now? Well, the reality is that it probably doesn’t matter. I don’t think lots of software does the sync due to slowness and the world still runs.

Desktop UI frameworks written by a single person

2025-07-09T00:00:00Z

Less known desktop UI frameworks

Writing desktop software is hard. The UI technologies of Windows or MacOS are awful compared to web technology.

What can trivially be done with HTML/CSS/JavaScript in few minutes can take hours using Windows’s win32 APIs or Mac’s Cocoa.

That’s why the default technology for desktop apps, especially cross-platform, is Electron: a Chrome browser combined with Node runtime.

The problem is that it’s bloaty: each app is a unique build of Chrome with a little bit of application code. Chrome is over 100MB so many apps ship less than 1MB of code in a 100M wrapper.

People tried to address the problem of poor OS APIs by writing UI frameworks, often meant to be cross-platform.

You’ve heard about QT, GTK, wxWindows.

The problem with those is that they are also old, their APIs are not the greatest either and they are bloaty as well.

There just doesn’t seem to be a good option.

Writing your own framework seems impossible due to the size of task.

But is it?

I’ll show a couple of less-known UI frameworks written mostly be a single person, often done simply to enable writing an application.

SWELL in WDL

WDL is interesting. Justin Frankel, the guy who created Winamp, has a repository of C++ code he uses in different projects.

After selling Winamp to AOL, a side quest of writing file sharing application, getting fired from AOL for writing file sharing application, he started a company building Reaper a digital audio workstation software for Windows.

Winamp is a win32 API program and so is Reaper. At some point Justin decided to make a Mac version but by then he had a lot of code heavily using win32 APIs.

So he did what anyone in his position would: he implemented win32 APIs for Mac OS and Linux and called it SWELL - Simple Windows Emulation Layer.

Ok, actually no-one else would do it. It was an insane idea but it worked.

It’s important to not over-state SWELL capabilities. It’s not Wine. You can’t take any win32 program and recompile for Mac with SWELL.

Frankel is insanely pragmatic and so is his code. SWELL only implements the subset of APIs he uses in Reaper.

At the same time Reaper is a big app so if SWELL works for Reaper, it could work for your app.

WDL is open-source using permissive MIT license.

Sublime Text

For a few years Sublime Text was THE programmer’s editor.

It was written by a single developer in C++ and he wrote a custom UI toolkit for it. Not open source but its existence shows it can be done.

10x Editor

Less known that Sublime Text, 10x Editor is a Windows only editor specialized for large C/C++ code bases.

Also written by a single person and with custom UI system.

RAD Debugger

RAD Debugger is an open-source Windows debugger for C/C++ apps written in C by mostly a single person.

It implements a custom UI framework based on 3D renderer.

The UI is integral part of the the app but the code is well structured so you probably can take just their UI / render code and use it in your own C / C++ app.

Currently the app / UI is only for Windows but it’s designed to be cross-platform and they are working on porting the renderer to Mac OS / Linux.

They use permissive MIT license and everything is written in C.

Dear ImGUI

Dear ImGui is a newer cross-platform, UI framework in C++. Open source, permissive MIT license.

Written by mostly a single person.

Ghostty

Ghostty is a cross-platform terminal emulator and UI. It’s written in Zig by mostly a single person and uses it’s own low-level GPU renderer for the UI.

File Pilot

File Pilot is a file manager for Windows with custom UI framework written on top of OpenGL. Based on this talk

You too can write your own UI framework

At first the idea of writing your own UI framework seems impossibly daunting.

What I’m hoping to show is that if you’re ambitious enough it’s possible to build cross platform desktop apps that are not just bloated 100MB Chrome wrappers around few kilobytes of custom code.

I’m not saying it’s a simple thing, just that enough people did it that it’s possible.

It shouldn’t be necessary but both Microsoft and Apple have tragically dropped the ball on providing decent, high-performance UI libraries for their OS.

Microsoft even writes their own apps, like Teams, in web technologies.

Thanks to open source you’re not at the starting line.

You can just use Dear ImGUI or WDL’s SWELL.

Or you can extract the UI code from RAD Debugger or Ghostty (if you write in Zig).

Or you can look at how their implementation to speed up your own design and implementation.

Evolving Edna Ask AI UI

2025-07-09T00:00:00Z

This is a real life example of tweaking UI in Edna, my note taking application with super powers.

Ask AI is a simple AI chat: you write a question, send it to LLM model and get a response.

Here’s my first version of the UI:

What is good and bad about this version?

Good: there’s a learn more link. This is not an obvious feature because you need to pick a model and provide an API key. An easy access to an explanation is good.

Bad: It’s not clear enough that you need to provide an API key. To make things even more confusing, for models from OpenAI or xAI you can use either OpenAI/xAI key or OpenRouter key. Hence the Use OpenRouter checkbox. I decided to make things more explicit:

I think it’s clearer.

Checkbox is gone. Now I just ask for one or the other and will use whichever is given.

A learn more links to section of the docs explaining how to get API key and answering basic questions about API keys. In fact, there are duplicate links to make sure the user doesn’t miss them.

Added an error message if no API key is yet provided.

Added explicit placeholder Enter OpenAI API key text in input field.

All to make sure that if someone doesn’t know about API keys, the information is easy to reach.

Implementing UI translation in SumatraPDF, a C++ Windows application

2025-07-08T00:00:00Z

Translating user interface of SumatraPDF

SumatraPDF is the best PDF/eBook/Comic Book viewer for Windows. It’s small, fast, full of features, free and open-source.

It became popular enough that it made sense to translate the UI for non-English users. Currently we support 72 languages.

This article describes how I designed and implemented a translation system in SumatraPDF, a native win32 C++ Windows application.

Hard things about translating the UI

There are 2 hard things about translating an application

code for translation system (extracting strings to translate, translate strings from English to user’s language)
translating them into many languages

Extracting strings to translate from source code

Currently there are 381 strings in SumatraPDF subject to translation. It’s important that the system requires the least amount of effort when adding new strings to translate.

Every string that needs to be translated is marked in .cpp or .h file with one of two macros:

_TRA("Rename")
_TRN("Open")

I have a script that extracts those strings from source files. Mine is written in Go but it could just as well be Python or JavaScript. It’s a simple regex job.

_TR stands for “translation”.

_TRA(s) expands into const char* trans::GetTranslation(const char* str) function which returns str translated to current UI language.

We auto-detect language at startup based on Windows settings and allow the user to explicitly set UI language.

For English we just return the original string.

If a string to be translated is e.g. a part of const char* array[], we can’t use trans::GetTranslation().

For cases like that we have _TRN() which expands to English string. We have to write code to translate it at some point.

Adding new strings is therefore as simple as wrapping them in _TRA() or _TRN() macros.

Translating strings into many languages

Now that we’ve extracted strings to be translated, we need to translate them into 72 languages.

SumatraPDF is a free, open-source program. I don’t have a budget to hire translators. I don’t have a budget, period.

The only option was to get help from SumatraPDF users.

It was vital to make it very easy for users to send me translations. I didn’t want to ask them, for example, to download some translation software.

Design and implementation of AppTranslator web app

I couldn’t find a really simple software for crowd sourcing translations so I wrote my own: https://github.com/kjk/apptranslator

You can see it in action: https://www.apptranslator.org/app/SumatraPDF

I designed it to be generic but I don’t think anyone else is using it.

AppTranslator is simple. Per https://tools.arslexis.io/wc/:

4k lines of Go server code
451 lines of html code
a single dependency: bootstrap CSS framework (the project is old)

It’s simple because I don’t want to spend a lot of time writing translation software. It’s just a side project in service of the goal of translating SumatraPDF.

It doesn’t even use a database. Like in Redis, changes are stored as a series of operations in an append-only log. We keep the whole state in memory and re-create it from the log at startup.

Main operation is translate a string from English to language X represented as [kOpTranslation, english string, language, translation, user who provided translation].

When user provides a translation in the web UI, we send an API call to the server which appends the translation operation to the log.

Simple and reliable.

Because the code is written in Go, it’s very fast and memory efficient. When running it uses mere megabytes of RAM. It can comfortably run on the smallest 256 MB VPS server.

I backup the log to S3 so if the server ever fails, I can re-install the program on a new server and re-download the translations from S3.

I provide RSS feed for each language so that people who provide translations can monitor for new strings to be translated.

Sending strings for translation and receiving translations

So I have a web app for collecting translations and a script that extracts strings to be translated from source code.

How do they connect?

AppTranslator has an API for submitting the current set of strings to be translated in the simplest possible format: a line for each string (I ensure there are no newlines in the string itself by escaping them with \n)

API is password protected because only I can submit the strings.

The server compares the strings sent with the current set and records a difference in the log.

It also sends a response with translations. Again the simplest possible format:

AppTranslator: SumatraPDF
651b739d7fa110911f25563c933f42b1d37590f8
:%s annotation. Ctrl+click to edit.
am:%s մեկնաբանություն: Ctrl+քլիք՝ խմբագրելու համար:
ar:ملاحظة %s. اضغط Ctrl للتحرير.
az:Qeyd %s. Düzəliş etmək üçün Ctrl+düyməyə basın.

As you can see:

a string to translate is on a line starting with :
is followed by translations of that strings in the format: ${lang}: ${translation}

An optimization: 651b739d7fa110911f25563c933f42b1d37590f8 is a hash of this response. If I submit this hash with my request and translations didn’t change on the server, the response is empty.

Implementing C++ part of translation system

So now I have a text file with translation downloaded from the server. How do I get a translation in my C++ code?

As with everything in SumatraPDF, I try to do things in a simple and efficient way.

The whole Translation.cpp is only 239 lines of code.

The core of translation system is const char* trans::GetTranslation(const char* s); function.

I embed the translations in exact the same format as received from AppTranslator in the executable as data file in resources.

If the UI language is English, we do nothing. trans::GetTranslation() returns its argument.

When we switch the language, we load the translations from resources and build an index:

an array of English strings
an array of corresponding translations

Both arrays use my own StrVec class optimized for storing an array of strings.

To find a translation we scan the first array to find an index of the string and return translation from the second array, at the same index.

Linear scan seems like it would be slow but it isn’t.

Resizing dialogs

I have a few dialogs defined in SumatraPDF.rc file.

The problem with dialogs is that position of UI elements is fixed.

A translated string will almost certainly have a different size than the English string which will mess up fixed layout.

Thankfully someone wrote DialogSizer that smartly resizes dialogs and solves this problem.

The evolution of a solution

No AppTranslator

My initial implementation was simpler. I didn’t yet have AppTranslator so I stored the strings in a text file in repository in the same format as what I described above.

People would download it, make changes using a text editor and send me the file via email which I would then checkin.

It worked for a while but it became worse over time. More strings, more languages created more work for me to manually manage e-mail submissions.

I decided to automate the process.

Code generation

My first implementation of C++ side used code generation instead of embedding the text file in resources.

My Go script would generate C++ source code files with static const char* [] arrays.

This worked well but I decided to improve it further by making the code use the text file with translations embedded in the app.

The main motivation for the change was to open a possibility of downloading latest translations from the server to fix the problem of translations not being all ready when I build the release executable.

I haven’t done that yet but it’s now easier to implement given that the format of strings embedded in the exe is the same as the one I can download from AppTranslator.

Only utf-8

SumatraPDF started by using both WCHAR* Unicode strings and char* utf8 strings.

For that reason the translation system had to support returning translation in both WCHAR* and char* version.

Over time I refactored the code to use mostly utf8 and at some point I no longer needed to support WCHAR* version.

That made the code even smaller and reduced memory usage.

The experience

I’m happy how things turned out.

AppTranslator proved to be reliable and hassle free. It runs for many years now and collected 35440 string translations from users.

I automated everything so that all I need to do is to periodically re-run the script that extracts strings from source code, uploads them to AppTranslator and downloads latest translations.

One problem is that translations are not always ready in time for release so I make a release and then people start translating strings added since last release.

I’ve considered downloading the latest translations from the server, in addition to embedding them in an executable at the time of building the app.

Would I do the same today?

While AppTranslator is reliable and doesn’t require on-going work, it would be better to not have to run a server at all.

The world has changed since I started SumatraPDF.

Namely: people are comfortable using GitHub and you can edit files directly in GitHub UI. It’s not a great experience but it works.

One option would be to generate a translation text file for each language, in this format:

:first untranslated string
:second untranslated string
:first translated string
translation of first string
:second translated string
translation of second string

Untranslated strings are listed at the top, to make it easier to find.

A link would send a translator directly to edit this file in GitHub UI.

When translator saves translations, it creates a PR for me to review and merge.

The roads not taken

But why did you re-invent everything? You should do X instead.

All other X that I know about suck.

Using per-language .rc resource files

Traditional way of localizing / translating Window GUI apps is to store all strings and dialog definitions in an .rc file. Each language gets its own .rc file (or files) and the program picks the right resource based on a language.

This doesn’t solve the 2 hard problems:

having an easy way to add strings for translations
having an easy way for users to provide translations

XML horror show

There was a dark time when the world was under the iron grip of XML fanaticism.

Everything had to be an XML file even when it was the worst possible solution for the problem.

XML doesn’t solve the 2 hard problems and a string storage format is an absolute nightmare for human editing.

GNU gettext

There’s a C library gettext that uses .po files.

This is much saner solution than XML horror show. .po files are relatively simple text format. The code is already written.

Warning: tooting my own horn.

My format is better. It’s easier for people to edit, it’s easier to write code to parse it. This looks like many times more than 239 lines of code.

Ok, gettext probably does a bit more than my code, but clearly nothing than I need.

It also doesn’t solve the 2 hard problems. I would still have to write code to extract strings from source code and build a way to allow users to translate them easily.

Calling Grok, OpenAI, Anthropic, Google, OpenRouter API from the browser

2025-07-08T00:00:00Z

Here’s what I learned about calling LLM APIs from the browser when building AI chat functionality in my note taking app Edna.

The API I care about is getting LLM response to a question in a streaming way.

OpenAI pioneered this and created https://api.openai.com/v1/chat/completions POST API. Others created a compatible API for their LLM to make it easy for programmers to migrate. xAI has https://api.x.ai/v1/chat/completions for Grok and OpenRouter has https://openrouter.ai/api/v1/chat/completions.

Google and Anthropic have similar APIs but they use CORS to disallow calling them from the browser. Baffling restriction. For now I decided to not support them directly. I could route the requests via the server but I can use OpenRouter instead.

I’ve seen TypingMind call Google API from the browser but using a different API endpoint. Again, for now I decided to not support Google directly.

OpenRouter is an interesting service and business. They provide unified API for lots of different models so I can use Google or Anthropic APIs via OpenRouter and lots of other models. They charge 5% on top of what they pay the providers, which is reasonable if you consider that they probably pay ~3% for processing credit card fees.

For now I support OpenAI and Grok directly and everyone else via OpenRouter.

Increase open file limit on Ubuntu Linux

2025-07-07T00:00:00Z

What and why of open file limit

If you run a webapp on a Linux server, your webapp needs to open files and make network connections.

Most Linux servers have horrible default for this and limit the number of opened files at the same time to e.g. 1024.

To check the limit run: ulimit -n.

1024 makes sense if it’s a shared computer used by multiple users, to protect the system from abusive user. It doesn’t make sense if the server is used for running a web app which can run into this limit and silently fail because it can’t open a file or a network connection.

What is a reasonable limit? No one knows but I set mine high, to at least 65 thousand. The more RAM you have, the higher the limit can be. It also depends on your app: if it opens a lot of files and network connections, you need higher limit.

How to change open file limit on Ubuntu

1. Edit the system limits configuration:

sudo nano /etc/security/limits.conf

2. Add at the end of file:

*       soft    nofile  65535
*       hard    nofile  65535

3. Edit PAM configuration file:

sudo nano /etc/pam.d/common-session

4. Add at the end of file:

session required pam_limits.so

5. Edit the limits configuration file for systemd:

sudo nano /etc/systemd/system.conf

6. Add at the end of file:

DefaultLimitNOFILE=65535

7. Reboot:

sudo reboot

It’s way too complicated but that’s Linux for you.

Case study of over-engineered C++ code

2025-07-07T00:00:00Z

You’ve heard of over-engineered, unnecessarily complex code but what exactly is it?

I believe it’s best to show by example.

While it’s not my intention to criticize other people’s code, I think it’s better to show code and how to improve it rather than vaguely talk about principles.

The code that I consider over-engineered:

The problem it’s trying to solve

This code detects file format from file content. Are the bytes an audio wav file? A jpeg image?

In addition, it extracts some properties of the file format e.g. a dimension of the image file.

Over-engineered implementation

If you’re C++ programmer it’s natural to use object oriented design. You create XBinary base class with some virtual methods and then write a class for each format that inherits from XBinary.

Here’s just a small part:

class XBinary {
    virtual FT getFileType();
    virtual ENDIAN getEndian();
    // ... much more stuff
};

And implementation for detecting BMP images:

class XBMP : public XBinary {
    // ...
};

XBinary::FT XBMP::getFileType()
{
    return FT_BMP;
}

XBinary::MODE XBMP::getMode()
{
    return XBinary::MODE_DATA;
}

Over-engineering in the small: unnecessary virtual functions

This code is over-engineered in the small.

Notice that file type or mode are static per file format. They most likely do not depend on the data.

We can easily eliminate virtual calls by storing this info as class members.

class XBinary {
private:
    FT _fileType;
    MODE _mode;
public:
    FT getFileType() { return _fileType; }
    MODE getMode() { return _mode; }
};

class XBMP : public XBinary {
    XBMP() {
        fileType = FT_BMP;
        mode = XBinary::MODE_DATA;
    }
};

We replaced multiple virtual methods with a single non-virtual method in base class.

That is a saving in both code size and code speed.

Parsing and compiling more stuff requires compiler to do more work which takes more time.

Removing getter methods

We don’t need the method that just returns the value of a variable.

A function is necessary if it does some computation on data. It doesn’t happen here so it’s just bad habit of mindlessly adding unnecessary code.

We can simplify by making class members public:

class XBinary {
public:
    FT fileType;
    MODE mode;
};

Over-engineering in the big: design

XBinary defines 9 virtual classes, each to get small bits of information about the format:

class XBMP {
    virtual FT getFileType();
    virtual QString getMIMEString();
    virtual QString getArch();
    virtual MODE getMode();
    virtual ENDIAN getEndian();

    virtual QString getFileFormatExt();
    virtual QString getFileFormatExtsString();
    virtual _MEMORY_MAP getMemoryMap(MAPMODE mapMode = MAPMODE_UNKNOWN, PDSTRUCT *pPdStruct = nullptr);
    virtual QString getVersion();
}

An observation: they are all cheap to compute. Typically reading a few bytes of memory.

Instead of providing a function for each piece of information, we could have one function that returns everything.

struct FormatInfo {
    FT fileType;
    QString mimeString;
    // ... the other 7 values
};

class XBMP {
    virtual FormatInfo getFormatInfo();
};

We save lots of code by consolidating 9 different functions into one. We also simplified the API and I believe someone new to the library would figure out how to use smaller interface faster.

Each format also provides a per-format data. XBMP has:

class XBMP {
    BMPFILEHEADER getFileHeader();
    BMPINFOHEADER getInfoHeader();
};

Again, we could combine this into one function:

struct XbmpInfo {
    BMPFILEHEADER fileHeader;
    BMPINFOHEADER infoHeader;
};

class XBMP {
    XbmpInfo getXbmpInfo();
    virtual FormatInfo getFormatInfo();
};

But wait, we can combine this info a single function:

struct XbmpInfo {
    FormatInfo formatInfo;
    BMPFILEHEADER fileHeader;
    BMPINFOHEADER infoHeader;
}

class XBMP {
    XbmpInfo getXbmpInfo();
};

In fairness, we’ve lost ability to use the API in a certain way. Before if code was only interested in common properties in FormatInfo it could use the same code for every class representing a format. Now it has to know it’s calling e.g. XBMP and get FormatInfo out of XbmpInfo.

We don’t need classes at all

The best part is no part.

If we had to write this code in C, how would we do it?

We could implement each format detector as a single function.

struct XbmpInfo {
    bool isValid;
    FormatInfo formatInfo;
    BMPFILEHEADER fileHeader;
    BMPINFOHEADER infoHeader;
};

struct PngInfo { ... };

XbmpInfo maybeDetectXbmp(char* data, size_t dataSize);
PngInfo maybeDetectPng(char* data, size_t dataSize);

One function to rule them all

We have a function for each file type, but we can simplify it to a single function that detects the type and returns information for a given file type:

struct XbmpInfo { ... };
struct PngInfo { ... };

enum {
    InvalidTye, // if not a known format
	XbmpType,
	PngType,
	// ....
};

struct FormatInfo {
	enum typ;
	FormatInfo formatInfo;
	union {
		XbmpInfo* xbmp;
		PngInfo* png;
	} extraInfo;
};

FormatInfo detectFileFormat(char* data, size_t dataSize);

The API is now dramatically simpler.

We removed all the classes, all their methods. It’s a massive saving in lines of code.

You save binary size, you make the code faster but most importantly you save yourself time because this is code you don’t have to write.

You can focus on writing the logic for parsing file formats not on incidental complexity of typing up class names and methods.

Why do people over-complicate?

Because simplicity is hard.

Because when you have a hammer, everything looks like a nail.

After you’ve read a book on C++, teaching you about inheritance, virtual functions etc. it’s only natural to start modeling all problems with class inheritance and virtual functions.

To then come up with a solution that reduces all that to a function requires thinking outside the C++ box.

Thinking outside the box is hard.

Explaining nil interface{} gotcha in Go

2025-07-06T00:00:00Z

Explaining nil interface{} gotcha in Go

A footgun

In Go empty interface is an interface without any methods, typed as interface{}.

A zero value of interface{} is nil:

var v interface{} // compiler sets this to nil, you could explicitly write = nil
if v == nil {
  fmt.Printf("v is nil\n")
} else {
  fmt.Printf("v is NOT nil\n")
}

Try online

This prints: v is nil.

However, this sometimes trips people up:

type Foo struct {
}

var v interface{}
var nilFoo *Foo // implicilty initialized by compiler to nil
if nilFoo == nil {
    fmt.Printf("nilFoo is nil.")
} else {
    fmt.Printf("nilFoo is NOT nil.")
}
v = nilFoo
if v == nil {
    fmt.Printf("v is nil\n")
} else {
    fmt.Printf("v is NOT nil\n")
}

Try online

This prints: nilFoo is nil. v is NOT nil.

On surface level, this is wrong: t is a nil. We assigned a nil to v but it doesn’t equal to nil?

How to check if interface{} is nil of any pointer type?

func isNilPointer(i interface{}) bool {
    if i == nil {
        return false // interface itself is nil
    }
    
    v := reflect.ValueOf(i)
    return v.Kind() == reflect.Ptr && 
           v.IsNil()
}

	type Foo struct {
	}

	var pf *Foo
	var v interface{} = pf

	if isNilPointer(v) {
		fmt.Printf("v is nil pointer\n")
	} else {
		fmt.Printf("v is NOT nil pointer\n")
	}

Try online

Why

There’s a reason for this perplexing behavior.

nil is an abstract value. If you come from C/C++ or Java/C#, you might think that this is equivalent of NULL pointer or null reference.

It isn’t. nil is a symbol that represents a zero value of pointers, channels, maps, slices.

Logically interface{} combines type and value. You can think of it as a tuple (type, value).

An uninitialized value of interface{} is a tuple without a type and value (no type, no value).

In Go uninitialized value is zero value and since nil is an abstract value representing zero value for several types, it makes sense to use it for zero value of interface{}.

So: zero value of interface{} is nil which is (no type, no value).

When we assigned nilFoo to v, the value is (*Foo, nil).

Are you surprised that (no type, no value) is not the same as (*Foo, nil)?

To understand this gotcha, you have to understand two things.

One: nil is an abstract value that only has a meaning in context.

Consider this:

var ch chan (bool)
var m map[string]bool
if ch == m {
    fmt.Printf("ch is equal to m\n")
}

Try online

This snippet doesn’t even compile: Error:./prog.go:8:11: invalid operation: ch == m (mismatched types chan bool and map[string]bool).

Both ch and m are nil but you can’t compare them because they are of different types. nil != nil because nil is an abstract concept, not an actual value.

Two: nil value of interface{} is (no type, no value).

Once you understand the above, you’ll understand why nil doesn’t compare to (type, nil) e.g. (*Foo, nil) or (map[string]bool, nil) or (int, 0) or (string, "").

Bad design or inevitable consequence of previous decisions?

Many claim it’s a bad design.

No-one describes what a better design would look like.

Let’s play act a Go language designer.

You’ve already designed concrete types, you came up with notion of zero value and created nil to denote zero value for pointers, channels, maps, slices.

You’re now designing interface{} as a logical tuple of (type, value).

The zero value is obviously (no type, no value).

You have to figure how to represent the zero value.

A different symbol for interface{} zero value

Instead of using nil you could create a different symbol e.g. zeroInteface.

You could then write:

var v interface{}
var v2 interface{} = &Foo{nil}
var v3 interface{} = int(0)

if v == zeroInteface {
  // this is true
}

if v2 == nil {
  // tihs is true
}

if v3 == nil {
  // is it true or not?
}

Is this a better design?

I don’t think so.

We don’t have zeroPointer, zeroMap, zeroChanel etc. so this breaks consistency. It sticks out like a sore zeroInterface.

And v == nil is subtle. Not all values wrapped in an interface{} have zero value of nil. What should happen if you compare to (int, 0) given that 0 is zero value of int?

Damn the consistency, let’s do what user expects

You could ditch the strict logic of nil values and special case the if v == nil for interface{} to do what people superficially expect to happen.

You then have to answer the question below: what happens when you do if (int, 0) == nil?

The biggest issue is that you’ve lost ability to distinguish between (no type, no value) and (type, nil).

They both compare to nil so how would you test for (no type, no value) but not (type, nil)?

It doesn’t seem like a better design either.

Your proposal

Now that you understand the problem and seen two ideas for how to fix it, it’s your turn to design a better solution.

I tried and the above 2 are the only ideas I had.

We are boxed by existing notions of zero values and using nil to represent them.

We could explore designs that re-think those assumptions but would that be Go anymore?

It’s easy to complain that something is a bad design.

It’s much harder, often impossible, to design something better.

Size textarea to content

2025-07-05T00:00:00Z

To size textarea to content:

textarea {
	field-sizing: content;
	min-height: 8rem;
	max-height: 70vh;
}

Using tailwindcss: <textarea class="min-h-[8rem] max-h-[70vh] field-sizing-content"></textarea>

Needs Chrome 123+, Firefox 126+

All about Svelte 5 snippets

2025-07-03T00:00:00Z

Snippets are a useful addition to Svelte 5. I use them in my Svelte 5 projects like Edna.

Snippet basics

A snippet is a function that renders html based on its arguments.

Here’s how to define and use a snippet:

{#snippet hello(name)}
  <div>Hello {name}!</div>
{/snippet}

{@render hello("Andrew")}
{@render hello("Amy")}

You can re-use snippets by exporting them:

<script module>
export { hello };
</script>

{@snippet hello(name)}<div>Hello {name}!</div>{/snippet}

Snippets use cases

Snippets for less nesting

Deeply nested html is hard to read.

You can use snippets to extract some parts to make the structure clearer.

For example, you can transform:

<div>
  <div class="flex justify-end mt-2">
    <button
      onclick={onclose}
      class="mr-4 px-4 py-1 border border-black hover:bg-gray-100"
      >Cancel</button
    >
    <button
      onclick={() => emitRename()}
      disabled={!canRename}
      class="px-4 py-1 border border-black hover:bg-gray-50 disabled:text-gray-400 disabled:border-gray-400 disabled:bg-white default:bg-slate-700"
      >Rename</button
    >
  </div>

into:

{#snippet buttonCancel()}
  <button
    onclick={onclose}
    class="mr-4 px-4 py-1 border border-black hover:bg-gray-100"
    >Cancel</button
  >
{/snippet}
{#snippet buttonRename()}...{/snippet}

To make this easier to read:

<div>
  <div class="flex justify-end mt-2">
    {@render buttonCancel()}
    {@render buttonRename()}
  </div>
</div>

snippets replace default `<slot/>`

In Svelte 4, if you wanted place some HTML inside the component, you used <slot />.

Let’s say you have Overlay.svelte component used like this:

<Overlay>
  <MyDialog></MyDialog>
</Overlay>

In Svelte 4, you would use <slot /> to render children:

<div class="overlay-wrapper">
  <slot />
</div>

<slot /> would be replaced with <MyDialog></MyDialog>.

In Svelte 5 <MyDialog></MyDialog> is passed to Overlay.svelte as children property so you would change Overlay.svelte to:

<script>
let { children } = $props();
</script>

<div class="overlay-wrapper">
  {@render children()}
</div>

children property is created by Svelte compiler so you should avoid naming your own props children.

snippets replace named slots

A component can have a default slot for rendering children and additional named slots.

In Svelte 5 instead of named slots you pass snippets as props.

An example of Dialog.svelte:

<script>
let { title, children } = $props();
</script>

<div class="dialog">
  <div class="title">
    {@render title()}
  </div>

  {@render children()}
</div>

And use:

{#snippet title()}
  <div class="fancy-title">My fancy title</div>
{/snippet}

<Dialog title={title}>
  <div>Body of the dialog</div>
</Dialog>

passing snippets as implicit props

You can pass title snippet prop implicitly:

<Dialog>
  {#snippet title()}
    <div class="fancy-title">My fancy title</div>
  {/snippet}

  <div>Body of the dialog</div>
</Dialog>

Because {snippet title()} is a child or <Dialog>, we don’t have to pass it as explicit title={title} prop. The compiler does it for us.

snippets to reduce repetition

Here’s part of how I render https://tools.arslexis.io/

{#snippet row(name, url, desc)}
  <tr>
    <td class="text-left align-top"
      ><a class="font-semibold whitespace-nowrap" href={url}>{name}</a>
    </td>
    <td class="pl-4 align-top">{@html desc}</td>
  </tr>
{/snippet}

{@render row("unzip", "/unzip/", "unzip a file in the browser")}
{@render row("wc", "/wc/", "like <tt>wc</tt>, but in the browser")}

It saves me copy & paste of the same HTML and makes the structure more readable.

snippets for recursive rendering

Sometimes you need to render a recursive structure, like nested menus or file tree.

In Svelte 4 you could use <svelte:self> but the downside of that is that you create multiple instances of the component. That means that the state is also split among multiple instances.

That makes it harder to implement functionality that requires a global view of the structure, like keyboard navigation.

With snippets you can render things recursively in a single instance of the component.

I used it to implement nested context menus.

snippets to customize rendering

Let’s say you’re building a Menu component. Each menu item is a <div> with some non-trivial children.

To allow the client of Menu customize how items are rendered, you could provide props for things like colors, padding etc. or you could allow ultimate flexibility by accepting an optional menuitem prop that is a snippet that renders the item.

You can think of it as a headless UI i.e. you provide the necessary structure and difficult logic like keyboard navigation etc. and allow the client lots of control over how things are rendered.

snippets for library of icons

Before snippets every SVG Icon I used was a Svelte component. Many icons means many files.

Now I have a single Icons.svelte file, like:

<script module>
  export { IconMenu, IconSettings };
</script>

{#snippet IconMenu(arg1, arg2, ...)}
  <svg>... icon svg</svg>
{/snippet}}

{#snippet IconSettings()}
  <svg>... icon svg</svg>
{/snippet}}

C++ engineering decision in SumatraPDF code

2025-07-02T00:00:00Z

SumatraPDF is a medium size (120k+ loc, not counting dependencies) Windows GUI (win32) C++ code base started by me and mostly written by 2 people.

The goals of SumatraPDF are to be:

fast
small
packed with features
and yet with thoughtfully minimal UI

It’s not just a matter of pride in craftsmanship of writing code. I believe being fast and small are a big reason for SumatraPDF’s success. People notice when an app starts in an instant because that’s sadly not the norm in modern software.

The engineering goals of SumatraPDF are:

reliable (no crashes)
fast compilation to enable fast iteration

SumatraPDF has been successful achieving those objectives so I’m writing up my C++ implementation decisions.

I know those decisions are controversial. Maybe not Terry Davis level of controversial but still.

You probably won’t adopt them. Even if you wanted to, you probably couldn’t. There’s no way code like this would pass Google review. Not because it’s bad but because it’s different.

Diverging from mainstream this much is only feasible if you have total control: it’s your company or your own open-source project.

If my ideas were just like everyone else’s ideas, there would be little point in writing about them, would it?

Use UTF8 strings internally

My app only runs on Windows and a string native to Windows is WCHAR* where each character consumes 2 bytes.

Despite that I mostly use char* assumed to be utf8-encoded.

I only decided on that after lots of code was written so it was a refactoring odyssey that is still ongoing.

My initial impetus was to be able to compile non-GUI parts under Linux and Mac. I abandoned that goal but I think that’s a good idea anyway.

WCHAR* strings are 2x larger than char*. That’s more memory used which also makes the app slower.

Binaries are bigger if string constants are WCHAR*.

The implementation rule is simple: I only convert to WCHAR* when calling Windows API. When Windows API returns WCHA* I convert it to utf-8.

No exceptions

Do you want to hear a joke? “Zero-cost exceptions”.

Throwing and catching exceptions generate bloated code.

Exceptions are a non-local control flow that makes it hard to reason about program. Every memory allocation becomes a potential leak.

But RAII, you protest. RAII is a “solution” to a problem created by exceptions. How about I don’t create the problem in the first place.

Hard core #include discipline

I wrote about it in depth.

My objects are not shy

I don’t bother with private and protected. struct is just class with guts exposed by default, so I use that.

While intellectually I understand the reasoning behind hiding implementation details in practices it becomes busy work of typing noise and then even more typing when you change your mind about visibility.

I’m the only person working on the code so I don’t need to force those of lesser intellect to write the code properly.

My objects are shy

At the same time I minimize what goes into a class, especially methods.

The smaller the class, the faster the build.

A common problem is adding too many methods to a class.

You have a StrVec class for array of strings. A lesser programmer is tempted to add Join(const char* sep) method to StrVec. A wise programmer makes it a stand-alone function: Join(const StrVec& v, const char* sep).

This is enabled by making everything in a class public. If you limit visibility you then have to use friendto allow Join() function access what it needs. Another example of “solution” to self-inflicted problems.

Minimize #ifdef

#ifdef is problematic because it creates code paths that I don’t always build.

I provide arm64, intel 32-bit and 64-bit builds but typically only develop with 64-bit intel build. Every #ifdef that branches on architecture introduces potential for compilation error which I’ll only know about when my daily ci build fails.

Consider 2 possible implementations of IsProcess64Bit():

Bad:

bool IsProcess64Bit() {
#ifdef _WIN64
    return true;
#else
    return false;
#endif
}

Good:

bool IsProcess64Bit() {
    return sizeof(uintptr_t) == 8;
}

The bad version has a bug: it was correct when I was only doing intel builds but became buggy when I added arm64 builds.

This conflicts with the goal of smallest possible size but it’s worth it.

Stress testing

SumatraPDF supports a lot of very complex document and image formats.

Complex format require complex code that is likely to have bugs.

I also have lots of files in those formats.

I’ve added stress testing functionality where I point SumatraPDF to a folder with files and tell it to render all of them.

For greater coverage, I also simulate some of the possible UI actions users can take like searching, switching view modes etc.

Crash reporting

I wrote about it in depth.

Heavy use of CrashIf()

C/C++ programmers are familiar with assert() macro.

CrashIf() is my version of that, tailored to my needs.

The purpose of assert / CrashIf is to add checks to detect incorrect use of APIs or invalid states in the program.

For example, if the code tries to access an element of an array at an invalid index (negative or larger than size of the array), it indicates a bug in the program.

I want to be notified about such bugs both when I test SumatraPDF and when it runs on user’s computers.

As the name implies, it’ll crash (by de-referencing null pointer) and therefore generate a crash report.

It’s enabled in debug and pre-release builds but not in release builds. Release builds have many, many users so I worry about too many crash reports.

premake to generate Visual Studio solution

Visual Studio uses XML files as a list of files in the project and build format. The format is impossible to work with in a text editor so you have no choice but to use Visual Studio to edit the project / solution.

To add a new file: find the right UI element, click here, click there, pick a file using file picker, click again.

To change a compilation setting of a project or a file? Find the right UI element, click here, click there, type this, confirm that.

You accidentally changed compilation settings of 1 file out of a hundred? Good luck figuring out which one. Go over all files in UI one by one.

In other words: managing project files using Visual Studio UI is a nightmare.

Premake is a solution. It’s a meta-build system. You define your build using lua scripts, which look like test configuration files.

Premake then can generate Visual Studio projects, XCode project, makefiles etc. That’s the meta part.

It was truly a life saver on project with lots of files (SumatraPDF’s own are over 300, many times more for third party libraries).

Using /analyze and cppcheck

cppcheck and /analyze flag in cl.exe are tools to find bugs in C++ code via static analysis. They are like a C++ compiler but instead of generating code, they analyze control flow in a program to find potential programs.

It’s a cheap way to find some bugs, so there’s no excuse to not run them from time to time on your code.

Using asan builds

Address Sanitizer (asan) is a compiler flag /fsanitize=address that instruments the code with checks for common memory-related bugs like using an object after freeing it, over-writing values on the stack, freeing an object twice, writing past allocated memory.

The downside of this instrumentation is that the code is much slower due to overhead of instrumentation.

I’ve created a project for release build with asan and run it occasionally, especially in stress test.

Write for the debugger

Programmers love to code golf i.e. put us much code on one line as possible. As if lines of code were expensive.

Many would write:

Bad:

    // ...
    return (char*)(start + offset);

I write:

Good:

    // ...
    char* s = (char*)(start + offset);
    return s;

Why?

Imagine you’re in a debugger stepping through a debug build of your code.

The second version makes it trivial to set a breakpoint at return s line and look at the value of s. The first doesn’t.

I don’t optimize for smallest number of lines of code but for how easy it is to inspect the state of the program in the debugger.

In practice it means that I intentionally create intermediary variables like s in the example above.

Do it yourself standard library

I’m not using STL. Yes, I wrote my own string and vector class. There are several reasons for that.

Historical reason

When I started SumatraPDF over 15 years ago STL was crappy.

Bad APIs

Today STL is still crappy. STL implementations improved greatly but the APIs still suck.

There’s no API to insert something in the middle of a string or a vector. I understand the intent of separation of data structures and algorithms but I’m a pragmatist and to my pragmatist eyes v.insert (v.begin(), myarray, myarray+3); is just stupid compared to v.inert(3, el).

Code bloat

STL is bloated. Heavy use of templates leads to lots of generated code i.e. surprisingly large binaries for supposedly low-level language.

That bloat is invisible i.e. you won’t know unless you inspect generated binaries, which no one does.

The bloat is out of my control. Even if I notice, I can’t fix STL classes. All I can do is to write my non-bloaty alternative, which is what I did.

Slow compilation times

Compilation of C code is not fast but it feels zippy compared to compilation of C++ code.

Heavy use of templates is big part of it. STL implementations are over-templetized and need to provide all the C++ support code (operators, iterators etc.).

As a pragmatist, I only implement the absolute minimum functionality I use in my code.

I minimize use of templates. For example Str and WStr could be a single template but are 2 implementations.

I don’t understand C++

I understand the subset of C++ I use but the whole of C++ is impossibly complicated. For example I’ve read a bunch about std::move() and I’m not confident I know how to use it correctly and that’s just one of many complicated things in C++.

C++ is too subtle and I don’t want my code to be a puzzle.

Possibility of optimized implementations

I wrote a StrVec class that is optimized for storing vector of strings. It’s more efficient than std::vector<std::string> by a large margin and I use it extensively.

Temporary allocator and pool allocators

I use temporary allocators heavily. They make the code faster and smaller.

Technically STL has support for non-standard allocators but the API is so bad that I would rather not.

My temporary allocator and pool allocators are very small and simple and I can add support for them only when beneficial.

Minimize unsigned int

STL and standard C library like to use size_t and other unsigned integers.

I think it was a mistake. Go shows that you can just use int.

Having two types leads to cast-apalooza. I don’t like visual noise in my code.

Unsigned are also more dangerous. When you substract you can end up with a bigger value. Indexing from end is subtle, for (int i = n; i >= 0; i--) is buggy because i >= 0 is always true for unsigned.

Sadly I only realized this recently so there’s a lot of code still to refactor to change use of size_t to int.

Mostly raw pointers

No std::unique_ptr for me.

Warnings are errors

C++ makes a distinction between compilation errors and compilation warnings.

I don’t like sloppy code and polluting build output with warning messages so for my own code I use a compiler flag that turns warnings into errors, which forces me to fix the warnings.