Framework Economics: The $30 Million Question the JavaScript Ecosystem Keeps Getting Wrong

The pattern described in this retrospective talk has been repeated enough times that it now has recognizable stages. A team identifies genuine problems with existing UI solutions, builds something technically superior in specific ways, attracts a wave of early enthusiasm, secures significant capital, and then confronts the gap between “technically better” and “wins the market.” By the time that gap becomes undeniable, the money is spent.

What makes this worth examining is not the failure itself but the specific shape of the expenditure. The $30M almost never disappears on bad engineering. The core framework is usually good. The waste accumulates in places that nobody budgets for at the start.

The True Cost Structure of a Framework

Building a JavaScript framework’s core runtime is the cheap part. A small team of senior engineers can produce something technically credible in two to three years. The sticker shock comes from everything else.

Documentation and learning resources are the first underestimated line item. React’s documentation was rewritten at least twice, with the 2023 react.dev rewrite taking a dedicated team roughly a year. The new docs introduced the “thinking in React” mental model shift, deprecated class components in the canonical learning path, and required creating entirely new interactive diagrams and examples. This is not supplementary work. Poor documentation is a primary reason developers abandon a framework during evaluation.

Tooling comes next. Create React App (now deprecated in favor of Vite-based alternatives), the framework CLI, browser DevTools extensions, editor plugins, ESLint configurations, and TypeScript definition packages: each requires dedicated engineering for months. The Ember.js ecosystem required separate sustained investments in Ember CLI, Ember Inspector, EmberData, and later Glimmer.js as a lower-level rendering primitive. Ember’s primary backer Tilde, cofounded by Yehuda Katz, sustained this investment for over a decade, with additional help from LinkedIn, Apple, and other significant Ember users.

The hosting layer surprises many framework companies. If the framework supports server-side rendering or edge computing, the natural move is to offer managed hosting. This is where both Gatsby and Meteor tried to convert framework adoption into recurring revenue. Gatsby Cloud launched in 2020, two years after Gatsby Inc. was incorporated. Netlify acquired the company in 2023 for a price reportedly well below the $36M+ Gatsby had raised. Meteor built Galaxy, a managed hosting platform for Meteor applications, as its primary revenue vehicle. Neither service achieved the growth required to justify the framework investment.

Meteor: The Best-Documented Version of This Story

Meteor Development Group’s trajectory from 2012 to 2019 is the most completely documented case. The company raised $11.2M from Andreessen Horowitz in July 2012, at a moment when full-stack JavaScript was still a provocative claim, and total funding reached approximately $31.2M before Tiny acquired the project in 2019.

What Meteor got right technically was substantial. The DDP (Distributed Data Protocol) provided a standardized WebSocket protocol for reactive data synchronization between server and client. Livequery delivered MongoDB change stream behavior before MongoDB itself natively supported change streams. The isomorphic code model, where the same JavaScript ran on server and client with shared state, predated the React plus Node.js idiom that later became standard practice. Meteor’s Atmosphere package registry predated npm’s rise as the universal JavaScript package registry.

None of this was enough. The MongoDB-only data support was a serious constraint that took years to address. The DDP protocol was elegant but required Meteor on both sides of a connection, making gradual adoption impossible. You could not add Meteor reactivity to an existing Express application; you replaced the application with a Meteor application. When React arrived in 2013-2014, it offered a component model that could be adopted incrementally, column by column in an existing codebase. Meteor required a different kind of commitment.

The Galaxy hosting service launched in 2015 at pricing that reflected the real infrastructure costs of running Meteor’s stateful connections in production. By 2019, the company had been acquired by Tiny, a Canadian holding company that specializes in purchasing developer tools with established but slow-growing communities.

Why the VC Model Specifically Does Not Work for Frameworks

Developer tools are structurally difficult as VC-backed businesses. The people who evaluate and select frameworks are technical staff who have strong opinions about open-source licensing and vendor lock-in. The organizations using frameworks at scale want support contracts and SLAs but have procurement processes that make closing enterprise deals slow and expensive.

The VC model creates incentives that are almost precisely misaligned with framework adoption curves. Investors expect compounding growth; framework adoption curves are S-shaped with a long plateau after initial adoption. Pressure to grow faster than organic adoption allows leads to premature monetization that damages community trust, or features that serve enterprise sales requirements rather than developer experience quality.

React resolved this structural problem by not being a business. Meta funds React development as infrastructure for its own products. The framework has no revenue targets, no investor reporting obligations, and no need to convert developer enthusiasm into a recurring revenue model. That is an enormous structural advantage that framework startups cannot replicate.

Angular has Google. Vue.js has a distributed patronage model through OpenCollective and corporate sponsorships, alongside Evan You’s work at Volar and NuxtLabs. Svelte received Vercel’s institutional backing when Rich Harris joined in 2021. The common thread across every currently healthy framework is institutional backing that removes or substantially reduces direct revenue pressure.

Next.js and Vercel are the closest thing to a counterexample: a framework developed and maintained by a company that monetizes through hosting and CI/CD services. This model works partly because Next.js targets server-side rendering and edge functions that naturally require deployment infrastructure, and partly because Vercel has executed the developer experience layer with unusual discipline. But Vercel has raised over $313M in total funding, which contextualizes how much capital is required to make the “framework as infrastructure business” model function at all.

The Ecosystem Density Problem

The $30M figure represents the cost of learning that technical quality is necessary but not sufficient. What actually determines long-term framework adoption is ecosystem density: the cumulative count of libraries, tutorials, Stack Overflow answers, job listings, and consultant hours that reference the framework.

Ecosystem density compounds slowly and cannot be purchased directly with engineering budget. You can hire documentation writers and developer advocates, but you cannot hire the hundreds of independent blog posts and conference talks that constitute a framework’s ambient presence in developer culture. These emerge from genuine adoption, which takes years.

The Dojo Toolkit tells a version of this story across a longer time horizon. Dojo emerged with backing from SitePen, IBM, and AOL. It was technically advanced for its era: Dojo Deferred predated widespread Promise adoption by several years, the AMD module system was influential before CommonJS and ES Modules existed, and the widget toolkit was one of the more complete UI component libraries available in the late 2000s.

jQuery’s rise made Dojo’s comprehensive scope seem like a liability rather than a feature. By the time the React era arrived, Dojo was already in niche maintenance status. SitePen still maintains it, and Dojo remains present in significant enterprise applications, particularly within the Esri/ArcGIS ecosystem. The investment that built it never produced a framework business; it produced a well-engineered library that found a durable but limited niche.

YUI tells the same story at Yahoo’s scale. Significant engineering investment across nine years, deprecated in 2014, with no corresponding business value captured despite genuine technical quality. GWT (Google Web Toolkit) followed the same arc: substantial Google investment from 2006 onward, significant enterprise adoption in the early 2010s, and gradual deprecation as Angular and then React redefined how frontend development worked.

What Gets Built Before the Money Runs Out

The $30M in a framework investment follows a rough sequence: two to three years of core engineering, one to two years of ecosystem tooling, one year of community and content investment, and then a scramble to monetize before runway ends. The community and content investment almost always comes too late and gets cut short by pressure to ship revenue-generating features.

The framework ecosystem also demands maintenance commitments that compound over time. Security vulnerability response, major version migration guides, compatibility with each new version of Node.js, TypeScript, and the major bundlers: these are recurring costs with no natural revenue attachment. A framework that reaches 50,000 weekly npm downloads has simultaneously reached the threshold where abandoning it would hurt real production systems and the threshold where maintaining it requires sustained engineering investment that a startup without revenue cannot afford.

The lesson this pattern teaches is not that building frameworks is a bad idea. It is that building a framework is the tractable part of the problem. Building the conditions under which developers will adopt, stay on, and recommend the framework across a decade of competing alternatives and evolving browser standards is the expensive part. And that cost has very little to do with how good the underlying code is.

The $30M tends to answer the wrong question. The engineering question, “Can we build something technically better than what exists,” has an affirmative answer at relatively modest cost. The market question, “Can we displace the incumbent’s ecosystem density within the runway we have,” is the one the $30M rarely lives to see answered.