I Deleted Electron From My Windows Utility. It Went From 64 MB to 1.2 MB.

Aug 4, 2026

One job

Window Center & Resizer does exactly one thing: you press a key, and the active window jumps to the middle of your screen at a size you picked. That's the product.

I shipped it in June 2024, wrote up how I built it, and then didn't touch it for two years. In that time it collected about 2,373 downloads on GitHub and another 746 on MajorGeeks — both numbers read on 4 August 2026 — and got listed on Softpedia and MajorGeeks. Not viral. But a few thousand people installed it, and it kept working, which is its own quiet argument against touching anything.

Then I opened the repo again and actually read it.

The settings file is the entire product

Here is the app's complete configuration surface, verbatim from src/constants/defaultSettings.json:

{ "centerWindow": { "keybinding": "ctrl + shift + c" },
  "resizeWindow": { "keybinding": "f9",
                    "windowSizePercentages": [50/50, 75/75, 90/90] } }

Two hotkeys and three numbers. There is nothing else to configure, because there is nothing else the app does.

Serving those two hotkeys and three numbers: 1,114 lines of React for a tabbed settings UI, plus 507 lines of Electron main process to host it. The AutoHotkey script that did the actual work — find the window, compute the rectangle, move it — was 138 lines.

A further 208 lines were a bundled JSON parser, JXON.ahk. It existed for exactly one reason: React wrote the settings file in JavaScript conventions, and AutoHotkey then had to translate them back into something it understood. A parser to undo the formatting choices of the layer that didn't do any work.

That was the thing I hadn't seen while building it. Electron was never doing the work. AutoHotkey was always there, doing all of it. Electron was drawing a form — and charging 64 MB, 1,650 lines and seven runtime dependencies for the privilege.

The rewrite

2.0.0 is pure AutoHotkey v2. One portable executable. No installer, no runtime, no dependencies, no build chain beyond a single compiler invocation.

The settings window survived, because people do need to change their hotkeys. It's now roughly 80 lines of native AutoHotkey GUI, and it has no tabs — there was never enough in it to justify tabs. That was true in 1.0 too; the tabs were there because the framework made tabs easy, not because the app had that much to say.

Rewriting it surfaced four bugs that had been shipping for two years

This was the part I didn't expect. Porting logic forces you to read every line as though you're responsible for it, and four bugs fell out — all of them present since 1.0.

1 · Wrong size on secondary monitors. The clearest one to just show you:

ScreenWidth := A_ScreenWidth          ; the PRIMARY monitor
mon := GetNearestMonitorInfo(hwnd)    ; the CURRENT monitor
NewWidth := (ScreenWidth * WidthPercentage / 100)      ; sized off PRIMARY
NewX := mon.WALeft + (mon.WAWidth - NewWidth) / 2      ; centred on CURRENT

Sized against one monitor, centred on another. On a 4K primary with a 1080p secondary, a "50%" window on the secondary came out fullscreen.

2 · Windows overflowed the taskbar. Same function, same class of mistake: take the size from the full screen dimensions, then centre within the work area. At 90% the window extended underneath the taskbar. On a 1920×1080 display the bounds are 1080 and the work area is 1032 — a 48-pixel gap, which is exactly the taskbar.

3 · Fractional pixels were being handed to WinMove.

4 · The first size preset was unreachable. The counter was initialised to 1 and incremented before use, so the very first keypress selected preset 2. You could not get to 50/50 without cycling all the way around. That shipped for two years and nobody reported it — which tells you something about how far people get into a utility's feature list.

Bugs 1 and 2 have one fix, and it's a shape rather than a patch. Sizing and centring both derive from the same passed-in rectangle, so they cannot disagree with each other:

CenteredRect(waLeft, waTop, waWidth, waHeight, widthPct, heightPct) {
    w := Round(waWidth  * widthPct  / 100)
    h := Round(waHeight * heightPct / 100)
    x := waLeft + Round((waWidth  - w) / 2)
    y := waTop  + Round((waHeight - h) / 2)
    return { x: x, y: y, w: w, h: h }
}

The Round calls take care of bug 3 on the way past.

The bug a user did report

Issue #12, opened 11 March 2025: "Access denied" when resizing Task Manager.

This one isn't a maths error. WinMove raises OSError 5 because a non-elevated process cannot move a window owned by an elevated one — Windows simply refuses. There's no clever fix; the correct behaviour is to explain what happened instead of throwing a raw error dialog at someone. 2.0.0 does that, and offers "Restart as administrator" from the tray menu.

The issue was open for 17 months. Four months in, a second user — unrelated to the reporter — turned up to say they loved the tool and had hit the same error across many different programs. The common factor, once you know to look for it, was that all of those programs ran elevated.

The numbers

52× smaller. The port deleted 70 files and 33,327 lines.

One thing I'm deliberately not claiming: that it's faster. I never measured startup on either version, and smaller isn't the same as quicker. It's smaller, and that's the claim I can support.

What nearly broke the release

The rewrite had 63 passing assertions, four mutation-tested suites and a clean build. The thing that almost shipped broken was a filename in the README.

The download link pointed at Window-Center-Resize.exe. The new build produced WindowCenterResizer.exe. Because the URL is of the form releases/latest/download/<filename>, publishing 2.0.0 would have 404'd every existing download link in the wild — including the ones the software directories had mirrored, which are most of where the installs actually came from.

Caught in review. Not by any test, because no test compiles a README. The fix was to attach the binary under both filenames.

Get it

Download 2.0.0 · Source · Landing page

It's free, it stays free, and it's not code-signed — so Windows may show a SmartScreen prompt the first time you run it. You can read every one of the 454 lines before you do.