I have spent the past year implementing such a "decoupled" multi-user single-page TypeScript/JavaScript application called "NarraFirma". NarraFirma is based on my wife's work on "Participatory Narrative Inquiry" explained in her free book "Working with Stories in Your Community or Organization". The application (designed by my wife) has more that forty "pages" all defined in TypeScript (and some JSON) using Mithril and D3 for the front-end GUI, which communicates to a backend using AJAX with JSON. The application backend can be either WordPress (via a PHP plugin) or via a small NodeJS server application in JavaScript. The backend code is maybe 1% of the frontend code in size. Data is primarily stored as messages consisting of triples in the WordPress database (one table per project, with one message per row, with database indexes) or as flat files under NodeJS (one directory per project, one file per message, with indexing and caching in memory). This message-oriented approach supports several users collaborating at once to modify the same "page" and reasonably quickly see updates without a page reload. Pages can include editable tables and editable 2D clustering diagrams. I'm currently working on improving the admin GUI for the WordPress plugin also using Mithril to make it easier to create multiple projects with various different access permissions. We plan on announcing the official release of the first major version in a few weeks. This project has been mostly a labor of love, although we hope in the long-term it will increase the demand for my wife's consulting services related to her book.

We have released all the code for the NarraFirma application under the GPL here:
https://github.com/pdfernhout/narrafirma

It's exciting to see WordPress improving as an application platform supporting JavaScript applications. It's hard to beat the "one click" install process of a web app that WordPress makes possible for tens of millions of users. While the NodeJS backend is more "efficient" than the WordPress backend as far as throughput per CPU cycle, the NodeJS backend is much harder to install and maintain for most people than the WordPress plugin and thus is "inefficient" of people's time in that sense. The stand-alone NodeJS version also does not leverage an existing community's or organization's user base in terms of people who already have signed up for an account on a WordPress site and who can be authorized easily to use the plugin rather than having to create yet another account on some new system. So, we expect that most of the application's users will install it via WordPress. I expect other developers may make a similar choice in the future for deploying JavaScript and mobile apps that need an easy-to-install-and-upgrade backend -- especially if that backend is intended to support projects for a specific community or organization.