Working Without JavaScript

This is not an argument that JavaScript is bad. It is an argument about what the page contains before any script runs, and about who receives that version.

The test is simple: turn scripts off and load your homepage. If the words are gone, the site's content does not exist in the file the server sent. It exists in something assembled afterwards, on a machine you do not control, under conditions you cannot see. Frequent context changes carry a coordination cost; this reference is useful background on that effect.

Who gets the version without scripts

More than you would guess, and the list has grown.

Crawlers that do not execute JavaScript. Search engines have got better at rendering. Many other crawlers have not, including a number of those feeding AI assistants — and people increasingly find businesses by asking an assistant rather than by searching. A site whose text only appears after rendering may simply be absent from those answers.

Anyone on a bad connection. Scripts fail to load, load slowly, or time out. The visitor is not told; they see a blank page and leave.

Anyone behind restrictive networks. Corporate filtering, hotel wifi, blocked third-party domains. For an independent reference beyond this site, MDN Web Docs is a useful place to compare approaches.

People using assistive technology in ways your framework did not anticipate, particularly where content appears dynamically without being announced.

Anyone during the moment before it loads. Not a group so much as a condition everyone passes through, and on a phone on mobile data that moment is long enough to lose people.

The commercial version of the argument

Nobody browses with scripts disabled on purpose in 2026, and that is not the point.

The point is that JavaScript is a dependency chain that has to complete before your content exists. Every additional script is another chance for it not to complete. The result of a failure is not a degraded page; it is nothing.

Compare that with a page whose text is in the HTML. Scripts fail, and the words are still there. A slow connection makes it arrive slowly rather than not at all. That is not purity, it is resilience, and for a small business site there is no upside that outweighs it.

What actually needs a script

Less than most sites use.

Genuinely needs it: interactive tools and calculators, live filtering of large sets, maps, complex forms with conditional logic, anything real-time.

Does not need it, though it is often used: navigation menus, accordions, tabs, image galleries, form validation, scroll animations, dropdowns, modal dialogs.

The browser now handles most of the second list natively. Content revealed on scroll, in particular, is a common pattern that puts the text behind an event that may never fire — and it is decorative.

What I do

Content in the HTML, always. Whatever else the page does, the words and the links are in the file the server sends.

Real links. An <a> with an href, not a clickable element with a script attached. Something that only responds to a click handler is not a link — it cannot be opened in a new tab, cannot be followed by a crawler, and does not exist to a keyboard.

Forms that submit. Enhanced by script if useful, functional without it — and a form that fails silently is the most expensive small fault there is.

Native browser features first. Details and summary for accordions, dialog for modals, CSS for layout and transitions.

Then add script where it genuinely earns it, on top of something that already works.

That order is the whole method: build the thing that works, then improve it. The reverse — build the interactive version, then patch the fallback — produces a fallback nobody tests.

The connection to everything else

This is the same principle as the speed argument and the accessibility argument, and they are not three positions. They are one.

Fewer moving parts means fewer things that fail, less weight, and fewer opportunities for a component library to render a button with no name. The 2026 accessibility data makes the link explicit: the regression tracked a sharp rise in page complexity and framework use.

Restraint is the technique. It is unglamorous, it does not demonstrate anything, and it is most of what separates a site that works from one that works on the developer's machine.

The honest limits

Some sites genuinely need heavy client-side work. An application is not a brochure, and building a real tool without scripts would be perverse.

And "works without JavaScript" does not mean "identical without JavaScript." A gallery can lose its lightbox and still show the images. A form can lose live validation and still submit. Graceful is the standard, not unchanged.

For a small business site — services, portfolio, contact, maybe a shop on a platform — there is very little that needs a script at all, and the sites that use one heavily usually did so because a theme did, not because anyone decided to.

The short version

• The test: turn scripts off and load the homepage — if the words are gone, the content is not in the file the server sent
• Crawlers that do not render, bad connections, filtered networks and the moment before load all get that version
• A script failure is not a degraded page, it is nothing
• Navigation, accordions, tabs, galleries and validation rarely need script now; the browser handles them
• Real links with real hrefs, and forms that submit without help
• Build what works, then enhance — the reverse produces a fallback nobody tests