Build the content, navigation and contact details in the page itself, and use scripts to improve what is already there. Then a script failure degrades the experience instead of removing the site.

Nobody turns JavaScript off

Worth conceding immediately, because the usual framing of this argument is wrong and gets dismissed for good reason.

Almost nobody deliberately disables scripts, and designing for that person is not a sensible use of anybody's time.

The reason to care is different: scripts fail for ordinary people, temporarily, for reasons that have nothing to do with preference.

A file times out on a poor connection. A content network has an outage. A corporate firewall blocks an external domain. An older phone runs out of memory. A browser extension interferes.

Each is brief and each produces the same result: a visitor arrives and the page does not work.

What a failure looks like

It depends entirely on how the site was built, and the difference is stark.

On a site where the content is in the page and scripts improve it, a failure means the menu does not slide, the gallery does not fade, and everything is still readable and usable.

On a site where scripts build the content, a failure means a blank white screen.

Same fault, same visitor, and one of them can still find your phone number.

The order that matters

The principle is old and it survives because it works.

Put the content in the page as ordinary markup. Style it. Then add scripts that enhance what is already present.

The alternative, common in modern tooling, is to send a nearly empty page and have scripts assemble it in the browser.

For a web application with users who log in, that is a legitimate trade with real benefits.

For a brochure site with fourteen pages of text, photographs and a contact form, it is a considerable amount of fragility bought for very little.

What should never depend on a script

These are the things somebody came for. If any of them requires code to run before it exists, a temporary failure removes the reason your site is there.

Menus are the usual offender

The most common single failure on otherwise sensible small business sites.

A mobile menu built so that the links only exist once a script has run, or a menu button that does nothing without one.

The page loads, the text is fine, and there is no way to reach any other page.

The remedy is that the links should be real links in the page, present whether or not anything runs. A script can then collapse them into a tidy menu, and if it fails the visitor sees a plain list of links, which is inelegant and entirely usable.

Forms that need scripts to submit

The second common failure and the more expensive one.

Where a form is intercepted by a script and sent in the background, a script failure means the submit button does nothing, or worse, appears to succeed while sending nothing.

A form should have a real destination and submit normally on its own. Scripts can then improve it: validating as somebody types, submitting without a page reload, showing a friendlier confirmation.

When those enhancements fail, the form still posts and the enquiry still arrives, which is the outcome that matters.

A worked example

A professional practice had a site built with a page builder, where the navigation and the contact details were both assembled by scripts.

An external script provider had a partial outage lasting about forty minutes on a weekday morning.

During that window the site loaded to a mostly blank page with a logo. No navigation, no phone number, no form.

Nobody noticed until a client mentioned it two days later, since it had resolved on its own and left no trace.

Rebuilding the header so the phone number and navigation were plain markup took a developer a couple of hours.

The next comparable outage, some months later, produced a site with an unstyled menu and a visible phone number, which nobody reported because nobody was prevented from doing anything.

Testing it

Two minutes, and it is genuinely alarming the first time.

Open your browser's developer tools, find the setting to disable JavaScript, and reload your homepage.

Then check the short list above: is the phone number visible, does the navigation work, is the body text there, does the form have a real destination.

Repeat on a service page and the contact page.

You are not aiming for a perfect page. You are checking that a visitor could still find you and get in touch, which is a much lower bar and one a surprising number of sites fail.

Search engines and the same question

A related benefit, and one that has become less severe than it was.

Search engines do run scripts now, so content assembled in the browser is generally seen, and this is no longer the emergency it once was.

It does happen later and less reliably than reading content that is already in the page, and anything that fails to run for a crawler is content that does not exist as far as it is concerned.

Content in the page is read immediately and without conditions, which is one fewer thing that can go wrong in a process where a good deal already can.

The counter-case

This is not an argument against JavaScript, and applying it rigidly to everything would be foolish.

Genuine applications, where somebody logs in and manipulates data, are built with scripts for good reasons, and demanding they work without is asking for a worse product.

Some features simply cannot exist without scripts: interactive calculators, live availability, anything drag and drop. Nobody should build those twice.

The distinction is between a feature that needs scripts and a brochure page that needs them by accident. A calculator failing without JavaScript is expected. A phone number failing is not, and it is usually the same underlying tooling that caused both.

The check

  1. Disable JavaScript in your developer tools.
  2. Reload the homepage and look for the phone number.
  3. Try the navigation and confirm the links work.
  4. Check body text is present on a service page.
  5. Confirm the form has a real destination.
  6. Fix the header first if anything is missing.

The header and the form are where nearly all of the value is, and both are usually a contained piece of work rather than a rebuild.

Depending on technology that stops working is covered in Flash ends this month and something will break.


Frequently asked questions

Does anybody actually browse without JavaScript?

Almost nobody by choice. The reason to care is that scripts fail temporarily for ordinary people: timeouts on poor connections, provider outages, corporate firewalls, and older phones running out of memory.

What should work without scripts?

Your phone number and address, the main navigation as real links, body text, important images, the contact form, and opening hours. Those are what people came for.

Why do mobile menus break?

Because the links often only exist once a script has run. Make them real links in the page and let a script collapse them into a menu, so a failure leaves a plain usable list.

What about contact forms?

A form should have a real destination and submit normally on its own. Scripts can then improve it. If they fail, the enquiry still arrives, which is what matters.

How do I test this?

Disable JavaScript in your browser's developer tools and reload. Check the phone number is visible, navigation works, text is present, and the form has a destination.

Is this an argument against JavaScript?

No. Applications where people log in and manipulate data need it, and interactive features cannot exist without it. The problem is a brochure page depending on scripts by accident.

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.

Two-minute test?

Disable JavaScript, reload your homepage, and see whether your phone number is still there.

Start a Conversation