Construí 17 calculadoras sin una sola dependencia de JavaScript en el cliente

In recent months, the author began building Utiligo, a collection of Spanish-language calculators: overtime, VAT, gratuity, loans, BMI. The technical premise was straightforward and the author took it seriously: zero JavaScript dependencies in the browser. No React, no UI frameworks, no graphics libraries. None at all. That's what the author learned while building it.

Why zero dependencies? Most of these tools perform arithmetic: counting hours, applying a percentage, dividing a salary by 30. Sending 40 KB of framework to the browser to calculate salary / 30 / 8 is disproportionate, especially in Latin America where the author's audience resides. The stack became: Astro in output: static mode, which generates pure HTML, inline script with all the usual JavaScript for interactivity, and Cloudflare Pages to serve it.

The result is pages that function before any content has loaded. The downside of this decision is that the graphics must be drawn by hand. The pie chart of the monthly budget is SVG generated with trigonometry: `var end = start + pct * 2 * Math.PI; var x1 = cx + r * Math.cos(start); var y1 = cy + r * Math.sin(start); var x2 = cx + r * Math.cos(end); var y2 = cy + r * Math.sin(end); var large = pct < 0.5 ?

1 : 0; svg += "<path d=" + "M" + cx + "," + cy + "L" + x1 + "," + y1 + "A" + r + "," + r + "0" + large + "1 " + x2 + "," + y2 + "Z />"`; With a library, it would take three lines. Here, there are thirty, and each must understand the elliptical arc of SVG. Is it worth it? For a graphic, yes. For an entire dashboard, probably not.

There is no reactivity. Every `oninput` updates the DOM manually. It works well with ten fields; with a hundred, it would be unsustainable. The QR code generator had to be written from scratch, including Reed-Solomon encoding. It was the most educational but least recommended weekend of the project.

The most important lesson came from a bug in the overtime calculator: `var amount = hourlyRate * hours * (rate / 100);` For Colombia, `rate` was 125 — overtime is paid at 125% of the regular rate. Correct. For Mexico, it was 100. And there the problem was: article 67 of Colombia's Federal Labor Law states that overtime is paid at 100% more than the regular salary, or 200%.

The author had coded the surcharge (100%) in a field that the calculation interpreted as total. The calculator had been paying simple overtime correctly, not double. Exactly half. The same issue existed in El Salvador. The author discovered it by auditing each country against the legal text, not by reading the code. The code was consistent with itself; what was wrong was the translation of the domain.

No unit tests were written to catch this, as they would have affirmed the wrong value. The author learned that when software encodes real-world rules — labor laws, tax rates, regulations — code correctness and data correctness are two distinct problems, and the latter is more difficult. In this audit, the author also found that Colombia's night shift starts at 7 p.m. from December 2025 (unlike 9 p.m., valid until the reform), Peru has no legal overtime limit since 2002 (the article fixing it was repealed, but most internet still cites it), and El Salvador's maximum of 3 daily hours of overtime simply does not exist in its Labor Code.

The practical conclusion: if a product depends on normative data, the source must be the legal text, with a verification date. Secondary sources copy each other and carry errors for years. If you want to see it, Utiligo.app is free and requires no registration. Calculators with legal implications (overtime, gratuity) cite the relevant norm, precisely for this reason.