The react revolution

React was greeted like an ugly stepchild when it walked on stage in May 2013. HTML inside JavaScript? When CDN framework imports and jQuery were the standard build pipelines⁴, the new syntax was doing too much all at once. It not only mixed two separate languages, but it also mixed two inherently imperative communities. Declarative state programming was not how you build websites.

A few months later Pete Hunt doubled‑down with his now‑classic "Rethinking Best Practices" talk at JSConf EU, waving JSX around like a red cape and daring everyone to give it five minutes before stampeding. Five minutes might be all that it takes when you know an alternative would take you hours.

React's timing helped. Node.js was already exploding. npm ended 2014 serving 7 billion downloads a month, up roughly 4x from just two years before¹. Same language in the front and back promised zero context switching, more flexible engineers, and faster features. React hitched a ride on that freight train then jumped tracks. Electron (open‑sourced 2013) put those components on the desktop, Slack‑style. React Native went mobile after Facebook’s F8 reveal in 2015 and suddenly JavaScript was compiling down to real Cocoa Touch views instead of running in a WebView.

"Good enough" cross‑platform was more than enough when the alternative was three different codebases.

Meanwhile every platform stole the mental model. Apple lit up WWDC 2019 with SwiftUI - declarative, live‑previewed. It was the whole React playbook just with SomeView instead of <div>. Google answered with Jetpack Compose, hitting 1.0‑stable in July of 2021. The idea is contagious: describe the final state, let the runtime figure out the steps.

We collectively realized, everyone at the same time, that it just feels good to write declarative interface code. To describe how you want something to look at its end state - not how to transform the current state of an element to get there.

The general arguments about declarative vs imperative design patterns emerge as they always do. The tension distills down to something like "declarative cuts boilerplate" versus "imperative gives me control". But then they stall out in abstract territory. They miss how people feel after six hours at the keyboard. Cognitive‑load studies keep showing that when a language lets you state your intent instead of narrating every micro‑step, you burn less mental energy and make fewer mistakes.² You can actually think about the problem instead of shepherding variable properties.

Imperative code flatters you with an illusion of mastery - every loop, every mutation screaming “I did this.” Jeremy Keith calls it the comfort of inventing everything from scratch, right up until the day you inherit someone else’s mess and realize the knobs were placebo all along.

Declarative flips that relationship: you hand the runtime the goal, the runtime does the grunt work, and your brain stays parked in high‑level land. That feels like magic the first time a <Button> component re‑skins itself across the entire app with one prop change. It gives you a little jolt of magic every day.³

Simplicity makes it easier to get into the flow. Hooks (React 16.8, February 2019) distilled the API to three lines: useState, useEffect, and a return statement full of markup. Add props and you’ve basically memorized the surface area.

When you're writing JSX you just feel like you're writing regular Javascript and regular HTML. The additional syntax layered on top of two existing languages makes the learning curve almost trivial. There's way more you can learn but at its heart that's all you have to deeply internalize. Learn how to manipulate variables and you learn how to manipulate the whole layout of the page.

So here we are, twelve years on. No headings, no templates, just one big component tree. React didn’t just win the JavaScript wars; it changed how every major platform thinks about UI. Everything else is implementation detail.