Plug a VIA-compatible keyboard into Chrome, open usevia.app, and you can move a key in about ten seconds. The layout is written into the controller's non-volatile memory over WebHID, so it follows the board to your work laptop with no driver and no login. A keyboard without that support charges you a firmware build, a bootloader jump and a flash every time you decide the bracket keys sit in the wrong place.
That difference outlasts switch feel, so this guide sorts on firmware first. We read spec sheets, manuals and firmware repositories to write it. We did not type on each board for a month, and we measured nothing with a decibel meter — no sound claim below is ours.
Layers matter more than switches
A 75% board is not smaller because it dropped keys. It is smaller because the keys moved to a layer. Hold one key and the right hand's home row becomes arrows, or the number row becomes F1 through F12. For code that means brackets, braces, angle brackets and underscore can sit under your fingers instead of at the far corners of the board.
The constraint is how many layers you get without touching a compiler. VIA ships four dynamic layers by default — DYNAMIC_KEYMAP_LAYER_COUNT is 4 in most vendor configs. That is enough for a base layer, a navigation layer, a symbol layer and one scratch layer. Past four you are back in QMK's C keymaps and a build toolchain. Plan the four before you buy.
Two firmware features are worth knowing by name because they decide how a small board feels. Tap-dance makes one key do different things by tap count. Mod-tap turns your home row into modifiers when held, which is why people move to 60% boards and stop curling a little finger toward Ctrl. Mod-tap also introduces timing bugs: roll quickly from A to S with A configured as a held Ctrl and you get a Ctrl+S you did not ask for. QMK's TAPPING_TERM and PERMISSIVE_HOLD exist to tune that, and tuning takes days, not minutes.
If $200 is more than you want to commit before you know whether layers suit you, the plastic-cased sibling runs the same configurator.
The VIA setup step the product pages skip
Here is the failure that will cost you an evening. You plug in a new board, open usevia.app in Chrome, and the app reports no device — or lists the keyboard and refuses to draw a layout. Nothing is broken. VIA only recognises a board it holds a definition file for, and those definitions live in a repository (the-via/keyboards) that vendors have to submit to. Newer or small-run boards ship the JSON on their own support page instead.
The fix is two clicks: open Settings, enable Show Design tab, then load the vendor's JSON there. The board appears immediately. This is almost never on the product page, and the support article that explains it usually sits a level below wherever you landed.
Two related things to plan for. WebHID is Chromium-only, so usevia.app works in Chrome, Edge, Brave and Arc, and does not work in Firefox or Safari. And wireless Keychron boards do not build from upstream QMK — Keychron maintains its own fork carrying the Bluetooth stack, so qmk setup against the main repository will not find them. If you stay in VIA you never notice. If you want a hand-written C keymap, you clone their tree. We did not compile it ourselves.
If your employer's device policy blocks WebHID or forbids installing a Chromium browser, a VIA board degrades to whatever layout it shipped with. Check that before paying for remappability you cannot reach.
Picks for split, minimal and locked-down machines
If the problem is your wrists rather than your key placement, the split contoured category is its own decision, and the model name matters more than usual.
Budget one to three weeks of reduced typing speed for that board. The concave wells and thumb clusters move nearly every key you have muscle memory for.
At the other end, the 60% purist option is neither hot-swap nor MX.
The HHKB has no arrow row at all — arrows are Fn plus the bracket, semicolon, quote and slash cluster. It is the most expensive way to own the fewest keys, and it is a poor first mechanical keyboard.
Half of the reach problem is in the editor, not the keyboard. Before you spend anything on hardware, look at what your editor already binds and how far your hands actually move to reach it.
What we did not test, and when to buy nothing
We did not measure sound, did not run typing-speed tests, and make no claim about RSI — that is a medical question, and a keyboard purchase is not a treatment. Switch lifetime numbers, like Cherry's 100-million-actuation rating for MX, are the manufacturer's figures, not ours.
For most developers the honest first move is to spend nothing. If the complaint is "Ctrl and Escape are in bad places", kanata (cross-platform, open source) and Karabiner-Elements (macOS, free) give you layers, home-row mods and tap-hold in software on the keyboard already in front of you. Run that config for two weeks. If it sticks and the only remaining annoyance is the physical layout or a mushy feel, buy hardware then — and you will know exactly which layout you want, because you already built it.
Three conditions flip it to hardware: you move between machines often and software remaps do not follow you, your work machine blocks background utilities, or the software layer produces mistyped modifiers you cannot tune out.
Whichever board you buy, write your layout down in a file and commit it. VIA keymaps live in the keyboard's memory, and a firmware update or a factory reset erases them with no prompt.
Originally published at pickuma.com. Subscribe to the RSS or follow @pickuma.bsky.social for new reviews.
Top comments (0)