You’ve felt it. That moment when you’re three callbacks deep, your async function returns undefined for no reason, and you think: Why the hell are we still writing JavaScript in 2024?
Python is cleaner. Python is elegant. Python reads like English. So why does the browser — the most widely deployed runtime in human history — remain stubbornly, maddeningly, JavaScript territory?
Most developers think it’s just inertia. Microsoft won. Netscape lost. V8 got fast. Path dependence did the rest.
That’s the story everyone tells. It’s also completely wrong.
JavaScript doesn’t run the web because it’s popular. It’s popular because it’s the only language whose execution model actually fits how a browser works.
Think about what a browser actually does. It’s not a Python interpreter with a rendering engine bolted on. It’s a real-time, event-driven machine that must respond to clicks, scrolls, network packets, and animation frames — all while painting pixels to a screen 60 times a second. Every millisecond matters. The DOM doesn’t wait. The event loop doesn’t wait. Nothing waits.
Now think about Python. Python is synchronous by nature. It’s designed for clean, linear execution where one thing happens, then the next. You can add async, sure — but you’re bolting concurrency onto a language that was never built for it. JavaScript was born in the browser. Its entire soul is non-blocking.
The browser doesn’t care about your syntax. It cares about your execution model. And Python’s execution model is fundamentally, architecturally at odds with what the web demands.
Here’s what people miss when they fantasize about a Python-first web: the DOM API is not just some interface JavaScript happens to use. It’s deeply, intimately coupled to JavaScript’s event loop. Every addEventListener, every setTimeout, every Promise.then — these aren’t features layered on top. They’re baked into the rendering pipeline itself. The browser schedules DOM mutations around JavaScript’s microtask queue. It pauses scripts during layout. It batches reflows around event loop ticks.
You can’t just swap the language. You’d have to rebuild the browser.
Imagine a Python-first browser. To make Python manipulate the DOM the way JavaScript does, you’d need one of two things: a completely new virtual machine that reimplements the event-driven concurrency model — at which point, congratulations, you’ve reinvented JavaScript with worse syntax — or you’d lean on WebAssembly, running Python compiled to WASM alongside a JavaScript shim for DOM access. Which means you still need JavaScript. You’ve just added a layer of indirection and made everything slower.
Every developer who’s ever cursed JavaScript’s quirks needs to understand this: the quirks aren’t bugs. They’re the price of admission to the only execution model that makes interactive web pages possible.
I’ve watched teams try to dodge JavaScript. They reach for PyScript, for WASM-compiled Python, for server-side everything. And every time, they hit the same wall: the moment you need real, responsive, client-side interactivity — drag and drop, real-time updates, smooth animations — you’re back in JavaScript’s house. Because the browser’s rendering engine and JavaScript’s event loop aren’t separate things that happen to coexist. They’re the same system.
The uncomfortable truth? Python is a better language. JavaScript is a better web language. Those two facts coexist without contradiction, and pretending otherwise is a category error.
Python dominates data science, backend services, scripting, AI. It wins everywhere the execution model is: receive input, process, return output. Linear. Clean. Beautiful.
The web is not that. The web is: receive 47 simultaneous events, reconcile state, mutate a live document tree, paint to screen, handle the next 47 events — forever, without blocking, without crashing, without dropping a frame.
Python was designed to make developers happy. JavaScript was designed to make browsers work. The web chose function over beauty. That’s not a tragedy — that’s engineering.
So the next time you’re drowning in Promise chains and reaching for a Python-shaped life raft, remember: the grass isn’t greener on the other side. It’s a different ecosystem entirely. And the browser — that beautiful, chaotic, event-driven beast — will always belong to the language that was born inside it.
FAQ
Q: But what about PyScript and WebAssembly? Aren't they already making Python in the browser a reality?
A: They're impressive demos, but they fundamentally rely on JavaScript as a bridge to the DOM. You're not replacing JavaScript — you're adding layers on top of it, with performance penalties and architectural compromises. The moment you need responsive, real-time interactivity, you hit the wall.
Q: Does this mean we're stuck with JavaScript forever?
A: For the browser's interactive layer, effectively yes — unless someone rebuilds the rendering engine from scratch around a different execution model. WebAssembly may eventually provide a true escape hatch, but that's a decade away from replacing JavaScript's DOM integration.
Q: Isn't this just defending a monopoly because it exists?
A: No — it's recognizing that JavaScript's dominance isn't arbitrary. It reflects a genuine architectural fit between language design and runtime constraints. If Python had been built for event-driven, non-blocking DOM manipulation from day one, it might have won. It wasn't, so it didn't.