Your calculator should work with JavaScript switched off

Open almost any Indian finance calculator with JavaScript disabled and you get an empty box. Sometimes a spinner that never resolves. The page has loaded; the thing you came for has not.

That is a strange way for a tool to fail when its entire job is one arithmetic operation.

Who this actually breaks

Not developers who switch JavaScript off for sport. The people who hit this are:

• Anyone on a slow or intermittent connection, where the HTML arrives and the script bundle times out
• Office, college and institutional browsers with locked-down policies
• Low-end Android devices, where a heavy bundle is slow enough to feel broken
• Every crawler, preview bot and link unfurler that does not execute JavaScript

The last one has a consequence people underrate. A page whose content only exists after JavaScript runs is a page that search engines see empty on first pass. Rendering happens later, on a lower-priority queue, if it happens promptly at all. You have not just inconvenienced a reader on a train — you have handed the crawler a blank page and hoped it comes back.

What we do instead

Every calculator on EMICalcs is rendered on the server at build time. The default result is computed during the build and written into the HTML as text. JavaScript then takes over for interactivity — moving a slider, changing a tenure — but it is an enhancement, not a prerequisite.

You can check this without taking my word for it. Fetch the page with something that cannot run scripts at all:

curl -s https://emicalcs.com/sip-calculator/ | grep emiOut

and the answer is already sitting there:

<div class="emi-huge" id="emiOut">₹23,23,391</div>

That is the maturity value for the default scenario — ₹10,000 a month for ten years — present in the markup before a single line of JavaScript executes. Do the same on the income tax calculator and you will find ₹97,500 already computed for its default case.

The cost of doing it this way

It is not free. The build has to run every calculator's engine to produce those defaults, which means the engine cannot depend on anything only a browser has — no window object, no DOM, no reading values out of input elements. The calculation has to be a pure function of its inputs, callable from Node during the build and from the browser afterwards.

That constraint turned out to be the useful part. Because the engine is a pure function it can be called directly from a test — which is how 159 automated math tests came to exist, and how every figure in these posts gets checked before it is published.

The same property is why results are shareable: the whole input state lives in the URL, so the server can render your exact scenario for whoever opens your link.

A reasonable objection

"Nobody browses with JavaScript off in 2026." Largely true, and beside the point. The question is not whether people deliberately disable it — it is what your page does in the seconds before the bundle arrives, or when it never does, or when the visitor is a machine. Server-rendering answers all three the same way: the number is already there.

All 44 calculators work like this, they are free, and none of them ask you to sign in first. Try one with the network throttled and watch what shows up before the JavaScript does.