How Should a Website Gadget Behave When JavaScript, Internet Connectivity, or External Services Fail?

 

A website gadget should be designed to work well not only when everything goes perfectly, but also when something goes wrong.

A visitor may have JavaScript disabled. Their internet connection may be extremely slow. Their phone may temporarily lose connectivity. An external API may be unavailable. A third-party service may time out. A database may temporarily fail. A browser extension may interfere with scripts. A network request may simply take too long.

These situations are normal possibilities on the web.

A poorly designed gadget may respond to such situations by displaying a blank space, endlessly spinning loader, broken layout, raw error message or completely unusable interface.

A well-designed gadget should instead fail gracefully.

That means the visitor should understand what is happening, retain access to whatever functionality remains available, and receive a useful alternative whenever one exists.

The Gadget Should Be Designed for Failure From the Beginning

Failure handling should not be something added after the gadget has already been built.

Before writing the code, identify the major states the gadget can experience:

Loading

Successful

Empty

Slow

Offline

External service unavailable

JavaScript unavailable

Permission denied

Rate limited

Invalid data

Server error

Recovered

Each state should have an intentional user experience.

This produces a much more reliable gadget than building only the "everything works" scenario.

What Happens When JavaScript Is Disabled?

Many modern gadgets depend heavily on JavaScript.

JavaScript may control:

• Search

• Filtering

• Animations

• Real-time updates

• API requests

• Calculations

• Interactive cards

• Popups

• Tracking

• Dynamic content

• Form validation

If JavaScript is disabled, those functions may not work.

However, that does not necessarily mean the entire gadget should become useless.

The gadget should provide a fallback experience wherever practical.

For example, instead of showing an empty container, it could display:

This interactive feature requires JavaScript. Please enable JavaScript in your browser to use search and filtering.

That is significantly better than presenting a blank box.

Important Information Should Not Disappear Completely

Suppose a gadget displays property listings.

If JavaScript is unavailable, it may not be possible to provide interactive filtering.

But basic property information could potentially still be rendered as HTML:

3-Bedroom House

Location: Utawala

Price: KES 22,000,000

Contact

This means the visitor can still access important information even though advanced interaction is unavailable.

This principle is sometimes described as progressive enhancement.

The basic content works first.

JavaScript then adds advanced functionality.

Progressive Enhancement Is Particularly Valuable

A robust gadget can have several layers.

Basic Layer

HTML provides:

• Text

• Links

• Images

• Basic information

• Essential forms

Styling Layer

CSS improves:

• Layout

• Typography

• Spacing

• Colors

• Responsive design

Interactive Layer

JavaScript adds:

• Search

• Filtering

• Animations

• Real-time updates

• Dynamic content

• Advanced interactions

If JavaScript fails, the basic information can still remain accessible.

This is much more resilient than making the entire gadget dependent on JavaScript from the first millisecond.

Not Every Gadget Can Fully Work Without JavaScript

Some applications genuinely require JavaScript.

For example:

• Complex real-time dashboards

• Interactive calculators

• Advanced music players

• Drag-and-drop systems

• Highly dynamic applications

• Live collaborative tools

In these cases, a complete non-JavaScript equivalent may not be practical.

The goal is therefore not to pretend that every feature can work without JavaScript.

The goal is to provide the most useful fallback possible.

For example:

This live dashboard requires JavaScript. You can still view the latest saved report here.

That is much more useful than:

Error.

Slow Internet Requires Different Treatment

A slow connection is not the same as a failed connection.

A visitor may eventually receive the information, but it may take 10, 20 or 30 seconds.

The gadget should therefore distinguish between:

Loading normally

and:

Taking longer than expected

Instead of displaying an endless spinner, it could eventually communicate:

This is taking longer than expected. Please wait or try again.

This gives the visitor feedback rather than leaving them wondering whether the gadget is broken.

Don't Make the Visitor Wait for Everything

A slow connection makes it especially important to prioritize content.

Suppose a gadget requires:

• Product information

• Five large images

• Analytics

• Social statistics

• Reviews

• External advertising

• Recommendations

• Real-time activity

The visitor may not need all of those things before they can begin using the gadget.

Load essential information first.

Then load secondary information progressively.

For example:

First: Product name + price + main action

Then: Image

Then: Reviews

Then: Recommendations

Then: Secondary statistics

This is known as progressive loading and can substantially improve perceived performance.

Show Something Useful While Content Loads

A blank white box is poor feedback.

A gadget can instead display:

Loading products...

or use an appropriate skeleton layout.

The visitor immediately understands that the system is working.

However, the loading state should not continue indefinitely.

Use Timeouts

Every external request should have a reasonable timeout.

Imagine a gadget requesting information from an external service.

If the service never responds, the browser should not wait forever.

Eventually the gadget should stop waiting and move into an appropriate failure state.

For example:

Live information is temporarily unavailable.

Then provide:

[TRY AGAIN]

if retrying makes sense.

Automatic Retry Should Be Controlled

Temporary failures sometimes resolve themselves.

A gadget can attempt a controlled retry.

For example:

First attempt → fails

Retry → after a short delay

Second attempt → fails

Retry → after a longer delay

If the service continues failing, stop retrying aggressively.

Constantly sending requests to an unavailable service only increases the problem.

This is where retry backoff becomes useful.

The delay between attempts can increase after repeated failures.

Don't Expose Technical Error Messages to Visitors

A visitor generally does not need to see:

HTTP 502 Bad Gateway

or:

ECONNRESET

or:

JSON.parse failed at line 1

These messages may be useful to developers but are rarely useful to ordinary visitors.

The gadget should show a human-readable message such as:

We couldn't load this information right now. Please try again.

The detailed technical error can be recorded internally for administrators.

The Administrator Should See More Than the Visitor

This distinction is important.

Visitor sees:

Live statistics are temporarily unavailable.

Administrator dashboard sees:

External API timeout
Provider: Example API
Endpoint: statistics
First failure: 10:32:14
Last failure: 10:35:41
Failure count: 37
Average response time before failure: 4.8 seconds

The visitor needs clarity.

The administrator needs diagnostics.

These should be separate experiences.

External Services Should Never Be Allowed to Destroy the Entire Gadget

Suppose a gadget displays a business profile.

It retrieves:

• Business information from your database

• Weather from an external API

• Social media statistics from another service

• Maps from a mapping provider

If the weather service fails, there is no reason to hide the business information.

The gadget should continue displaying what is available.

For example:

Business Name

Phone

Address

Opening Hours

[CONTACT]

Then:

Weather information temporarily unavailable.

This is much better than:

Gadget failed to load.

Separate Critical and Non-Critical Services

A useful architectural approach is to classify dependencies.

Critical

Without this service, the main gadget cannot perform its primary function.

Important

The gadget remains useful, but some functionality is reduced.

Optional

The visitor can continue normally without it.

For example, in a property gadget:

Property database: critical

Map: important

Weather: optional

Social statistics: optional

If the weather API fails, the property search should continue.

Use Fallback Data Carefully

Caching can provide a useful fallback when an external service is temporarily unavailable.

For example, if a business-information API fails, the gadget may display information successfully retrieved five minutes earlier.

But it must be clear that the information may not be current.

For example:

Showing information last updated 5 minutes ago.

This is much better than presenting stale information as if it were live.

Some Information Should Never Be Treated as Fresh When It Is Not

Certain systems require particular caution.

Examples include:

• Payment status

• Product stock

• Property availability

• Booking availability

• Financial