I mean, not really? My naive implementation in Solid required a few tweaks understanding the model and performs updates perceptually instantaneously on a perf sensitive input I use as a smoke test, without any of the tricks I expected to need, just its built in reactive primitives. The existing implementation performs the same computations on that data in about half a second, which feels like an eternity without special care to unblock the UI. JS is really fast. You just have to know how to use it, and when not to.

Every programming language and application has the chance to become unusable, thus every JavaScript application has the opportunity to become unusable, obviously most do not because otherwise nothing would be usable on the Internet which, snark aside, things are usable even if they might annoy me.

>You just have to know how to use it, and when not to.

So, you have never had a JS application delivered over the web become unusable despite your attempts to only use it how and when you need to?

Okay, well, congratulations either or in order or you've not been forced to use it for something you didn't want to or have just never been building something big with the technology and made a mistake?

I mean my stuff generally doesn't become unusable, but generally is not always.

> So, you have never had a JS application delivered over the web become unusable despite your attempts to only use it how and when you need to?

Of course I have, that’s not the point I was making. My point was that JS and the VMs it runs on are very fast, if you know how to use the language and when not to use it. That couldn’t possibly apply to apps you didn’t build. If I’d said C or whatever is fast if you know how to use it, I don’t think I’d get this comment about some horribly inefficient downloaded printer driver.