Hacker News Reader

Comment by merb | Hacker News Reader

well wasn't that clear? Isn't something like a Template Engine quite CPU intensive? Things were node.js performce poorly?

View on HN

They include a comparison with using ES6 Template literals (native JavaScript string interpolation), and saw 10x increase over React. The native string interpolation actually came out just behind serving straight static files. JavaScript CPU performance is actually quite high among interpreted languages.

So to answer your question more specifically, no I don't think it is clear. What this is specifically isolating as the performance problem is that using React as a template renderer on the backend is not performant, not because of NodeJS performance, but because React is realistically not really specialized for this.

Does anyone actually use vanilla JavaScript string literals for all their backend rendering?

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.

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.

I have no personal experience with it, but Google's been toying with this project: https://github.com/PolymerLabs/lit-html

Might help with some of those pain points

Same experience here.

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

And hyperHTML [1] that preceded it and has near identical API.

[1] https://github.com/WebReflection/hyperHTML

Thanks for the heads up, I've definitely seen that one credited but I thought it used to not use template literals. Clearly it at least does now.

EDIT: Yeah, looks like it's always worked that way. Maybe I was thinking of another lib.

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.

well depends, I doubt that native js string interpolation is written in javascript at all. so basically it is javascript, but since you are using the native interpolation you probably go trough a c interface. or some kind of extremly optimized path.

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

I don't understand how this can be your takeaway since you can see how fast Pug is in comparison. The article is clearly singling out React's slow render speed.

Reply on news.ycombinator.com