Cant vouch for every situation but I think in general it actually pretty much achievable using slow attrition. From what I've observer while consulting corporate systems are collections of hundreds components. Start with one with clearly defined functionality and slowly chip away. Does not prevent from delivering new features.

The only thing here is that it will introduce certain overhead and has to be carefully managed. Also one has to make sure if it has measurable ROI.

Okay, fine. I will try for Elixir, Phoenix Live View and as little JS as possible and see how we go.

I am not sure if Elixir is performance beast. But then again I do not know much about it other than it runs on VM.

I wouldn't call Elixir/Phoenix a "top performer" in the league of Java/Vert.x or Rust/Actix (see TechEmpower benchmarks) but it does VERY well at chugging along and not falling to pieces. Its dev experience is really nice. Its missing type-safety, but, honestly, I quite enjoy messing with it.

Everyone thinks Elixir is slow until they use it and then realise throughput is often more important than absolute performance.

As I said I do not know much about Elixir so yo be the judge. I do however have doubts about throughput of well designed code running on VM being faster then that of native. My understanding is that on Erlang VM this throughput is achieved by using async and message passing patterns backed up by thread pools inside. All perfectly available for "low level" languages as well.

I understand, my preference is Elixir but while fast enough and scalable, it is a memory and cpu hog.

That’s possibly a trend from the places I’ve worked. The larger he organization the better the odds there are little niches of few users using specific software and website services. From around. 2x-5x GP’s size.

Corporate America, am I right?

But this is a safe place for us devs.