The rise and fall of famo.us...
Chapters9
Sets up the idea that some technologies reshape history while others are forgotten, focusing on a forgotten tech from 2012.
Famo.us tried to turn the browser into a GPU-powered 3D rendering engine, but a shifting web ecosystem and hard math kept it from mainstream success.
Summary
Fireship’s rapid dive into the rise and fall of Famo.us chronicles a bold 2012-era vision: render everything in the browser using GPU-driven 3D transforms and a 4x4 matrix math approach. Seth, as the host, recalls how HTML5 was hailed as the web’s future even as Facebook and Bench Rank wrestled with its limitations, unintentionally nudging developers toward GPU tricks. Famo.us pivoted from a startup story akin to LinkedIn-meets-Hot-or-Not to a rendering engine that promised universal reach across devices, thanks to GPU-accelerated CSS. Yet by 2014, browsers had already evolved with faster GPU compositing, 3JS filled the 3D niche, and React offered declarative UI for the rest, eroding Famo.us’s advantages. The API proved tough, requiring deep math and JS knowledge, while the business model struggled—fueling layoffs and a final pivot to a marketing-site CMS. Despite the failure, Famo.us pushed the industry toward higher performance and bolder UI aspirations, a legacy Fireship argues is worth commending. The sponsor segment introduces Railway as a modern cloud-in-a-box counterpart, highlighting how the industry keeps evolving between flashy demos and practical tooling.
Key Takeaways
- GPU-driven rendering sparked early excitement for browser-native UIs, with Famo.us building a 4x4 matrix-based system to control layout, size, and animation.
- HTML5 limitations in 2012–2014 created pain points that developers briefly tried to solve with GPU tricks rather than waiting for standards to evolve.
- By 2014, faster GPU compositing, 3JS, and React reduced the unique advantages Famo.us offered, diminishing its core value proposition.
- Famo.us faced a tough API, requiring math, physics, and JavaScript expertise, which limited adoption among UI developers.
- The company pivoted to hosting, monitoring, and finally a CMS for marketing sites, but the shifts could not sustain the business at scale.
- Despite the failure, Famo.us pushed the industry toward higher performance expectations and native-like web experiences, influencing future tooling and UX thinking.
- Railway is highlighted as a modern, user-friendly cloud provider that exemplifies the ongoing evolution from ambitious demos to practical platforms.
Who Is This For?
Essential viewing for frontend engineers and UI specialists curious about browser rendering history and the factors that kill ambitious rendering startups. It explains why GPU-based UI ideas flourished briefly and then faded, and what current tools can learn from that hype.
Notable Quotes
"The famous would literally output a 4x4 matrix that would then get interpreted by the browser as a matrix 3D CSS property with every element's layout, size, and animation determined by these matrices."
—Describes the core rendering trick behind Famo.us and why it seemed revolutionary.
"At their peak, Famous had 25 employees, and their founder was quoted as saying he didn't believe in running a lean startup."
—Highlights the company’s ambitious culture and one of the managerial missteps that contrasted with market realities.
"They pivoted to creating a rendering engine based on that parlor trick."
—Shows the initial pivot from a startup concept to a rendering engine strategy.
"But when that also didn't pan out and the hype for the rendering engine died down, they had to lay off their entire engineering team."
—Marks the downturn and the consequences of a fading market fit.
Questions This Video Answers
- What happened to Famo.us and why did its browser rendering approach fail?
- How did HTML5 limitations influence early GPU-based UI experiments in the browser?
- What can modern UI toolchains learn from Famo.us about balancing performance with developer usability?
- Why did 3JS and React together outpace GPU-based web rendering frameworks in the mid-2010s?
- What is Railway and how does its approach to cloud deployment compare to legacy browser rendering technologies?
Famo.usGPU RenderingHTML5 HistoryBrowser Rendering Engines3D CSS Transforms4x4 Matrix in CSSTech Startup PivotsTech Hype CyclesRailway Cloud Platform
Full Transcript
Every once in a while, a technology comes around that changes the course of history. The transistor, cloud computing, AI. But even more often, a technology comes along that has no impact on the course of history whatsoever. It's easy to celebrate the winners of tech history. But today, we're going to do the opposite and honor one of the great technological face plants that's been forgotten to time. The year was 2012. Everyone was doing the Gangdom Style dance while writing copycript code in Sublime Text. And if you were a developer during this time, I'd like to take a moment to remind you that it's time to go get your prostate checked.
Now, believe it or not, at the time, there was one programming language that everyone was talking about, HTML 5. Its goal was to expand the web as a platform that developers could build on to better compete with native apps without plugins like Flash or Silver Light. Unfortunately, it didn't really work out that way. Even Zuck, despite an ongoing battle with the FTC over privacy issues, it claimed Facebook's biggest mistake was betting too much on HTML 5. At the same time, another team in Silicon Valley was working on a reputation system for people startup called Bench Rank, which you can kind of think of like if LinkedIn and Hot or Not had a baby.
While building their web app, they also ran into the same HTML 5 limitations that plagued Facebook. But while trying to get around those limitations, they discovered a cool parlor trick with the browser. Instead of letting the browser's layout engine control everything as it normally does by essentially hacking the native Matrix 3D CSS property, they could push as much work as possible to the GPU, which solved some of their rendering performance issues. Then after realizing that working on a startup that could be described as if LinkedIn and Hot or not had a baby was a terrible waste of time, they pivoted to creating a rendering engine based on that parlor trick.
Now, I know what you're thinking. There's no way in hell a company could raise $30 million from a single GPU accelerated CSS property. Well, sure enough, they raised $30 million. And in hindsight, it's easy to laugh at. But at the time, the idea of throwing out the traditional CSS model in favor of a cartisian coordinate system where all the elements are absolutely positioned with 3D transforms was kind of cool. The famous would literally output a 4x4 matrix that would then get interpreted by the browser as a matrix 3D CSS property with every element's layout, size, and animation determined by these matrices.
It was the good old days of linear algebra in the browser before it was used to decimate our entire industry. And take a shot if you've heard this before, but because most devices have access to a GPU, the Famous could target all of them, allowing you to write a single app that would work mostly anywhere. So why aren't we all using Famous today? and why is their website currently for sale? Because reality is often disappointing. The Famous was first announced at TechCrunch Disrupt in September of 2012, but it took them until June of 2014 to release something that developers could actually play with, and a lot happened during that period.
At first, browsers got faster thanks to improvements in GPU compositing and animation scheduling. This meant that many of the performance tricks Famous relied on like bypassing layout and animating purely with transforms became common browser practices which shrink the advantage of Famous's custom rendering engine. The second how we built UIs changed. If you really needed a complex 3D GPU interface, 3JS became a solid option. And if you had a more normal interface, you could describe it declaratively with React. Third, when it did get released, Famous wasn't the easiest API to work with. Despite their best efforts, it still required a deep understanding of math, physics, and JavaScript to work well.
And if there are three things UI developers aren't good at, it's math, physics, and JavaScript. And finally, the economics of creating a new layout engine in the browser never really made sense. At their peak, Famous had 25 employees, and their founder was quoted as saying he didn't believe in running a lean startup. This led to them trying out a few different ways to make money, like hosting and monitoring. But when that also didn't pan out and the hype for the rendering engine died down, they had to lay off their entire engineering team and did one final hard pivot to a CMS for marketing sites, which also eventually failed.
But I don't think that means Famous was all failure. They tried to ship the future early by building around the limitations of the browser instead of waiting for the standards to evolve. That's what made it so promising yet so brittle. Sure, it failed, but for a moment, it made developers believe the web could feel truly native, and it helped push the industry's expectations of performance and UI ambition forward. And for that, it should be commended. And another technology that's pushing the industry forward right now is Railway, the sponsor of today's video. It's an all-in-one intelligent cloud provider that lets you deploy anything in a few clicks.
So, instead of drowning in YAML, you can just connect your repo to Railway and it automatically sets up the right config for you. Or you can use the Railway CLI with their new agent skills to let Claude Code, Codeex, or any of your other agent minions to do all the dirty work. Developers love how easy it is to spin up any service you want, and how Railaway only charges you for the resources you actually use and not what you provision, which can save over 65% on cloud costs. Sign up for free today with the link below and you'll get $20 in free credits when you upgrade.
Thanks for watching.
More from Fireship
Get daily recaps from
Fireship
AI-powered summaries delivered to your inbox. Save hours every week while staying fully informed.



