The 6-Week Hack That Killed Flash: How Jordan Walke Built React in His Spare Time — And Facebook Accidentally Started a Revolution

The Ad That Wouldn't Update

It was 2011, and Jordan Walke had a problem that was costing Facebook millions.

Every time someone interacted with a sponsored post in their News Feed — liked it, commented, clicked through — the entire page reloaded. The experience was clunky. Users hated it. Advertisers were complaining. And Jordan, a software engineer on Facebook's ads team, was watching conversion rates tank because the DOM manipulation was too slow.

The web in 2011 worked like this: when something changed on a page, you either reloaded the whole thing (slow, jarring) or you manually updated specific DOM nodes with jQuery (fast, but a maintenance nightmare). Facebook's News Feed had thousands of interactive elements. Managing them by hand was like conducting an orchestra where every musician played a different song.

Jordan couldn't sleep. So he started building something in his spare time.

He called it FaxJS.

The Heresy

Jordan's idea was considered insane by most web developers in 2011.

Instead of manually updating the DOM when data changed, what if you just... re-rendered everything?

Not the whole page. Just the parts that mattered. And not by hand — let the computer figure out what changed.

Here's the radical part: Jordan proposed keeping a lightweight copy of the DOM in memory — a "virtual DOM" — and whenever your application state changed, you'd:

1. Re-render the entire virtual DOM tree
2. Compare it to the previous version (a "diff")
3. Calculate the minimal set of actual DOM changes needed
4. Apply only those changes to the real DOM

This was heresy. Re-rendering everything sounded slow. Wasteful. The DOM was expensive to touch — everyone knew that. You were supposed to surgically update only what changed, à la jQuery or Backbone.

But Jordan had done the math. If you could diff two JavaScript objects fast enough — and Facebook's engineers were very good at making JavaScript fast — you could re-render a component tree in under 16 milliseconds. One frame. Imperceptible to humans.

The trade-off was brilliant: sacrifice a tiny bit of raw performance for massive gains in developer sanity. No more spaghetti jQuery selectors. No more brittle event listeners. No more "wait, which part of the DOM is this variable supposed to update?"

You just wrote your UI as a pure function of state. UI = f(state). When state changed, React re-rendered. The end.

The Secret Weapon: XHP

Jordan didn't invent this idea in a vacuum. He'd been working with XHP, Facebook's internal PHP extension that let you write HTML-like syntax directly in PHP code.

XHP looked like this:

$link = <a href="{$url}">{$text}</a>;

It was composable. Type-safe. You could build UI components and nest them. It made server-side rendering at Facebook way easier.

Jordan thought: What if we brought this model to the client?

But JavaScript in 2011 didn't support XML-like syntax. So Jordan wrote a custom syntax extension. He called it JSX.

JSX looked like this:

const element = <a href={url}>{text}</a>;

When Jordan demoed FaxJS internally at Facebook, showing off components written in JSX that re-rendered on every state change without touching the actual DOM until necessary, people were... confused.

"Why are you putting HTML in your JavaScript?"

"This violates separation of concerns."

"This will never be fast enough."

But then they saw the ads dashboard. Updating in real-time. No full page reloads. No jQuery soup. Just components that re-rendered themselves when data changed.

It worked.

The Instagram Problem

In 2012, Facebook acquired Instagram for $1 billion. Instagram's web app was a mess — built with Backbone, drowning in imperative DOM updates, slow as molasses.

Pete Hunt, another Facebook engineer, saw an opportunity. He'd been working with Jordan on FaxJS (now being called "React" internally). He pitched Instagram's team: Let us rebuild your web app in React.

They were skeptical. React was still experimental. It had barely been used outside Facebook's ads products. And JSX looked weird.

But Pete was convincing. "Give us two weeks," he said.

Two weeks later, Instagram's feed was rendering 50% faster. The codebase was half the size. And engineers who'd been drowning in jQuery callbacks were suddenly enjoying writing frontend code again.

That's when Facebook's leadership realized: this wasn't just an internal tool. This could change how the entire web was built.

The Keynote That Broke the Internet

May 29, 2013. JSConf US in Amelia Island, Florida.

Pete Hunt walked on stage to introduce React to the world.

He opened with a slide that said: "React: Rethinking Best Practices."

Then he showed JSX.

The room erupted. Not in applause — in groans.

"This is a step backward!"

"You're mixing concerns!"

"We spent 10 years separating HTML, CSS, and JavaScript, and you want to mash them back together?"

Pete smiled. He'd expected this. He clicked to the next slide:

"Separation of concerns is not separation of technologies."

He explained: a "concern" isn't "HTML vs JavaScript." A concern is a feature. A button. A dropdown. A news feed item. Each of those is a logical unit. So why scatter its template, logic, and styles across three different files?

React components bundled everything together. One file. One component. If you deleted the component, you deleted all its code. No orphaned CSS. No mystery event listeners.

Then Pete showed the demo.

He built a live-updating comment thread. Every keystroke in the input field re-rendered the entire component tree. But the DOM only updated the input's value. No flicker. No lag. 60 frames per second.

The skeptics went quiet.

By the end of the talk, developers were lining up to ask questions. The React GitHub repo, which Facebook had open-sourced that morning, was getting hundreds of stars per hour.

Within six months, React was the most talked-about JavaScript library on the internet.

The Reckoning: Angular vs React

In 2013, the dominant frontend framework was AngularJS, built by Google. Angular had two-way data binding, dependency injection, and a sprawling ecosystem. It was the "enterprise" choice.

React was the scrappy challenger.

Angular's two-way data binding seemed magical at first: change a model, and the view updates automatically. Change the view, and the model updates automatically. But as apps grew, this became a nightmare. Changes rippled unpredictably. Debugging was impossible. Performance tanked because Angular had to "dirty check" the entire scope tree on every change.

React's one-way data flow was simpler: data flowed down from parent to child. Changes flowed up via callbacks. You always knew where data came from. And because React's virtual DOM diffing was so fast, you could re-render aggressively without performance penalties.

By 2015, Netflix, Airbnb, Dropbox, and Uber had all bet their web frontends on React. Angular was scrambling to rebuild from scratch (Angular 2 was a complete rewrite, incompatible with Angular 1).

React had won.

The License War

But there was a problem.

In 2017, Facebook's open-source license for React included a controversial patent clause: if you sued Facebook for patent infringement, you automatically lost your license to use React.

Companies freaked out. Apache Foundation banned all Facebook open-source software with this license. WordPress threatened to rip React out of Gutenberg, its new editor. Startups worried their VCs would pull funding if they used React.

In September 2017, Facebook's developer relations team was in crisis mode. React's adoption was tanking. Competitors like Vue and Preact were gaining ground.

Facebook's legal team blinked.

On September 23, 2017, Facebook relicensed React under MIT — no patent clause. The announcement was posted on GitHub at 11 PM on a Friday night. By Monday morning, the controversy was over.

React's growth resumed. By 2020, React was used by 8 million developers — more than Angular, Vue, and Svelte combined.

The Genius Under the Hood

What made React truly revolutionary wasn't JSX or the virtual DOM. It was the reconciliation algorithm — the code that figured out what changed between renders.

React's diffing algorithm is based on two assumptions:

1. Elements of different types produce different trees. If a <div> becomes a <span>, React throws away the old subtree and builds a new one.
2. Developers can hint at stable identity with keys. When rendering lists, you provide a key prop. React uses it to match old and new elements, preserving state.

These heuristics let React diff trees in O(n) time — linear, not exponential. A general tree diff is O(n³). For a tree with 1,000 nodes, that's the difference between 1,000 operations and 1 billion.

This is why React is fast.

The Compiler Revolution

Today, React is evolving again.

In 2024, React 19 introduced the React Compiler — an optimizing compiler that analyzes your components and automatically memoizes them. No more manual useMemo or useCallback. The compiler figures out dependencies and optimizes re-renders for you.

It's the same philosophy Jordan Walke started with in 2011: let the computer do the hard work.

The Legacy

Jordan Walke left Facebook in 2018. He's now working on ReasonML, a functional programming language that compiles to JavaScript.

But React lives on. It powers Facebook, Instagram, Netflix, Airbnb, Discord, Notion, and millions of other apps. The "component model" React popularized has been copied by Vue, Angular, Svelte, and every modern framework.

The idea that seemed insane in 2011 — re-render everything, let the virtual DOM figure it out — is now the foundation of how we build for the web.

Jordan Walke built React in six weeks because Facebook's ads were too slow.

He accidentally started a revolution.