The Smart Calc

How to handle financial arithmetic without floating-point errors in JavaScript

Replaced native JavaScript Number arithmetic with the decimal.js library across all 12 calculator modules. Every intermediate value in a multi-step calculation (e.g. monthly rate derivation inside loan amortization) is kept as a Decimal instance and only converted to a primitive string for display.

Adds a dependency and slightly more verbose code, but eliminates the class of bugs where 0.1 + 0.2 === 0.30000000000000004 — critical for a platform where users trust the numbers.

How to serve bilingual content without a third-party translation API at runtime

Stored all UI strings and calculator labels in flat JSON message files per locale (en.json, ar.json) loaded at build time. Next.js middleware maps each incoming request to the correct locale and the message file is imported statically in Server Components.

Translations must be maintained manually in the JSON files — there is no auto-sync with a translation platform — but page load has zero network round-trip overhead for i18n.

How to monetize a free calculator platform without degrading performance

Google AdSense ad units are loaded lazily via a dynamic import behind an IntersectionObserver. The ad script is deferred until the ad slot enters the viewport, so it never blocks the main thread during initial page load.

Ads appear slightly later than on platforms that load them eagerly, but Core Web Vitals scores (LCP, CLS) are not impacted by ad loading weight.

Loan amortization schedules for long tenures (30-year mortgages) were generating tables with 360 rows, causing noticeable render lag on low-end devices.

Implemented virtual pagination on the amortization table: only the first 12 rows are rendered on mount, with a 'Load more' button that appends the next 12 rows. The full schedule is computed once and held in a ref, so pagination is pure DOM addition with no recomputation.

Initial render time dropped from ~400ms to under 50ms for a 30-year schedule while keeping the full data available without a round-trip.

RTL layout required more than a CSS direction flip — form inputs, number formatting, and error message alignment all had to adapt to Arabic reading order.

Created a useLocale hook that exposes the current locale and a dir value. Components that need direction-aware styles consume dir and apply conditional class names. Number formatting uses Intl.NumberFormat with the locale string so Arabic numerals render correctly in ar locale.

The Arabic version of the site is a full RTL experience — inputs, labels, error states, and number outputs all respect Arabic reading order without any hardcoded LTR overrides.