At Blockvue we have also had a lot of success going back to basics with vanilla js. Doing a large SPA in vanilla js is actually a charm these days and the result is extremely lightweight and fast. The SPA concept is sort of new, but if you really commit to not doing any server side page generation the result is so easy to manage. This also allows us to focus on having a fast crystal-based API backend to power our SPA and other services. We use a script to minify and deploy directly to s3/cloudfront, and then use lambda and some microservices for API endpoints. The turning point for me on this issue was when I realized that Google has been indexing dynamic js content since 2012 (I had no idea).
I'm still firmly of the opinion that nobody wants a SPA apart from the developers of that app.
I'd bet any of us could find a ton of weird and unintuitive things your app does, as well as it probably being slow to load, hard to use and brittle, in that you'll regularly put out an update that inexplicably breaks something for a day or two.
Add on top that massive extra expense of doing a pure SPA compared to the ease and simplicity of developing a mixed server/front side app, I have no idea why anyone sane ever signs off on a SPA.
And that's before we even get onto the vastly better tooling and development environments that server-side languages have.
It could be that our app is uniquely situated to avoid these issues, but we have had the opposite experience. Our API is versioned so things never get out of sync, the frontend code has no external dependencies so its as unbrittle as one could imagine, and we use aws API gateway to fake server side endpoints, so we dont have to do some weird url scheme. This could never work with a CRM though.
