Bun's adoption rate (because of its NPM compatibility) was the forcing function; not VC funding. Deno could pursue a slow-and-steady better-will-win approach vs. Node until another runtime competitor appeared with a more seamless node integration. In fact, the VC funding is what made the slow-but-steady strategy possible in the first place.

▲

afavour 4 hours ago | parent [-]

Strong disagree. Deno could have been a cheaply run open source project with corporate sponsors and could have pursued the slow and steady approach. There's no reason to feel pressure from competitors unless you want to if you're forging a genuinely new path. "Clean break from Node" was the differentiator. Once they abandoned that the reason for using it went away.

The moment they took on VC funding they had to care about competitors and also had to move away from the framework to things like Deno Deploy in pursuit of money.

▲

carefulfungi 3 hours ago | parent | next [-]

I doubt deno could have funded its development purely from sponsorship. And Deploy generated real revenue (on its OEM/b2b side).

Jt is interesting to speculate on what might have been had Deno never been a profit-seeking company. But having worked there, I am reasonably confident in my assessment above.

	▲	afavour 2 hours ago \| parent [-]
		I agree that should it need to be profit making then what’s e got makes sense. But hey, Node isn’t a profit making enterprise. Deno could have been the same.

▲

genxy 3 hours ago | parent | prev [-]

I only tangentially followed Deno, but am a proud Deno 1 hoodie-haver!

A compatibility shim sounds like a great community run project while the core team could work on the slow-but-steady w/o concerning the core with too much burden of node compat.

Deno is now a feedstock for future JS runtimes.