skip to content

Your team wants every core write to work before any script loads; how do you decide which writes get that guarantee?

level: principalimportance: nice to knowfreq 34%

answer

  1. the window exists on every load
  2. not about users with scripting off
  3. grade by cost of silent failure
  4. the input must fit a form
  5. an untested guarantee decays

basics

~20 s

Grade writes by what a failure in the pre-hydration window costs, not by how many users disable scripting. Guarantee the small number on the revenue and account path, accept the scripted-only path elsewhere, and test the guarantee or it decays.

solid answer

~50 s

The argument for a scriptless submit path is usually made about users with scripting off, an easy objection to dismiss. The stronger argument is that **every** load has a window between first paint and hydration, and on a slow device, a cold cache or a flaky network that window is long enough for someone to submit. So the criterion is cost: which writes, if they silently do nothing during that window, lose money or trust? Those get the guarantee. The price is real — the input has to be expressible as form fields, the outcome has to be renderable as a server response, multi-step flows need server-held state, and interactions built on client-only state cannot qualify at all. Keep the guarantee for that short list, make the plain form shape the default so it comes free where possible, and test it with the enhanced path disabled, because an untested guarantee decays.

go deeper

for a junior

Take away the core fact: there is a period on every page load before the bundle is live, and a plain form submit is the only thing that works during it.

for a middle

Be able to explain what the guarantee constrains — input encodable as fields, outcome renderable as a server response, no dependence on client-only state — rather than treating it as a switch you turn on.

for a senior

Show how you would keep it true: default to the plain shape so most writes qualify, exercise the important ones with the enhanced path disabled, and make controls that cannot work yet look inert.

for a principal

Own the classification and the tradeoff. Grade writes by the cost of silent failure, state plainly which are scripted-only, and be willing to argue that for some products the parallel path is not worth building.

## Reframe the question before answering it "Works without JavaScript" invites an argument about a population nobody can measure well. The sharper framing is **the pre-hydration window**, which every visitor passes through on every cold load: - the HTML is painted and interactive controls are visible; - the bundle is still downloading, parsing, or executing; - a click on a submit control either does the platform's thing, or does nothing at all. On a fast laptop that window is milliseconds and invisible. On a mid-range phone on a congested network it is seconds, and it lands exactly on the users who are most likely to abandon. Add the loads where the bundle never arrives — a failed chunk request, a hostile network, an aggressive proxy, an extension that broke — and the population is not the ideological non-scripting user. It is a slice of everybody. ## What the guarantee costs It is not free, and a principal answer says so plainly: 1. **The input must be encodable as form fields.** Text, choices and files are fine. A canvas selection, a drag-reordered list, a rich text document held in client state are not, without building a parallel representation that the scriptless path submits. 2. **The outcome must be expressible as a server response.** Field errors returned as data, a redirect on success. Anything whose result is "update this part of the screen and leave the rest" needs the full document round trip instead. 3. **Multi-step flows need server-held state.** With no client to accumulate, each step posts and the server keeps the partial record, which means storage, expiry and cleanup. 4. **The testing matrix doubles for those writes.** Two transports, both of which must pass. 5. **Some designs are simply excluded.** If the interaction only exists because script is running, guaranteeing it is incoherent. ## A way to grade the writes | Tier | Examples of shape | Decision | |---|---|---| | Loses money or access if it silently fails | completing a purchase, signing in, changing a password, submitting an application | guarantee it | | Ordinary domain writes with form-shaped input | creating a record, editing fields, posting a comment | get it for free — use the plain form shape and do not fight it | | Enhancement-only interactions | reordering by drag, autosave while typing, inline toggles | do not guarantee; make sure they cannot appear interactive before they work | | Fire-and-forget telemetry | analytics, presence pings | no guarantee, no obligation | The third row carries a duty that is easy to miss: if a control cannot work before hydration, it should not look ready. Rendering it in a disabled state until the page is live is more honest than a control that silently swallows a click. ## Making the policy survive A guarantee nobody exercises stops being true quietly. Three things keep it alive: - **Make the enhanced form the default.** When the ordinary way to write a form already produces a working scriptless submit, most writes qualify without anyone deciding to make them qualify. The guarantee then costs only the cases that fight it. - **Test it where it matters.** A small suite that submits the tier-one writes with the enhanced path disabled and asserts the redirect and the resulting state. This is a handful of tests, not a parallel test estate. - **Name it in review.** "Which tier is this write?" is a one-line question that catches the drift, and it is cheaper than an audit later. ## Argue the other side honestly There is a real position against a blanket rule. Some products are, by their nature, applications that cannot function without script, and forcing every write through a form round trip there produces awkward interactions and a second code path maintained for a case that cannot arise. A sensible lead does not mandate a doctrine; they classify. The failure mode to avoid is the opposite of a policy — nobody has decided, so the checkout happens to work scriptless this quarter and stops working next quarter because a refactor moved the submit into a click handler, and nothing noticed. ## The decision, compressed Guarantee the writes whose silent failure is expensive. Take the free ones by keeping the plain shape as the default. Be explicit that the rest are scripted-only and make them look inert until they are not. Test the short list. Revisit when the shape of the product changes, not when someone quotes a statistic about users with scripting disabled.

  • What should a control do when it cannot work before hydration?
    Not look ready. Render it inert until the page is live, so a click in the window is visibly ignored rather than silently lost. A control that looks identical whether or not it works is worse than one that admits it is not ready yet.
  • How do you keep the guarantee from decaying?
    Make the plain form shape the default so writes qualify by construction, and keep a small suite that exercises the high-cost writes with the enhanced path disabled. Without an executing test, a refactor that moves the submit into a click handler passes review unnoticed.
  • Is there a legitimate case for not offering the guarantee at all?
    Yes. A product whose core interactions only exist because script is running gains nothing from a parallel form path, and maintaining one costs real effort. The requirement is to decide deliberately and write it down, not to adopt a doctrine either way.

saying these in an interview costs you the question

  • Justifies the decision only by the number of users with scripting off
  • Mandates the guarantee for every write without weighing the cost
  • Assumes hydration is instant so the window does not exist
  • Leaves a control looking ready when it cannot work yet
  • Claims the guarantee without any test that exercises it