The Convection Oven Architecture
Web developers destroy mobile conversion rates by shipping massive JavaScript bundles for simple features modern HTML already handles natively.
By Saul Berger
Sparked by HTML Can Do That · discussion

The CEO stares at a downward-trending chart while quietly losing his mind, wondering what is wrong with the company's mobile conversion rates. “We spend scrillions on Google Ads to get people here, and then they just vanish into the ether,” he mutters. Meanwhile, his lead developer is sitting across the glass conference table, spinning a custom-machined brass top and sketching impenetrable UML diagrams on a whiteboard, passionately lecturing the room about how if they just pause all feature development for six months to migrate their entire front-end infrastructure to a brand new server-side-rendered micro-hydration framework, their component state management will be 34% more elegantly decoupled and the DOM will finally achieve true zen-like reactivity.
Garbage.
Here is the physical world absurdity at the absolute, beating heart of modern web development: For over a decade now, we have essentially been mailing our end-users a 4,000-pound commercial convection oven, a wooden pallet loaded with fifty-pound sacks of raw flour, a complex ventilation hood that requires a master electrician to install, and a dense, incomprehensible binder of assembly instructions just so the user can eat a single, solitary slice of toast.
When a customer clicks the checkout button on your e-commerce site, they just want to see a shopping cart. They want the toast. But your engineering team is forcing their phone to download, parse, compile, and execute an entire industrial bakery of client-side routing, virtual DOM diffing logic, and state-management middleware. Every single megabyte of JavaScript your team dumps onto a user's phone is a literal, calculable tax on your conversion rate, essentially burning your hard-earned marketing budget in a dumpster out back to subsidize an Architecture Astronaut's ego.
We did not arrive at this ridiculous situation maliciously. Back in 2012, HTML was a frozen, lifeless wasteland. If you wanted a modal window, a functional accordion, or a tooltip that didn't look like it was designed by a mid-level bureaucrat in a Soviet planning committee, you had to duct-tape it together with massive, sprawling JavaScript libraries. The browser was fundamentally stupid. Shipping a 200kb JS bundle was an absolute necessary evil because you had to build the oven in the client's house, considering the client's house didn't even have a fire pit, let alone a kitchen. You spent hours just trying to make a dropdown menu that wouldn't inexplicably render underneath an embedded YouTube video.
But then the Architecture Astronauts took over. These are the folks who simply cannot solve a practical problem without first inventing a massive, metaphysical abstraction layer to represent the concept of the problem in a perfectly pure, platonic void. They convinced an entire generation of junior developers that every single website on the internet needs to be a stateful, client-side application. We started shipping the convection oven to render static blogs, basic text-heavy marketing pages, and dead-simple checkout flows. The industry normalized a workflow that is the digital equivalent of requiring your users to dig a trench with a spoon and lay their own fiber-optic cables just to read a damn restaurant menu.
Here is the part the astronauts completely missed while they were fiercely debating whether to store global application state in Redux, Context, or whatever shiny new paradigm Hacker News was fawning over that week: the web actually evolved.
I was reading through Chris Burnell's HTML cheat sheet yesterday, and it acts as a violent shock to the system for anyone whose brain is still stuck in a 2016 engineering mindset. You don't need a massive JavaScript component and a gigabyte of node modules to build an accordion anymore. You use <details> and <summary>. You don't need a third-party library to trap focus, manage Z-indexes, and render a pop-up over the rest of the page. You just use the native <dialog> element, which has been quietly documented over on MDN and supported natively in every major browser for years.
The browser now comes with a pre-installed toaster. We are shipping massive, sprawling JavaScript bundles purely out of historical ignorance, terrified to wake up and realize that modern HTML can already do the job natively.
(Attention, W3C pedants and web-standards contrarians: Yes, I am fully aware of the pragmatic reality that native datalist elements still have glaring accessibility quirks and severe styling limitations compared to heavy JS date pickers. Look, I don't need a twelve-page diatribe in my inbox detailing your righteous indignation over the purity of the DOM. Start your own newsletter. We are talking about basic modals, popovers, and accordions here, not trying to build a fully localized, enterprise-grade airline booking engine in raw markup.)
Let us pivot away from the aesthetic arguments about architectural purity, which are mostly just religious wars for nerds anyway, and focus on brute, undeniable microeconomics. Let us talk about the Megabyte Tax.
The fundamental delusion of modern web development is the persistent belief that everyone in the world is testing their code on a $3,000 MacBook Pro. On that machine, a massive React bundle parses and compiles faster than you can blink. It feels instantaneous. But real customers do not shop on brand new MacBook Pros while sipping artisanal lattes on a gigabit office network. Real customers shop on cracked, four-year-old mid-tier Android phones while waiting for a bus on a spotty 3G connection in the rain.
The V8 team's 2019 data proves exactly how dangerous this hardware illusion is. A JavaScript bundle that parses and compiles in a brisk 50ms on an engineer's high-end laptop takes over a full second to parse on a real-world Moto G phone.
During that agonizing second, the phone's CPU is completely locked up. The main thread is gagging on your elegant hydration logic. The user is frantically tapping a frozen checkout button, getting absolutely nothing in return, assuming the entire site is broken, and leaving to buy their shoes from your competitor.
Diagram Opportunity: A stark, MS-Paint-style bar chart comparing the 50ms JS parse time on a Developer's $3000 MacBook Pro versus the 1100ms parse time on a Customer's cracked Android phone, labeled The Architecture Astronaut Illusion.
That frozen second of silence is actively destroying your business. The Deloitte report on mobile speeds found that a mere 100ms delay in site load time causes an 8.4% drop in retail conversions.
Do the math.
Let's say your site does $100,000 a day in sales. Your lead developer's insistence on shipping the entire industrial bakery to the client just cost the business 8.4% of its top-line revenue. That is $8,400 a day, or over three million dollars a year, flushed directly down the toilet. This is what I mean by the Megabyte Tax. The company is setting literal piles of money on fire with targeted advertising to funnel users onto a product page, only to violently slam the door in their faces at the last possible millisecond because the device is too busy compiling a massive abstraction layer that the user will never even see. You are literally paying Google for traffic, and then paying your own developers to build a brick wall that prevents that traffic from buying anything.
Madness.
The Architecture Astronauts will tell you that the oven is necessary for future-proofing, or because Facebook does it that way. But you are not Facebook. You do not have thousands of engineers on standby. You are trying to sell a pair of shoes. When you force your users to pay the Megabyte Tax, you are prioritizing the aesthetic preferences of your engineering department over the actual survival of the business. You are letting the inmates run the asylum.
Look, if your engineering team is actively trying to build a full-blown competitor to Figma that requires real-time vector manipulation entirely inside the browser, fine. You get a pass. But for the rest of you? The harsh reality is that writing a handful of plain, boring, native HTML tags is going to be the most ruthlessly profitable approach to getting your product out the door. Stop shipping the oven. Just serve the toast.