Hey dev.to community! 👋
I want to share an indie engineering project I’ve been building over the last few weeks: QuickConvertUnits.
It’s a fast, ad-free, local-first unit conversion utility designed to solve a personal frustration I had with the modern web ecosystem.
Whenever I needed to quickly convert cooking metrics on my phone or map out structural spatial areas (like square feet to acres) on-site, the top search results always led me to ancient calculator directories that completely choked my mobile browser. They forced megabytes of intrusive tracking pixels, pop-up scripts, and full-screen layout shifts onto the viewport.
I wanted to see how clean, lightweight, and fast a modern web utility could be if we stripped away all the bloat and focused strictly on modern client-side capabilities.
Here is a deep dive into the engineering decisions and code patterns behind the platform.
🛠️ The Core Technical Stack
- Zero Framework Architecture: Built entirely using native HTML5, semantic CSS, and pure vanilla JavaScript. No React re-renders, no heavy framework hydration lag.
- Progressive Web App (PWA): Engineered using custom service workers. Once a user loads a directory path once, the core math engines are cached locally. It runs 100% offline.
- Strictly Privacy-First: No backend servers, no cloud storage dependencies, and no remote data parsing. The application processes data instantly inside the local client layer.
💡 Interesting Code Patterns Implemented
1. Zero-Latency Reactive Calculation
Instead of forcing users to click an old-school "Submit" or "Calculate" button, the mathematical calculation logic executes reactively on the active browser input event listener.
Here is a simplified blueprint of the native listener strategy used to handle dynamic structural conversions without unnecessary DOM thrashing:
javascript
const inputElement = document.getElementById('source-value');
const outputElement = document.getElementById('target-output');
// Simple reactive calculation matrix execution
function handleInstantConversion() {
const rawValue = parseFloat(inputElement.value);
if (isNaN(rawValue)) {
outputElement.value = '';
return;
}
const conversionFactor = 0.03527396; // e.g., grams to ounces
const processedResult = rawValue * conversionFactor;
// Smooth rendering via precision normalization
outputElement.value = Number(processedResult.toFixed(4));
}
inputElement.addEventListener('input', handleInstantConversion);
Multi-Language i18n Without Heavy Bundles
To make the application globally accessible, I wanted to support comprehensive multi-language support (English, Italian, French, German, Chinese, Arabic, etc.).
Instead of pulling down a massive external internationalization library via npm, I kept the application bundle highly optimized by utilizing a lean native JSON lookup object matching the language pathing variables inside the window state. This allowed me to serve localized interfaces instantly while preserving a near-zero initial JS payload size.
🚀 What I Learned
Building this reminded me of how powerful native web APIs have become. We often reach for frameworks out of habit, even when building simple, high-performance daily utilities. Relying entirely on native web standards allowed me to keep the mobile performance score near perfect while offering complete offline capabilities that rival native mobile apps.
💬 I'd Love Your Feedback!
The project is live here: quickconvertunits.com
As developers, how are you dealing with floating-point math precision errors when handling deep decimal conversions in pure client-side JavaScript? I'd love to know what strategies you use to ensure absolute math precision without bringing in heavy mathematical utility libraries.
Let me know your thoughts on the performance layout, or if there are any custom conversion modules you think I should add next!
Top comments (0)