As a front-end developer working on a similar type of web application in the mental health care space, Eric Bailey's article about performance of modern front-end frameworks really hit home.
I have to admit, as I assume a lot of other developers are in the same boat: I wasn't involved in setting up the architecture at my company. I'm currently working with a front-end framework that was picked by (non-front-end) developers who choose what aligned best with their coding practices and was similar to what they worked with before.
Do we over-rely on client-side rendered JavaScript? Perhaps we do, and I would love to be able to change this in the future by moving more towards native web API's. But the hardest thing is to convince stakeholders this is a worthy goal pursuing. With a small product team we have a lot of other projects that need attention and take up precious time. Refactoring our relatively young front-end stack might not get a high priority status (or any status at all) in the next few years.
I'm interested in solutions and ideas on how to tackle this problem as an individual developer. We are knee deep into a relatively popular client-side JavaScript framework, written in TypeScript. It's too complex in my opinion, but works fine, is part of an even bigger complex stack and is well-engineered. But I would love to lose the complexity, the potential barriers for our users, and move more towards native web solutions. I just have to figure out how to exactly do this.