Intranet terminals are locked to old browsers and pages go blank—should we change the code or ask the client to replace the machines?

In most cases, you do not need to build a separate frontend for this one client. Based on common delivery experience in 2026, blank screens in old browsers mostly fall in the syntax layer and API layer. Lowering the build target and adding on-demand polyfills usually gets the main flow running. Only when blockers are concentrated in layout and component interactions is it worth discussing a separate low-spec version. Whether to invest depends on three things: what share of terminals are affected, whether they carry business actions that must be completed, and whether the client can provide a real terminal that can reproduce the issue.

Which layer is the blank screen stuck at?

Blank screens in old browsers should be handled by layer. Discussing them all together is the easiest way to cause rework.

• Syntax layer: optional chaining, nullish coalescing, class static fields, top-level await, and ES module syntax appear in the build output. The old kernel throws a SyntaxError during parsing, the whole script bundle does not execute, and the result is a completely blank page.
• API layer: the syntax passes, but the page uses Promise.allSettled, Array.prototype.flat, fetch, IntersectionObserver, and similar APIs, causing runtime errors. The page skeleton is there, but the content does not appear.
• Rendering layer: the script runs normally, but flex gap, grid, and CSS variables are unsupported. This shows up as layout misalignment or popups flying off screen, not as a blank screen.

The diagnosis order should be fixed: open the page in the target kernel and check the first console error. Syntax errors point to build configuration; missing methods point to APIs; visual breakage points back to styles. Skipping this step and changing code directly makes rework much more likely.

What is the difference in scope and cost among the four paths?

The same statement, 'we need compatibility with old browsers,' can lead to very different scopes. The timelines below are experience ranges and vary with page count and terminal distribution.

• Path A: lower the build target + on-demand polyfills at the entry. Changes are concentrated in build configuration and the entry. Typical range is 3 days to 3 weeks. The cost is larger build output and slightly slower execution on new terminals.
• Path B: fallback page + upgrade prompt. Only capability detection is added; unsupported environments go to a static prompt page. Typical range is 1 to 3 days. Suitable when old terminals are a low share and are not on the core path.
• Path C: separate low-spec version. Separate routes or templates that keep only the core flow. Typical range is 3 weeks to 2 months. Long term, this means double regression testing and double release checks.
• Path D: push for terminal replacement or browser upgrade. No code changes; the timeline depends on communication. Suitable when there are few terminals and the client can be pushed in person.

A and B are not in conflict. Many projects use A for the main flow and B for a few old kernels that truly cannot run. Shipping B first and then adding A makes it less likely that compatibility issues hold up the release schedule.

Delivery scene: how to schedule when the budget covers only one regression round

A fairly typical constraint is this: the client has over two hundred intranet terminals, some of which use embedded browsers shipped with the equipment; neither the operating system nor the browser can be upgraded by the user; page assets are provided by the client and cannot be changed; the delivery window is three weeks; and the budget covers only one full regression round.

The approach is to narrow the scope to 'main flow usable' rather than pursuing site-wide visual consistency: lower the build target to the syntax level supported by that kernel; import polyfills on demand once at the entry; change pages that rely on grid and gap to margin-based layout; use static images as fallback for the remaining two complex chart pages and state this clearly on the page. When there are dozens of pages, this level of change typically takes three to ten days, and chart-page fallback takes about half a day to one day per page.

The result is that the main flow runs, two chart pages are degraded, and regression takes about four extra days, with the schedule delayed slightly overall. Writing the cost into the delivery document and fallback checklist in advance is much easier than explaining it on acceptance day.

Acceptance criteria and two common misjudgments

• On the target kernel, all key paths in the main flow (login, list, form submission, file upload, payment redirect, etc., typically 8 to 12 items) can be completed, with no blank screens and no blocking errors.
• No syntax-level errors appear in the console. Any remaining runtime warnings must have a checklist; a single line saying 'known issue' is not enough.
• There is a written fallback checklist that states item by item which features are unavailable on that kernel and what the alternatives are.
• Record the terminal baseline version, and use that baseline for regression on every later release instead of relying on memory or verbal handover.

Misjudgment one: changing the UA to an old version only in developer tools and treating that as verified. Changing UA only affects server-side detection and a small amount of styling; the browser JS engine does not change, so syntax-level failures cannot be reproduced at all. You must test on a real kernel or a real device with the corresponding version. Misjudgment two: only running a homepage screenshot. Old kernels usually fail on interaction paths such as detail pages, upload, and payment, so you need to walk through the main flow item by item. When the conclusion is uncertain, writing 'not verified' is safer than signing off based on speculation.

When to invest and when not to

The boundary is relatively clear: if terminals are centrally managed by the client, cannot be upgraded by users, and carry business actions that must be completed, compatibility is a hard requirement within delivery scope. Conversely, for public internet products where users can upgrade their own browsers, old terminals are only a small share, and those terminals are not on the core path, a fallback page prompting upgrade is usually enough, and the whole project does not need to be changed.

• Worth investing: intranet office systems, embedded browsers in industry equipment, government or medical terminals, and private deployment projects where the client issues machines centrally.
• Not necessary: public internet products with scattered but upgradeable terminal versions, very low old-terminal traffic share, and compatibility pages that are only informational display.
• Ask clearly in advance: whether the client can provide a real terminal or a reproducible kernel version. This directly determines whether later testing is accurate or whether you can only guess and change.

Frequently asked questions

If we only add polyfills and do not change the build target, will old browsers still show a blank screen?

Yes. Polyfills fill in runtime APIs, but they cannot fill in new syntax that the browser cannot understand. If optional chaining or ES module syntax appears in the build output, the script will still fail as a whole during parsing.

If the client says terminals cannot upgrade their browsers, do we have to rewrite a separate frontend?

Usually not. First count whether blockers fall in the syntax, API, or layout layer. The first two layers can be covered by build configuration and on-demand polyfills. Only when layout and component incompatibilities are extensive is a separate low-spec version worth considering.

What share of old intranet terminals makes dedicated compatibility work worthwhile?

There is no universal threshold. Based on common delivery experience in 2026, when old terminals carry core flows and reach about 10% to 20% or more, Path A is generally cost-effective. When the share is very low and those terminals are not on the core path, a fallback page is more suitable.

Do we have to maintain compatibility forever after it is done?

You do not need to carry it long term. You can agree on a supported kernel baseline in the contract or delivery document, evaluate terminal distribution once a year, and when the share falls very low, send an end-of-support notice in advance and then stop regression.

If you have a project like this at hand, do one thing first: run the main flow on a real target terminal, record the first console error, and then decide which path to invest in. In private deployment projects, Xiyue Company usually schedules with a test-first, change-later sequence. One boundary to keep in mind: once the terminal baseline is set, write it into the documentation. Compatibility work without a baseline can easily be overturned in the next release.