Modern frontend development defaults to building the entire experience in JavaScript, which works well for the visitor whose connection is stable and whose script loads cleanly, and fails completely for the visitor whose doesn't — a poor mobile connection dropping mid-load, an aggressive corporate firewall stripping scripts, an ad blocker or privacy extension interfering more broadly than intended. For that visitor, a JavaScript-dependent site isn't degraded, it's blank.
Progressive enhancement is the older discipline of building the core experience to work with plain HTML first, then layering JavaScript on top to improve it — rather than building the JavaScript-dependent version first and treating anything else as an edge case not worth handling. A form that submits via a plain HTML request and works without JavaScript, then gets enhanced with client-side validation and a smoother submission experience when JavaScript is available, degrades gracefully instead of failing completely for the visitor without it.
This isn't an argument against building rich, JavaScript-driven interfaces — it's an argument about what the baseline is. The core, essential functionality — can someone read the content, can someone complete the primary action the page exists for — should not depend on JavaScript loading successfully. Everything beyond that core, the interactivity and polish that makes an experience genuinely good, can reasonably depend on it.
The Indian context makes this more relevant than it might first appear, given the connectivity variability covered in the piece on building for low-bandwidth users. A visitor on an intermittent mobile connection is precisely the visitor most likely to have a script fail partway through loading, and a site built with progressive enhancement in mind degrades to something still usable for that visitor, while a site that assumes JavaScript loading is a given shows them nothing at all.
