[SiVal]

This seems to imply something about the client side of your strategy that I wasn't aware of (but maybe I should have realized) that probably matters: that your clients will (almost?) all be Windows machines running the new-MS-strategy MSVC native apps written (at least partly) in JS, where "JS" on Windows now (as in Node) means Chromium specifically.

In a situation where you get to build the client all the way to the hardware, you're like Apple. You can probably get more advantage than most by matching client and server more deeply than the usual talk-to-the-API level. In your case, it sounds as though it's Microsoft's TS-in-Chromium spanning both.

[apaprocki]

Yes to Chromium, not so much for anything specifically MS-related. Using Chromium as a low-level GDI replacement lets you leverage higher-level constructs and work in web-space to implement rendering, and TS nicely spans between client-side Chromium and server-side V8.

Note -- it doesn't need to be specifically Chromium or specifically Node. It just so happens that Node bet on V8 and Chromium is embeddable, so you can get even more leverage out of using the two together. (We actually also use TS with server-side Spidermonkey as well, so TS has definitely proven itself as a better way to interop at the tooling level across these different implementations.)

This all comes with a Titantic-iceberg-sized caveat, however. Keeping up with Chromium is difficult. Any embedder is not Google and embedded use cases are not the web. You can leverage all the collective work put into making the web work quickly, but you have to back it up with your own resources to leverage the source and make changes and contributions where necessary.[1] It's definitely a balancing act!

[1]: https://github.com/bloomberg/chromium.bb/branches/active