[vbo]

The overall experience feels (and is) faster as you only need to update the DOM, not recreate it from scratch, so you're not rerendering the whole page. There's also less processing required on the server as you're only requesting the piece of data you know will change and the response comes back faster. The history API makes going back and forth seamless, as if you were browsing the "classical" way. But this comes with additional complexity which is sometimes not dealt with correctly.

[tommek4077]

Only if you use 8k$ Macs. Not for normal people.

[johnisgood]

Perhaps it is just poorly written, or maybe it is the animations that are making it look like it is slower than it should be. I created a simple website where I update parts of the DOM, and it is super fast. I have the opposite experience on known websites.

[bmeski]

Totally agree. I implemented a page with tons of posts on it that will hide the posts before the provided cursor in the url and I simply show hide them with display: none. Even if it’s 100 posts hidden, the images are lazy and clicking “show” unhides all of them immediately. If new posts come in we simply append to the top of the parent container with basic DOM apis.

The app were replacing with this page is heavy react and there’s a long visual stutter during the show hide because it has to render them all. Not simply show/hide. They actually load more bits to lazy load the posts in JS than to simply send the html and hide/show.