DEV Community: jack

What the Browser Gamepad API Can—and Cannot—Tell You About Controller Health

jack — Wed, 22 Jul 2026 14:00:00 +0000

A controller can appear to work normally while still having problems that affect gameplay.

A stick may not return perfectly to the center. A trigger may fail to reach its full range. Wireless mode may produce less stable updates than a wired connection. A controller may also behave differently across browsers, operating systems, and connection modes.

Most online controller testers only visualize buttons and axes. That is useful, but it does not answer a more important question:

Is the controller actually healthy?

While building Controller Tester Online, I explored how far the browser Gamepad API can go beyond basic input visualization.

The result is a browser-based testing workflow that checks buttons, triggers, analog sticks, stick drift, circularity, deadzone behavior, update stability, and vibration support.

However, browser-based testing also has important limitations. In particular, browser measurements should not be confused with low-level USB hardware analysis.

This article explains what the Gamepad API can measure reliably, what it can only estimate, and how I approached building a more complete controller health check.

Reading a Controller in the Browser

The Gamepad API provides access to controllers connected to a user's device.

A basic implementation can start like this:

const gamepads = navigator.getGamepads();
const gamepad = gamepads[0];

if (gamepad) {
  console.log(gamepad.id);
  console.log(gamepad.buttons);
  console.log(gamepad.axes);
}

The browser exposes several useful properties:

{
  id,
  index,
  connected,
  mapping,
  buttons,
  axes,
  timestamp
}

For each button, the browser can usually provide:

{
  pressed,
  touched,
  value
}

Digital buttons normally return values close to either 0 or 1.

Analog inputs, such as triggers, may return values across a range.

Analog sticks are usually represented as axes between approximately -1 and 1.

A typical layout might look like this:

const leftStickX = gamepad.axes[0];
const leftStickY = gamepad.axes[1];

const rightStickX = gamepad.axes[2];
const rightStickY = gamepad.axes[3];

The exact axis and button mapping can vary depending on the controller, driver, browser, operating system, and whether the controller uses the standard mapping.

Why the User Usually Has to Press a Button First

Browsers do not always expose a connected controller immediately.

In many cases, the user must first press a button or move a stick. This behavior helps prevent websites from silently identifying connected gaming devices without user interaction.

A controller testing page therefore needs a clear initial state, such as:

Connect your controller, then press any button to activate it.

The page can also listen for connection events:

window.addEventListener("gamepadconnected", (event) => {
  console.log("Controller connected:", event.gamepad.id);
});

window.addEventListener("gamepaddisconnected", (event) => {
  console.log("Controller disconnected:", event.gamepad.id);
});

However, connection events alone are not enough. The application still needs to read the latest controller state continuously.

A common approach is to use requestAnimationFrame:

function updateController() {
  const gamepads = navigator.getGamepads();
  const gamepad = gamepads[0];

  if (gamepad) {
    updateButtons(gamepad.buttons);
    updateAxes(gamepad.axes);
  }

  requestAnimationFrame(updateController);
}

requestAnimationFrame(updateController);

This works well for visualization, but it is important to understand that the rendering loop is not necessarily the same as the controller's hardware polling loop.

That distinction becomes important later.

Raw Input Is Not a Health Check

Showing live button and stick values is useful, but it does not automatically tell the user whether the controller has a problem.

For example, a stick at rest might report:

X: 0.021
Y: -0.034

Does that mean the stick is drifting?

Not necessarily.

Small center deviations are common. Their impact depends on several factors:

The size of the deviation
Whether the value is stable or constantly moving
The deadzone used by the game
The controller model
The connection mode
Calibration and driver behavior

A better controller test therefore needs timed sampling rather than relying on a single reading.

Measuring Stick Drift

For a basic drift test, the user should place the controller on a stable surface and avoid touching the analog sticks.

The application can then sample both sticks for several seconds.

A simplified implementation might look like this:

function getStickMagnitude(x, y) {
  return Math.sqrt(x * x + y * y);
}

function sampleStick(gamepad) {
  const leftX = gamepad.axes[0] ?? 0;
  const leftY = gamepad.axes[1] ?? 0;

  const rightX = gamepad.axes[2] ?? 0;
  const rightY = gamepad.axes[3] ?? 0;

  return {
    left: {
      x: leftX,
      y: leftY,
      magnitude: getStickMagnitude(leftX, leftY),
    },
    right: {
      x: rightX,
      y: rightY,
      magnitude: getStickMagnitude(rightX, rightY),
    },
  };
}

During the test, the tool can record:

Average X and Y values
Maximum distance from the center
Variation over time
The percentage of samples outside a chosen threshold

For example:

let maximumMagnitude = 0;
let magnitudeSum = 0;
let sampleCount = 0;

function addSample(x, y) {
  const magnitude = Math.sqrt(x * x + y * y);

  maximumMagnitude = Math.max(maximumMagnitude, magnitude);
  magnitudeSum += magnitude;
  sampleCount += 1;
}

function getAverageMagnitude() {
  return sampleCount === 0 ? 0 : magnitudeSum / sampleCount;
}

A single short spike should not necessarily produce a severe warning. It is usually more useful to consider both the maximum deviation and the average behavior during the test.

The result can then be presented as practical guidance rather than an absolute diagnosis.

For example:

Left stick maximum center deviation: 3.2%
Suggested initial deadzone: approximately 4%–5%

The suggested deadzone should be slightly higher than the observed center deviation, while still remaining low enough to preserve responsiveness.

It is also important to avoid claiming that one threshold is correct for every controller.

Testing Stick Range and Circularity

A healthy analog stick should normally reach close to its expected outer range when rotated around the edge.

To test this, the user can rotate the stick slowly through a complete circle.

Each sample can be plotted on a two-dimensional coordinate system:

const point = {
  x: gamepad.axes[0],
  y: gamepad.axes[1],
};

A perfectly circular result would follow an ideal unit circle:

x² + y² = 1

Real controllers rarely produce a perfect circle.

Some may produce:

Slightly square output
Restricted diagonal movement
Uneven maximum range
Different results in different directions
Values that exceed the expected unit circle
Incomplete outer-edge coverage

The distance from the center can be calculated using:

const radius = Math.sqrt(x * x + y * y);

This makes it possible to inspect whether the stick consistently reaches the outer range.

However, circularity should not be treated as a simple pass-or-fail score.

A controller can have imperfect circularity and still perform normally in games. Different controller firmware and calibration systems may intentionally shape analog output differently.

The most useful result is usually a visual trace combined with several measurements:

Minimum outer radius
Maximum outer radius
Average radius
Directional consistency
Percentage of expected outer-edge coverage

Checking Trigger Range

Triggers can also develop problems.

A trigger may:

Fail to return completely to zero
Fail to reach its maximum value
Move inconsistently
Produce unstable values
Have a large inactive area at the beginning of travel

A trigger test should record both its resting value and maximum value.

For example:

let minimumValue = 1;
let maximumValue = 0;

function updateTrigger(value) {
  minimumValue = Math.min(minimumValue, value);
  maximumValue = Math.max(maximumValue, value);
}

The user can then be asked to release and fully press each trigger.

A result might look like:

Left trigger resting value: 0.000
Left trigger maximum value: 0.984

This is more informative than only showing a moving progress bar.

Estimating Update Rate in a Browser

Polling rate is one of the most easily misunderstood measurements in browser-based controller testing.

A website does not have the same low-level access as a USB protocol analyzer or native hardware testing application.

The browser may expose a timestamp for the gamepad state:

const timestamp = gamepad.timestamp;

By observing changes in this timestamp, an application can estimate how frequently the browser receives new controller state.

A basic calculation might look like this:

const interval = currentTimestamp - previousTimestamp;

if (interval > 0) {
  const estimatedRate = 1000 / interval;
}

For example, an interval of approximately 4 milliseconds would correspond to:

1000 / 4 = 250 Hz

However, this should be described as a browser-observed estimate.

Several layers can influence the result:

Controller hardware
USB, Bluetooth, or wireless receiver
Device firmware
Operating-system input stack
Driver behavior
Browser implementation
Page visibility
Rendering performance
JavaScript scheduling
Power-saving features

The browser may also reuse state between frames or expose timestamps differently across platforms.

Therefore, a browser tool should not claim:

Your controller's exact hardware polling rate is 500 Hz.

A more accurate description is:

The browser observed controller updates at an estimated average rate of approximately 500 Hz during this sample.

That wording matters.

Polling Rate Versus Rendering Rate

It is also important not to calculate polling rate only from requestAnimationFrame.

Most displays run at 60 Hz, 120 Hz, 144 Hz, or another fixed refresh rate. If controller state is checked only once per animation frame, the measurement may be limited by the page's rendering frequency.

For example, a 60 Hz rendering loop runs approximately once every:

1000 / 60 = 16.67 ms

A controller may update several times within that interval, but the JavaScript code may only observe the latest state.

This means:

requestAnimationFrame(() => {
  // This loop frequency is not automatically the controller polling rate.
});

For browser testing, update-rate measurements are most useful for relative comparisons.

For example:

Wired mode versus Bluetooth mode
Bluetooth mode versus a 2.4 GHz receiver
One USB port versus another
Stable updates versus large irregular gaps
Different browsers on the same computer

The result should be interpreted as a practical browser-level signal rather than laboratory-grade hardware data.

Measuring Jitter

Average update rate does not tell the whole story.

Two controllers can have the same average estimated rate while producing very different timing consistency.

Suppose one controller produces intervals like:

4.0 ms
4.1 ms
3.9 ms
4.0 ms

Another might produce:

1.0 ms
8.0 ms
2.0 ms
5.0 ms

Both sets can produce a similar average, but the second is much less consistent.

A useful test should therefore record:

Average interval
Minimum interval
Maximum interval
Standard deviation
Large timing spikes
Distribution of intervals

A simplified standard-deviation calculation might look like this:

function standardDeviation(values) {
  if (values.length === 0) return 0;

  const average =
    values.reduce((sum, value) => sum + value, 0) / values.length;

  const variance =
    values.reduce((sum, value) => {
      const difference = value - average;
      return sum + difference * difference;
    }, 0) / values.length;

  return Math.sqrt(variance);
}

This measurement can help identify unstable browser-observed updates, although it still cannot reveal exactly where in the hardware-to-browser pipeline the instability originated.

Detecting Vibration Support

Some browsers and controllers expose a vibration actuator through the Gamepad API.

A capability check may look like this:

const actuator = gamepad.vibrationActuator;

if (actuator) {
  console.log("Vibration actuator detected");
}

A short vibration test might use:

await gamepad.vibrationActuator.playEffect("dual-rumble", {
  duration: 500,
  strongMagnitude: 0.8,
  weakMagnitude: 0.5,
});

However, the availability of the API does not guarantee that vibration will work in every environment.

Support may depend on:

The browser
The operating system
The controller
The connection method
Browser permissions
Driver support

For this reason, a browser tool should distinguish between:

A vibration interface being exposed
A vibration command being accepted
The user confirming that physical vibration occurred

Capability detection alone is not always enough.

Keeping Controller Tests Local

A controller testing tool does not need to upload input data to a server.

Button states, axes, timestamps, drift samples, and test results can all be processed locally in JavaScript.

This provides several benefits:

Immediate feedback
No account requirement
Lower latency
Better privacy
Easier testing across devices
No need to store controller identifiers or input history

The report can also be generated locally from the completed tests.

For a tool like this, browser-side processing is not just convenient. It is usually the most appropriate architecture.

Building a Complete Testing Workflow

Instead of presenting every metric at once, I organized the testing process into a sequence.

A typical workflow is:

Connect and activate the controller
Check the detected controller name and mapping
Test every button
Test both triggers
Move both sticks through their full range
Leave the sticks untouched for a drift test
Rotate each stick for a circularity test
Sample browser-observed update intervals
Check vibration support
Generate a summary report

This makes the process easier for non-technical users while still exposing detailed measurements for developers and advanced users.

The live implementation is available here:

Try Controller Tester Online

The tests run inside the browser, and controller input data is processed locally.

What Browser Testing Can Tell You

A browser-based controller test can be useful for identifying:

Buttons that do not register
Buttons that remain active after release
Triggers with incomplete travel
Analog sticks that do not return near the center
Significant stick drift
Restricted stick range
Uneven directional output
Irregular browser-observed update timing
Differences between connection modes
Whether vibration support is available to the browser

These tests are also useful when buying or selling a used controller, comparing connection modes, troubleshooting input issues, or checking a controller before starting a game.

What Browser Testing Cannot Prove

A browser test cannot always determine:

The exact USB hardware polling rate
The precise source of input latency
Whether a problem comes from firmware, drivers, the browser, or the operating system
How every game applies its own deadzone and response curve
Whether a controller meets laboratory calibration standards
Whether a wireless timing spike came from interference or software scheduling

Browser measurements should therefore be treated as diagnostic evidence, not absolute hardware certification.

Lessons From Building the Tool

The main lesson was that visualization is easy, but interpretation is difficult.

Displaying an axis value is straightforward.

Explaining whether that value indicates a meaningful problem requires:

Multiple samples
Clear testing instructions
Appropriate thresholds
Transparent limitations
Results that avoid false precision

The same applies to polling rate.

A number such as 250 Hz appears precise, but the surrounding measurement method matters more than the number itself.

A trustworthy testing tool should clearly separate:

Direct values reported by the Gamepad API
Calculations based on timed samples
Browser-level estimates
User-confirmed hardware behavior

That distinction helps users understand what the result actually means.

Feedback From Other Developers

Controller behavior varies significantly across devices and platforms, so broader testing is useful.

I would be interested to know:

Which controllers produce unusual button or axis mappings?
Do you see different results in Chrome, Edge, Firefox, or Safari?
How different are your wired, Bluetooth, and 2.4 GHz results?
Does vibration work correctly on your operating system?
Are there additional controller health metrics that would be useful?

You can test your controller at Controller Tester Online and share your browser, operating system, controller model, and connection method in the comments.

Disclosure: AI was used to help improve the English wording and article structure. The testing methodology, implementation details, and technical conclusions were reviewed by the author.

Why I Split My Mouse Tester Into Its Own Site — And What "Low 5%" Actually Tells You About Your Mouse

jack — Mon, 22 Jun 2026 11:22:36 +0000

Why I Split My Mouse Tester Into Its Own Site — And What "Low 5%" Actually Tells You About Your Mouse

After my last post about bypassing Chrome's event loop to measure polling rates, I got a question I couldn't stop thinking about:

"I have a 4000Hz Razer mouse. The test shows an average of 3,847Hz. Is that... good? Or is something wrong?"

The honest answer: the average doesn't tell you. And that gap between "what the spec says" and "what actually matters in-game" is exactly why I ended up building mousepollingratetest.com.

A quick backstory

My original hardware testing project lives at hardwaretest.org — a broader tool covering multiple peripherals. Mouse polling rate was just one feature among many there.

But after publishing those first posts, mouse polling rate questions kept coming: from competitive FPS players, from mechanical keyboard folks curious about crossover behavior, from people debugging USB dropouts. The topic was pulling more search traffic and user engagement than any other test on the site.

So I split it out. One domain, one job. And in the process of rebuilding it as a standalone tool, I had to confront a question I'd been sidestepping: what metrics actually matter?

The problem with average polling rate

Most browser-based polling rate testers show you one number: your average Hz. That number feels satisfying — you see "998 Hz" and think "close enough to 1000, we're good."

But imagine two mice:

Mouse A: Every single report arrives at exactly 1ms intervals. Average: 1000Hz.
Mouse B: Most reports arrive at 1ms, but every 20th report takes 3ms. Average: ~952Hz.

In a benchmark, Mouse B looks fine. In a fast-paced FPS, that 3ms dropout is the exact moment your crosshair skips. Your aim didn't fail — your hardware did.

This is why I built three additional metrics into mousepollingratetest.com that I think tell a more complete story.

The three metrics that actually matter

1. Low 5% (the "worst-case" rate)

Borrowed from storage benchmarking (where it's called P5 latency), Low 5% filters out your best 95% of samples and shows you the average of the slowest 5%.

In plain terms: it's what your mouse does when things go wrong. USB bus contention, CPU spikes, background processes — they all show up here.

Example from a real test session:

Mouse	Average Hz	Low 5% Hz	Gap
Mouse A (1000Hz mode)	987	961	-26
Mouse B (1000Hz mode)	994	743	-251

Mouse B looks better on average. Mouse B is the worse gaming mouse. The Low 5% exposed it.

2. Jitter (interval standard deviation)

Jitter measures how consistent your polling intervals are, expressed as the standard deviation of the time between events (in milliseconds).

A 1000Hz mouse should fire every 1.0ms. If your jitter is 0.08ms, your intervals are ranging roughly from 0.92ms to 1.08ms — tight, stable, good. If your jitter is 0.4ms, your mouse is swinging between 0.6ms and 1.4ms intervals — you'll feel that as cursor microstutter.

Stable mouse:  [1.01, 0.99, 1.00, 1.02, 0.98] → jitter: 0.015ms ✅
Jittery mouse: [0.72, 1.31, 0.88, 1.45, 0.64] → jitter: 0.38ms  ⚠️

Jitter under ~0.1ms is excellent. Above 0.3ms, you're likely to notice it in precision tasks.

3. Stability Score (and the Grade)

Stability is a composite percentage that combines sample count, jitter, and dropout rate into a single signal. The Grade (S / A / B / C) maps this to something easier to act on at a glance.

An "S" grade means your hardware + USB path + OS are all playing nicely together. A "C" means something is wrong — but the individual metrics above tell you what.

The Chrome Extension angle

One thing I hadn't anticipated: a lot of people want to check polling rate without navigating to a website mid-game. So I shipped a companion Chrome Extension — toolbar popup, zero permissions, 6-second test, same metrics.

It routes back to mousepollingratetest.com for the full histogram and Leaderboard, but the quick check is fully self-contained.

Zero-permission browser extensions are a nice constraint to build against: no storage, no network, everything computed and discarded in memory. The implementation is simpler than the main site in some ways, more limited in others (no IndexedDB for local result history, for example).

What 8000Hz actually looks like in a browser

For the 4000Hz/8000Hz crowd: browser tests will always underreport at extreme polling rates. Here's why.

When your mouse fires at 8000Hz, it's producing a report every 0.125ms. Chrome's pointermove event handler is bound by the browser's internal event processing loop — which, even with setPointerCapture and raw input hints, can't reliably resolve sub-0.5ms intervals without coalescing.

So if mousepollingratetest.com shows you 3,800Hz on an 8000Hz mouse, that's not a bug. That's the browser's effective delivery rate after OS scheduling and USB interrupt handling. For real-world comparison purposes (how does my mouse perform in Chrome?), that's actually the right number to care about.

Want the raw hardware number? You need a native app. Want to know how your mouse behaves in every browser-based game you play? You're already in the right place.

What I'd build next

If you've gotten this far, you might as well go test your mouse: mousepollingratetest.com

The Leaderboard is where things get interesting — seeing how different mice cluster by brand, polling mode, and USB configuration. A 2000Hz Logitech G Pro X Superlight 2 on a dedicated USB controller vs. a USB hub tells a very different stability story.

If you have a high-Hz mouse, I'd genuinely like to see your Low 5% numbers. Drop them in the comments.

Previously in this series:

Is 1000Hz possible in Chrome? Bypassing the Event Loop to test Mouse Polling Rate

jack — Thu, 25 Dec 2025 02:01:48 +0000

As a PC gamer, I've always hated installing 500MB of bloatware (looking at you, Razer Synapse and G-Hub) just to verify if my mouse is actually running at its advertised 1000Hz polling rate.

I asked myself: Why can't I just test this in the browser?

The common answer is: "You can't. The browser is too slow. requestAnimationFrame is capped at your monitor's refresh rate (usually 60Hz or 144Hz)."

Challenge accepted. 🛠️

I spent the last few weeks building https://hardwaretest.org/mouse-polling-rate-test/, a privacy-first diagnostic suite. The hardest part was getting accurate, raw input readings that bypass the visual rendering loop.

Here is how I solved the "1000Hz Problem" in Vanilla JS.

The Problem: Visuals vs. Inputs
Most web animations rely on requestAnimationFrame (rAF). If your monitor is 60Hz, rAF fires every ~16.6ms. If you try to measure a 1000Hz mouse (which sends data every 1ms) inside a rAF loop, you will miss 94% of the data.

We need to decouple the Input Thread from the Render Thread.

The Solution: pointermove + performance.now()
We can't rely on the screen painting. We need to listen to the raw pointermove event, which fires much more frequently than the screen updates in modern browsers (Chrome/Edge handle this effectively via "Coalesced Events" logic, though we want the raw stream).

But standard Date.now() isn't precise enough. It gives us milliseconds. For 1000Hz, we need microseconds.

Enter the High Resolution Time API.

The Code
Here is the simplified logic of how I calculate the instant Polling Rate (Hz):

JavaScript

let lastEventTime = 0;
let pollingRateSamples = [];

window.addEventListener('pointermove', (event) => {
// 1. Get the microsecond-precise timestamp
const currentEventTime = performance.now();

// 2. Calculate the delta (time between two events)
const timeDelta = currentEventTime - lastEventTime;

// 3. Convert to Frequency (Hz)
// Hz = 1000ms / delta
const instantaneousHz = 1000 / timeDelta;

// 4. Filter out noise (idle or super slow movements)
if (instantaneousHz > 10 && instantaneousHz < 8000) {
pollingRateSamples.push(instantaneousHz);
}

lastEventTime = currentEventTime;

// NOTE: Do NOT update the DOM here!
// Updating the UI every 1ms will kill the browser performance.
// Store the data, and visualize it in a separate requestAnimationFrame loop.
});
The "Event Loop" Trap
The tricky part is that browsers try to "group" events to save battery.

If you run a heavy operation inside that pointermove listener, the browser will start throttling the event firing rate to match the frame rate.

The trick is:

Keep the event listener extremely lightweight (just math and array pushing).

De-couple the visualization. Use a separate requestAnimationFrame loop to read from the pollingRateSamples array and draw the graph.

The Result
By separating the input capture from the rendering, I managed to get consistent readings matching local software:

You can try the live demo here: Mouse Polling Rate Test

It also includes a Gamepad Tester (for stick drift) and a Dead Pixel test, all running locally in the browser.

Discussion 💬
I built this to prove that modern Web APIs are powerful enough to replace most "utility" desktop software.

What do you think? Are we at a point where we can finally uninstall those 500MB driver suites, or will native apps always be king for hardware interaction?

Let me know in the comments! 👇

Vibe Coded a Hardware Tester in a Weekend. (Spoiler: The UI took 10 mins, the Physics took 2 days)

jack — Wed, 17 Dec 2025 04:15:46 +0000

The Vibe: I wanted to build a simple, privacy-focused tool to test PC hardware (Mice, Keyboards, Screens) without installing shady .exe files.

The Tool: I opened my AI editor (Cursor/Claude), entered "flow state," and started prompting. My goal was www.hardwaretest.org.

Here is what I learned about the reality of Vibe Coding a tool that requires high-precision hardware interaction.

Where Vibe Coding Shines (The UI) This part felt like magic.

"Make it dark mode." -> Done.

"Give me a grid of clickable colors for dead pixel testing." -> Done.

"Make it responsive for mobile." -> Done.

In about 2 hours, I had a beautiful, functional frontend deployed on Vercel. If I were hand-coding the CSS/Tailwind, this would have taken me a full day.

Where the Vibe Died (The Logic) Then I tried to implement the Keyboard Polling Rate Test. I needed to detect if a gaming keyboard was actually reporting at 1000Hz (1ms latency).

I asked the AI: "Write a script to measure key press intervals." The AI confidently spit out code using standard Date.now() and addEventListener.

The Result? Jittery garbage data. The AI didn't understand that:

The Browser Event Loop is often slower than a high-end keyboard.

Date.now() isn't precise enough for sub-millisecond measurements.

DOM updates (rendering the number) cause layout thrashing that slows down the measurement.

The "Manual Mode" Fix I had to snap out of "Vibe Mode" and put on my Senior Engineer hat. I spent the next 48 hours manually debugging and rewriting the core logic.

Switched to performance.now() for microsecond precision.

Implemented a sliding window average algorithm to smooth out the browser's main thread jitter.

Decoupled the Input Loop (data capture) from the Render Loop (requestAnimationFrame).

The Verdict
Vibe Coding is a force multiplier, but it's not a replacement for domain knowledge.

AI built the vessel (UI, Layout, SEO schema).

I had to build the engine (Timing algorithms, Physics).

The tool is now live and stable. It features a Keyboard Tester, Mouse Double-Click Detector, and a Dead Pixel Fixer (Canvas-based).

Check it out here: 👉 www.hardwaretest.org

I'm curious—has anyone else hit a wall where AI implies "it works" but the underlying physics/logic is completely broken?

I Tried "Vibe Coding" a Hardware Test Site: AI is Powerful, But It's Not Magic (Yet) 🛠️

jack — Tue, 09 Dec 2025 01:35:32 +0000

👋 The Backstory
I want to share a recent "experimental project" of mine: HardwareTest.org.

The motivation was simple: I bought some new peripherals and wanted to test them. But I was fed up with the existing tools—screens full of ads, outdated UIs, or sketchy .exe files that I didn't want to download.

As a self-described "average developer," I recently got brainwashed by the concept of "Vibe Coding" (coding by natural language/AI intuition). I thought, "AI is so strong now. I'll just write the prompts, let the AI write the code, and I'll be done in minutes, right?"

Spoiler Alert: I was too naive. 😂
While AI absolutely lowered the barrier to entry and boosted my speed by 10x, taking a tool from "it works" to "it feels good to use" was full of hidden traps.

🚧 The Real Challenges
Here is a breakdown of the actual struggles I faced while pair-programming with AI:

The Tooling Chaos
My workflow was a bit of a mess. I started with Antigravity (it designed the initial UI), but ran out of credits. I switched to Codex to finish the logic. For the blog content, I used Gemini, but integrating that content back into the project via Codex resulted in a formatting nightmare. It was a lot of back-and-forth "fixing" what the AI broke.
Browser Limitations vs. Physics (The Keyboard Test)
I thought testing Keyboard Polling Rate would be simple: just tell the AI to "write an event listener."

The Reality: I discovered that the browser's Event Loop often can't even keep up with a 1000Hz gaming keyboard. The raw data coming out was jittery and unusable. The Fix: I was forced into dozens of rounds of conversation with the AI. We had to optimize the algorithm, add debounce logic, and implement sliding averages just to get a relatively accurate "Real-time Hz Dashboard" on the web.

The Devil is in the Details (The Mouse Test)
I assumed a mouse test was just listening for onClick. The Reality: To properly test for Double Click issues (a gamer's nightmare) and Scroll Wheel rollback, you need very precise counting logic. Also, the AI kept confusing "Middle Click" (pressing the wheel) with "Scrolling" (spinning the wheel). It took a lot of human intervention to separate those events cleanly.
The SEO Battle
Writing the code was just step one. To get this English-language site indexed by Google, I spent ages wrestling with Schema, FAQ, and JSON-LD. The Insight: AI writes syntactically correct code, but often logically nonsensical SEO tags. This led to Google Search Console errors that I had to manually debug and patch.

✨ The Result

Despite the process being more twisted than I expected, I’m still proud of what this experiment produced.
It became a pure static, ad-free, dark-mode online hardware diagnostic suite — and more importantly, a real-world test of what AI-assisted coding can and cannot do well.

The original experiment is available here:
👉 https://hardwaretest.org

Current Features:

⌨️ Keyboard Test: Visualizer with a real-time Hz polling rate dashboard (and Ghosting/NKRO support).

🖱️ Mouse Test: Left/Right/Middle buttons + Scroll Wheel + Double Click detection.

🖥️ Dead Pixel & Fixer: Standard color cycle test, plus a "High-Frequency Noise Repair" feature built with Canvas.

🎧 Audio Test: Left/Right channel separation + Logarithmic Sweep.

This "Vibe Coding" experience taught me a valuable lesson: AI is an incredibly fast junior developer. It can speed up production by 1000%, but it cannot yet replace the human eye for product details, edge cases, and user experience.

🙏 Feedback Welcome! The site just went live, so there are definitely bugs and rough edges. If you have a moment to try it out, I’d love to hear your feedback in the comments!

Update (Several weeks later)

After the initial launch, I ran into a problem I didn’t expect at all — SEO.

The AI-generated structure worked fine visually, but Google treated most pages as duplicates:

very similar raw HTML
reused meta descriptions
canonical pointing to the homepage

As a result, many URLs were canonicalized away in Google Search Console.

Instead of patching the old structure endlessly, I decided to take a more radical approach:
I extracted the most requested feature — mouse polling rate testing — and rebuilt it as a dedicated mouse polling rate testing tool.

This time, I avoided “AI-generated SEO” entirely and relied on proper SEO fundamentals.
The difference in indexing and visibility was immediately noticeable.

This experience reinforced something important for me:
AI can write code fast, but search engines still reward human judgment and structure.