I do this. It’s surprisingly effective, both in actual performance and developer productivity. The one area where it is useless however is for mutating DOM. It’s easy enough to create DOM using template strings, but if you say need to render something and then mutate it later on in you render function, it becomes terrible since you either have to do tricky string manipulation, actually create the DOM and use methods to mutate it, or use some framework at which point you may as well just give up on template strings altogether.

But for any case where you’re basically going in the one direction, i.e. data -> DOM and not changing things once rendered it’s great.

There's the lit-html[1] project, which is still fairly new.

It uses tagged template literals to render to the DOM, so on the server side it could fall back to vanilla string interpolation.

[1]: https://github.com/PolymerLabs/lit-html

I use a combination of both template string literals and React SSR streaming.

https://github.com/styfle/react-server-example-tsx/blob/4586...

Couldn't tell you, but it's not really relevant. The post I'm replying to says that it should come as no surprise that NodeJS template rendering is slow, and I just meant to point out that the article is quite specifically isolating ReactJS rendering as slow, and has nothing to do with NodeJS or JS at all.

All no, but quite a bit, in our prototype for our next gen codebase. Was quite nice because we had a lot of 'legacy' JSPx code that we transformed into JS code using a bit of one off programming with some clean up afterwards.

Pretty sure it's just a control so that you can compare the templating performance to what's essentially just string concat.