To make matters worse, they are using Django. I can't take the EU serious any more.
This is not a situation where you'll have thousands of people editing the same document, that'd be insane with Django for sure - but at general collaboration tooling with <100 (random number I made up) editing, Django is unlikely gonna be the bottleneck
What part of your document editor needs to be backed by a relational database?
Why use an MVT system if you don't need the Model part of it?
I see, in your broad and experienced mind, document editors don't have users, permissions, and the whole document management itself, comments on lines/threads, reactions on comments
Seriously, theyre all as cookie cutter perfect usecase for Django as you can get, but I guess you haven't actually thought about the domain and just wanted to take a dumb on other devs with intern-to-junior level insights
And in this case, as would be obvious from thinking about it, the only part it's not suited for is the live syncing of the text edit on the frontend, which is one one small part of the whole.
Now go check if they're doing it or you're just suggesting from the dunning kruger symptom.
TLDR: C++, WASM, and some form of GRPC with C++ on the server side as well. Because you need a language that's fast, can contain high complexity and large programs without collapsing (which is a short list of languages) and can work fast for the bits that need speed.
But thanks for answering honestly.
There's new languages where it's a bit of an open question still where they lie on the spectrum. Go would be one of them. I'd guess somewhere between Python and Java. Javascript I would argue is between perl and python. And Rust ... well ... good question.
An office suite is a gigantic application, which will need feature upon feature upon feature upon feature. If you want it working on the web, I'd propose something like C++ and WASM.
Edit: also appears to be based in the eu, how fitting for this thread.