4 ms·
They include a comparison with using ES6 Template literals (native JavaScript string interpolation), and saw 10x increase over React. The native string interpol
by ralusek 9y ago
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.
- foota 9y agoDoes anyone actually use vanilla JavaScript string literals for all their backend rendering?
- ralusek 9y agoCouldn'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.
- merb 9y agowell 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.
- jerven 9y agoAll 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.
- mstade 9y agoI 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.
- reificator 9y agoI have no personal experience with it, but Google's been toying with this project: https://github.com/PolymerLabs/lit-html https://github.com/PolymerLabs/lit-html Might help with some of those pain points
- pteredactyl 9y agoSame experience here.
- reificator 9y agoThere'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 https://github.com/PolymerLabs/lit-html
- allover 9y agoAnd hyperHTML [1] that preceded it and has near identical API. [1] https://github.com/WebReflection/hyperHTML https://github.com/WebReflection/hyperHTML
- reificator 9y agoThanks 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.
- styfle 9y agoI use a combination of both template string literals and React SSR streaming. https://github.com/styfle/react-server-example-tsx/blob/4586f3431b4bfd424179da3aad2c6adbddb0de10/src/server.tsx#L32 https://github.com/styfle/react-server-example-tsx/blob/4586...
- always_good 9y agoPretty sure it's just a control so that you can compare the templating performance to what's essentially just string concat.