Could you actually run Lovable through a TLS-downgrading proxy on Windows 98?

You could complete the TCP handshake and possibly load the initial HTML, but the editor would not function. IE 4.01 fails on the first ES2020 module it parses, before any DOM or WebSocket logic runs. The proxy solves the cryptographic layer and exposes the next four failure layers immediately. You would see a blank page or a scripting error dialog, depending on which IE settings are active.

Why does Lovable need WebAssembly when ChatGPT works in older browsers?

ChatGPT renders model output as text in a scrolling div, which is a 1995-era problem. Lovable transpiles and executes generated code inside the browser, using esbuild-wasm or equivalent tooling, so the WebAssembly dependency is real and load-bearing. If WebAssembly is absent, the in-browser build step has no fallback path that performs acceptably. The architecture diverges sharply from a pure chat interface here.

What was Internet Explorer 4.01 actually capable of in 1998?

IE 4.01 supported HTML 3.2, partial CSS 1, JScript roughly aligned with ECMAScript 1, ActiveX controls, and SSL 3.0. It introduced Dynamic HTML and the document.all model, which is non-standard and incompatible with every modern framework. It was, for its time, the most advanced consumer browser shipping. By 2026 standards the API surface it exposes is closer to a document viewer than an application runtime.

Is there any version of Windows 98 setup that could run a modern Chromium fork?

No. Chromium dropped Windows XP support in 2016, and the minimum Windows version has climbed steadily since. The kernel APIs Chromium relies on — modern threading primitives, sandboxing, GPU acceleration paths — do not exist in Windows 98. Community forks targeting older XP-class hardware exist but none target 9x-series Windows. The kernel architecture difference is the blocker, not the browser code itself.

Why does this thought experiment matter if nobody actually tries to do it?

Because the failure cascade is an X-ray of modern web infrastructure. Engineers who only ship on the current stack rarely audit which inherited layers they depend on. Working through which specific protocol, syntax, and API features Lovable cannot operate without is a faster way to understand the 2026 web than reading any architecture overview. The exercise forces an inventory most documentation skips.

Could you build a Lovable-equivalent that runs entirely on Windows 98 hardware?

Not in any honest sense. You could build a 1998-era code generator with templates and regex, but the agent loop that makes Lovable useful depends on calling a remote LLM, which depends on TLS 1.2 or higher, which Windows 98 cannot speak. You could ship a local model — but no quantization of any 2026-grade model fits in 64 MB of RAM with a 233 MHz Pentium II. The hardware ceiling closes the door the protocol ceiling left open.

What modern browser feature is the single biggest dependency for tools like Lovable?

The iframe sandbox with cross-origin isolation headers, combined with a structured Web Worker model and SharedArrayBuffer support. This combination is what allows the editor to safely execute AI-generated code inside the same tab without trusting it. None of these features existed before 2017 in any usable form, and the cross-origin isolation headers were only finalized around 2021. Remove this stack and the security model of in-browser code execution collapses.

Are there serious projects that actually target old-browser compatibility in 2026?

A handful, mostly in archival and accessibility contexts — the Internet Archive's emulation work, certain government portals required to support legacy clients, and niche embedded systems. None of them target generative AI workflows. The economic case for shipping AI tooling to a browser cohort under 0.001% of global traffic does not close. Lovable's product team has, correctly, never spent a sprint on it.

Lovable on Windows 98 Is a Thought Experiment, Not a Build

Somebody on Hacker News floated the idea of traveling back to 1998 and using Lovable on Windows 98, and the comment thread did exactly what you would expect — half the replies treated it as a joke, the other half started sketching emulation layers. Both camps missed the interesting part. Lovable launched in late 2023 as GPT Engineer, rebranded in 2024, and its entire interaction model assumes a browser that ships fetch, ES2020, WebSockets over TLS 1.3, and a JavaScript engine written after the iPhone existed. Windows 98 shipped Internet Explorer 4.01. The gap between those two facts is not a nostalgia problem. It is a protocol problem.

If you are reading this, you already know Lovable runs in a browser, talks to a remote model over HTTPS, and renders a live preview of whatever it just generated. You know Windows 98 came on a CD, not a download. You do not need the explainer paragraph. What you need is somebody to walk through exactly which layer breaks first when you try to bridge the 28-year gap, because every layer that breaks is a layer that tells you something about how modern web tooling actually works under the hood.

The reason this thought experiment is worth running is not that you will end up with Lovable on Windows 98. You will not. The reason is that the failure cascade — TLS handshake, then JavaScript engine, then DOM model, then WebSocket framing, then the model API itself — is a complete inventory of what the last quarter-century of web infrastructure quietly assumes. The people who built Lovable did not write any of it. They inherited all of it. So did you.

The Stack Gap Is Not Nostalgia, It Is a TLS Handshake

The first wall you hit is cryptographic, and it is not negotiable. Lovable's editor loads from a domain served behind a modern CDN, and modern CDNs deprecated TLS 1.0 around 2018, then TLS 1.1 by 2020. By 2026 the floor is TLS 1.2 with most edge configurations preferring 1.3. Internet Explorer 4.01, the browser that shipped with Windows 98 First Edition, speaks SSL 3.0 and a partial TLS 1.0. Even IE 5.5 on the Second Edition tops out at TLS 1.0. The handshake never completes. You do not get a 404, you do not get a login screen, you get a connection reset before a single byte of HTML arrives.

People who hear "TLS" think encryption strength. The real issue is cipher suite negotiation. A 1998 client offers a list of cipher suites — RC4, DES, maybe 3DES on a good day. A 2026 edge server responds with AES-GCM, ChaCha20-Poly1305, X25519 key exchange. There is no overlap. The TLS 1.3 specification, RFC 8446, explicitly removed every cipher suite a 1998 machine knows how to compute. This is the protocol layer doing exactly what it was designed to do, which is refusing to downgrade for a client that cannot prove it can keep a secret.

You could, in principle, run a man-in-the-middle proxy on the local network that downgrades the connection — terminate modern TLS on a Raspberry Pi, hand plaintext HTTP to the Windows 98 box. We have seen people propose this on the same Hacker News thread. It is a coherent workaround. It also means you are no longer running Lovable on Windows 98. You are running Lovable on a modern proxy and using Windows 98 as a dumb terminal that displays bytes the proxy already fetched. The actual computation has left the building.

The handshake is busy.

That is the recurring shape of every layer below this one. You can substitute, proxy, or emulate around the missing piece, but each substitution moves the real work somewhere else. The Windows 98 machine becomes a peripheral, not a participant. By the time you have proxied TLS, polyfilled the JavaScript runtime, and emulated the rendering pipeline, the only thing 1998 is contributing is the keyboard and the CRT.

Windows 98 Cannot Speak to Lovable, and That Is the Point

Suppose, for argument's sake, that the TLS problem was solved by the proxy. The connection lands. IE 4.01 receives HTML. Now the second cascade starts, and it is uglier than the first because there is no single layer to substitute. Lovable's frontend is a React application that compiles to ES2020 modules. ES2020 includes optional chaining, nullish coalescing, dynamic import, BigInt, Promise.allSettled, and a dozen syntactic features that the JScript engine in IE 4 parses as syntax errors before the first function body executes. The script tag fails to evaluate. The DOM never mounts. The page is blank.

You could downcompile. Babel can target IE 6 with the right preset, and there are forks that push further. But Lovable's editor is not a static SPA — it is a live workspace that streams tokens from the model over a WebSocket, applies them to a virtual file system in browser memory, transpiles them on the fly with esbuild-wasm or an equivalent, and renders the resulting React tree in an iframe sandbox. esbuild-wasm requires WebAssembly. IE 4 does not have WebAssembly. IE 4 does not have an iframe sandbox attribute. IE 4 does not have a structured Web Worker. The DOM API surface area is roughly 8% of what a 2026 application targets, and the 92% missing is precisely the 92% Lovable depends on.

The WebSocket layer is its own problem. RFC 6455 — the WebSocket protocol — was published in 2011. Before that, you had Comet, long-polling, hidden iframes pumping `