> how do you catch errors? Oh you just let things crash in production?

You write code differently, and you write tests. Rigorously testing business logic also has the nice side effect of catching type errors. "crash at runtime" in the real world means "crash in your tests". I've written a tonne of Ruby and it's simply not an issue

Plenty of businesses have been built on the back of dynamic languages. Nubank runs their somewhat critical business on millions of lines of gasp dynamic Clojure

> ..ends up creating an informally-specified, bug-ridden, slow implementation of half of React?

VS Code is written with custom JavaScript

Obsidian is written with custom JavaScript

Here's one reason to do it: the churn in these ecosystems is insane. Imagine writing a huge app in backbonejs back in the day when it was popular.. and then subsequently abandoned as people moved on to the new better way. That's an existential threat to your business if you're a small team. Even a big team takes a huge hit there

Vue2 to Vue3 was a shitshow. AngularJS -> Angular 2..

I'm still annoyed at React Query straight up deleting the documentation for the version a project I was on was using. Rails still has their docs up for the version released in 2009? The JS community just doesn't care about longevity

What happens when the React team decides "oh well actually WASM is the way forward" and redoes everything.. or maybe Svelte ends up taking over 4 years from now? Or hell if they even just evolve the framework in a direction that isn't in line with with what you want out of it