undefined | Better HN

0 pointsdaliwali8y ago0 comments

The string building approach is the fastest, and it's the benchmark to beat. Any other abstraction is just piling more work on top and is generally just a more inefficient way to output HTML. The most lightweight pseudo-DOM implementations are still going to be significantly slower than string concatenation, and I have benchmarks to back up that claim [0].

Realistically, a server-side rendered JS app is also going to run most of the code that runs in the client per page load, so you would also have to consider initialization costs as well. I've had to work on one that took 100+ ms to render a static page (without accounting for network latency), which a static file server could render the same page orders of magnitude faster.

Long story short, most of the newer, non-string based JS server-side rendering does not consider performance a factor and consequently, perform pretty terribly. There are band-aid fixes such as putting a reverse proxy in front or running on super fast hardware, but it's like putting a band-aid on a bullet wound.

[0] https://github.com/daliwali/simulacra/blob/master/benchmark/...

0 comments

4 comments · 2 top-level

jasim8y ago· 1 in thread

I don't know who downvoted you or why, but yes - performance could be a problem as you pointed out. I prefer the React model simply because it is more programmer friendly. I would hope that performance is something that can be fixed, or at least the 80-20 rule will come to help.

daliwaliOP8y ago

Most JS server-side rendering never approaches anywhere near string concatenation performance, and I've tried. Whatever abstraction you use has to resemble string concatenation without doing much else, and it's really, really hard to not do much else. That's why embedded JS templates (EJS) is so fast, it just concatenates strings with some logic built-in to the template.

dbbk8y ago· 1 in thread

I'd imagine at the Times' scale they're not server-side rendering every page view though. I'm sure they'd be caching the HTML result at the CDN level.

daliwaliOP8y ago

Yes, they likely have reverse proxies that cache static content. But this won't work well for any sort of dynamic content, i.e. apps that require login, when data changes in real-time, etc.

j / k navigate · click thread line to collapse