DEV Community: 임세환

Building an Offline-First Exchange Calculator with Vanilla JavaScript

임세환 — Tue, 12 May 2026 12:38:21 +0000

SudangHelp is a Korean financial decision engine that turns scattered government policies and financial data into simple calculator outputs. The product direction is intentionally practical: users should be able to open a page, enter a number, and get a clear result without reading through multiple policy documents.

One of the more interesting tools in this system is the travel exchange calculator. At first, it sounds like a basic currency converter, but the real use case is a little different: travelers need fast answers, country-specific defaults, and a page that still behaves reasonably when the network is unstable.

People do not always need a full finance dashboard when they are traveling. They need to know things like:

"How much is 100,000 VND in KRW?"
"Can I use this in the airport without installing an app?"
"Can I open the same page again if the connection is bad?"
"Can the page start with the right currency for Vietnam, Thailand, or Japan?"

That changed the implementation direction. I did not want to build a heavy app. I wanted a fast static page that behaves like a small app when needed.

The result is the live SudangHelp exchange calculator, built with plain HTML, CSS, and Vanilla JavaScript.

This post is a short implementation note on how I structured it.

1. Why I used Vanilla JavaScript

The calculator does not need a framework. Most of the state is local and temporary:

the source currency
one or more target currencies
the amount entered by the user
the latest loaded exchange rates
the country preset inferred from the URL

Using Vanilla JavaScript kept the runtime small and made the page easier to cache. It also reduced the amount of build tooling needed for a static site.

The core conversion logic is intentionally boring:

function convertCurrency(amount, from, to) {
  if (!EXCHANGE_RATES[from] || !EXCHANGE_RATES[to]) return 0;
  return (amount / EXCHANGE_RATES[from]) * EXCHANGE_RATES[to];
}

For a calculator, boring code is usually a good thing. The more important work was around page behavior: presets, fallback data, and offline access.

2. URL-driven country presets (briefly)

The calculator uses URL-based routing where each country path (e.g., /vietnam/, /japan/, /thailand/) initializes the calculator with the correct default currency pair — all served from a single static HTML file.

I covered this pattern in detail in an earlier post:

👉 Building a 49-Country Exchange Calculator with a Single Static Page

For this article, what matters is that the URL-derived preset determines which currency pair the offline cache prioritizes. That brings us to the more interesting part — making the whole thing work without an internet connection.

3. Live rates with a safe fallback

The calculator loads exchange rates from a worker endpoint. If the request succeeds, the app updates the in-memory rate table and recalculates the visible result.

If the request fails, the calculator does not crash. It falls back to default rates and shows an offline-mode message.

The simplified flow:

async function loadRates() {
  try {
    const response = await fetch(EXCHANGE_API_URL);

    if (!response.ok) {
      throw new Error(`HTTP error: ${response.status}`);
    }

    const data = await response.json();
    const rates = data.rates || data;

    if (typeof rates !== 'object' || rates === null) {
      throw new Error('Invalid rates data');
    }

    Object.keys(EXCHANGE_RATES).forEach(code => {
      if (rates[code] && typeof rates[code] === 'number' && rates[code] > 0) {
        EXCHANGE_RATES[code] = rates[code];
      }
    });

    updateDisplay();
    updateRateDisplay();
  } catch (error) {
    rateInfo.textContent = 'Offline mode using fallback rates';
  }
}

There are two important ideas here:

Validate external data before using it.
Keep the calculator usable even when the network is unstable.

For a travel tool, that fallback behavior is not a bonus feature. It is part of the product.

4. PWA-style caching

The project uses a service worker under the travel section. The service worker pre-caches the main travel pages, selected country pages, icons, and an offline page.

For HTML navigation requests, the service worker uses a network-first strategy:

if (
  event.request.mode === 'navigate' ||
  event.request.headers.get('accept')?.includes('text/html')
) {
  event.respondWith(networkFirst(event.request));
  return;
}

For static assets, it uses cache-first:

event.respondWith(cacheFirst(event.request));

This split is useful:

HTML should be fresh when possible.
CSS, JavaScript, and icons can be served quickly from cache.
If navigation fails, the cached page or offline page can still respond.

I also excluded API endpoints and external worker URLs from the cache list. Exchange rate data should not be silently frozen by a static asset cache.

5. DOM caching for repeated updates

The calculator updates the UI frequently when users type, switch currencies, or add target currencies.

Instead of querying the same DOM nodes repeatedly, I initialize a small DOM reference object on page load:

DOM.amountValue = document.getElementById('amount-value-input');
DOM.symbolInput = document.getElementById('symbol-input');
DOM.amountKorean = document.getElementById('amount-korean-input');
DOM.fromCurrency = document.getElementById('from-currency');
DOM.operationDisplay = document.getElementById('operation-display');
DOM.conversionResults = document.getElementById('conversion-results');

This is not a complex optimization. It is just a practical one. Calculator interfaces are input-heavy, so small repeated operations add up.

6. What I would improve next

The current version works as a fast static calculator, but there are still improvements I would like to make:

separate the country preset data from the calculator runtime
generate country pages from a single source of truth
add better test coverage for URL preset detection
improve stale-rate messaging when the app is offline
make the install prompt more consistent across iOS and Android

Final thoughts

The biggest lesson from this project was that a "simple calculator" is rarely just a formula. The formula is the easy part. The difficult part is designing the surrounding behavior: loading, fallback, routing, caching, and the first state the user sees.

That is where a small static tool starts to feel like a real product.

You can try the calculator yourself at sudanghelp.co.kr/travel/exchange/.

Building a 49-Country Exchange Calculator with a Single Static Page

임세환 — Tue, 13 Jan 2026 03:42:16 +0000

When I started building a travel exchange calculator, I ran into a familiar problem.

People don't search for "exchange calculator."

They search for "Vietnam currency to KRW", "Japan yen to won", "Thailand baht rate", and so on.

Each country has its own search intent, but building a separate HTML page for every country quickly turns into a maintenance nightmare.

So I asked myself a simple question:

Can one static page behave like dozens of localized landing pages?

The Idea: Let the URL Do the Work

Instead of creating 49 different HTML files, I used the URL path as a preset key.

/travel/exchange-calculator/vietnam/
/travel/exchange-calculator/japan/
/travel/exchange-calculator/thailand/

The last segment of the URL is read by JavaScript, matched against a preset table, and used to automatically initialize the calculator with the right currencies.

Same HTML.

Same JavaScript.

Different user experience depending on the URL.

Why This Works So Well

This pattern has a few big advantages:

No build system — just plain files
No duplicated HTML — one source of truth
One codebase to maintain — fix once, deploy everywhere
SEO-friendly URLs — every country gets its own indexable path

From the user's point of view, it feels like a country-specific calculator.

From the developer's point of view, it's still just one static page.

How the Routing Works

At page load, the script extracts the last segment from location.pathname and checks it against a simple preset map:

const presets = {
  vietnam:   { from: 'VND', to: 'KRW' },
  japan:     { from: 'JPY', to: 'KRW' },
  thailand:  { from: 'THB', to: 'KRW' },
  usa:       { from: 'USD', to: 'KRW' },
  // ... 45 more countries
};

const segment = location.pathname.split('/').filter(Boolean).pop();
const config = presets[segment] || { from: 'USD', to: 'KRW' };

initCalculator(config.from, config.to);

If there's a match, the calculator initializes with those currencies.

If not, it falls back to a sensible default (USD → KRW).

That's it. No server logic, no framework routing, no URL rewrites.

Why I Built It This Way

I'm building Sudanghelp — a real-world finance calculator platform focused on practical tools people actually use, from government benefits and military pay to travel expenses and currency exchange.

This exchange calculator is one piece of that ecosystem.

👉 Live demo: sudanghelp.co.kr/travel/exchange-calculator/

When This Pattern Makes Sense

This approach works especially well when:

You're on a static host (GitHub Pages, Netlify, Cloudflare Pages)
You want SEO-friendly URLs for many variations of the same tool
You don't need a heavy framework just to handle routing
Your "variations" are really just different initial states

It's basically turning your URL structure into a lightweight configuration API.

Final Thoughts

Frameworks are great, but for many real-world tools, plain HTML + JavaScript + smart URLs go a long way.

Sometimes the simplest solution is the most maintainable one.

If you're building similar tools or curious about the platform behind this, check out Sudanghelp.

What patterns do you use to handle multiple landing pages without duplicating code? I'd love to hear other approaches in the comments.