Everything you think needs JavaScript, and what it actually needs
The commonest objection to this specification is that the modern web needs its machinery: you cannot have logins without cookies, shops without scripts, or payments without a third party in the page. This is almost entirely false. The spec bans scripts, cookies, and third-party resources - it does not ban forms, links, or a server that remembers things. Links and form submissions are navigations, not embedded resources: handing a visitor off to another site is always legal; embedding another site in your page never is. Nearly everything below was routine before 1999. It is not impossible; it is merely more work.
Each row shows two grades: the best achievable with conforming mechanisms, and what a competent modern implementation earns - standard tools used carefully, by someone trying to do a good job, with no adtech excess. The second column does not grade the worst implementations, only careful ones.
| You want | The conforming way | The modern way, done well | ||
|---|---|---|---|---|
| A blog, docs, anything that is a document | HTML and CSS. It is a document. | A | A static-site generator whose theme ships a toggle script and a web font | D |
| Search | A GET form. The original use of forms. | A | A first-party JavaScript search index | D |
| Logins and sessions | HTTP Basic Auth over HTTPS, or a session token carried in the URL and rewritten into every link by the server - the 1990s pattern | A | A well-set first-party session cookie, no trackers. The cookie is the major. | D |
| A shopping basket | Server-side cart keyed by the URL token; add-to-cart is a form POST. Cookies were invented for carts in 1994; the pre-cookie pattern works. | A | A cookie cart, tidily done | D |
| Taking payment | Hand off: a link or form-redirect to the processor's hosted page, and a return URL back. Their page is graded on their domain, not yours - and this is less work than embedding. | A | The processor's script and frame embedded in your page, as the integration guide suggests | F |
| “Sign in with Google” | The OAuth redirect flow is pure navigation: out, authenticate, back with a code, and your server does the exchange | A | The provider's JavaScript button widget | F |
| Comments | A form and server-side rendering; honeypot fields or a first-party image CAPTCHA for spam | A | A comments service - even the ethical, open-source, GitHub-backed ones are a third-party script | F |
| Multi-step forms | Hidden fields carry state between round-trips - hidden fields are the cookie-free state channel | A | A client-side wizard, first-party | D |
| File upload | <input type="file">, styled with CSS |
A | A drag-and-drop uploader, first-party | D |
| Analytics | Your server logs. The server already knows every request; counting them requires no visitor's browser to do anything. | A | Self-hosted, cookieless, privacy-respecting analytics - which still costs the script major. (The hosted version is an F.) | D |
| Advertising | Directly sold, first-party-served static images. The spec does not ban advertising; it bans the adtech supply chain. | A | Programmatic adtech. There is no careful version. | F |
| Dark mode | prefers-color-scheme follows the visitor's own setting,
with zero stored state |
A | A scripted toggle persisted to local storage | D |
| Video | Self-hosted <video controls preload="none">. The spec
exempts on-demand media from the weight limit; the file downloads only when
a visitor presses play. |
A | Self-hosted with a first-party player library. (A YouTube embed is an F.) | D |
| Live-ish updates (scores, status boards) | <meta http-equiv="refresh">. Crude, but permitted. |
A | First-party polling | D |
| Newsletter signup | A form POSTing to your own endpoint | A | The provider's embed snippet, script included. Most providers also offer a plain HTML form, which is an A. | D |
| Remembering an anonymous visitor's preferences | This is the one real gap. Without a login or a URL token there is no conforming way to remember a visitor. The same property is what guarantees privacy. | D | A cookie or local storage | D |
| An app: games, editors, maps, anything that computes in the browser | Nothing conforming rescues this; client-side computation is the thing itself. An interactive map is an app, and a static image is not the same thing. Some pages are programs. This spec is for the ones that are documents. | F | The same, with a bundler | F |
A modern build done with care usually lands on D: one major fault, a first-party script or a session cookie, and nobody tracked. The second column only shows F where the standard approach embeds a third party: payment fields, comment services, identity widgets, adtech. The results in the gallery are much worse than this column, and the difference is not technical necessity. Not every site needs an A. But a site that is a document can score an A with almost no sacrifice, a pass takes modest effort, and an F is a choice.
URL-token sessions are usually criticised for leaking via the
Referer header. On a conforming site the classic vector is
structurally absent: tokens leak through third-party requests, and there are
none. A <meta name="referrer" content="no-referrer">
covers outbound link clicks.
Cross-site request forgery is also less of a problem. CSRF works because browsers attach cookies to requests automatically; a token carried in URLs and hidden fields is not attached automatically, so a forged request does not include it.