3 ms·
Just because Twitter does that doesn't mean it is the case everywhere else. It moves some of the rendering work from the backend (having to query the data and
by rrwo 4y ago
Just because Twitter does that doesn't mean it is the case everywhere else.
It moves some of the rendering work from the backend (having to query the data and generate markup) to the browser (query the API and generate the content based on the responses).
At my current job, it's made a significant improvement. The server returns compact JSON data instead of HTML, so it's easier to generate the data and uses less bandwidth.
It also looks faster for the user, because they change search parameters and only part of the page changes, rather than reloading the entire page.
As for "easier to maintain", that may be subjective. Code to generate a simple HTML template from results is replaced by JavaScript code to hit the API and generate the DOM. Although HTML5 templates makes that much easier.
- lucideer 4y agoI'm not saying it's impossible - glad to hear you've successfully implemented it in your workplace. I'm just saying that by-and-large it has the opposite effect to the stated intent. If most examples of a strategy make things worse, and only one person uses that strategy to improve things, then going around saying "everyone is doing it wrong" rather than questioning the strategy isn't particularly sound. I've build plenty of (small) client-side rendered UIs myself that lazy-load content; I know the trade-offs and I even believe I can achieve a performant outcome on my own. But that's anecdotal. In the wild, I have not seen a single major website improve perf. via lazy-fetched content rendering.
- rrwo 4y agoI was disagreeing with this statement: > My modern version of this is browsing with JavaScript disabled. Most of the sites that don’t work weren’t worth my time anyway. I think a lot of sites that require JavaScript are worthwhile. (Whether they are all well implemented is another matter.)