4 ms·

Facebook rendered just fine a decade ago. What changed between now and then, in terms of actual improvement to end user experience, to make it so slow this kind

Facebook rendered just fine a decade ago. What changed between now and then, in terms of actual improvement to end user experience, to make it so slow this kind of crap is needed? My guess is: - Desire to offload more processing to end user machines to save compute - More and more ads and user analytics in order to pick which ads to show - More engineers that irrationally hate the simplicity of PHP Duct tape on top of abstractions on top of duct tape in order to make a document platform behave like an application platform. Isn't it time to just replace web browsers with something that doesn't suck?

reaperducer 6y ago
Duct tape on top of abstractions on top of duct tape in order to make a document platform behave like an application platform. Isn't it time to just replace web browsers with something that doesn't suck? It's not the browsers that suck, it's what companies like Facebook do with browsers that sucks. And then all the other non-thinking middle managers in other companies who want to copy these terrible things because they're incapable of leadership.
- core-questions 6y ago
  > It's not the browsers that suck, They're great at rendering documents, yep. Applications delivery platform? Not so much, not until you tack a shitty language on top of it and then a bunch of crap on top of that language to make it remotely useful....
laggyluke 6y ago
> Duct tape on top of abstractions on top of duct tape in order to make a document platform behave like an application platform. Isn't it time to just replace web browsers with something that doesn't suck? Be careful what you wish for. You just described native mobile apps.
- core-questions 6y ago
  I do prefer native apps on mobile in many cases. At least the UI is idiomatic.
aeyes 6y ago
A lot more features? Facebook of 12 years ago didn't have groups, marketplace, dating, live videos, stories, ...
- core-questions 6y ago
  99% of that could have been implemented fine using the same technology. Live videos etc. are a scourge on the culture and I wouldn't miss them.
  - dbbk 6y ago
    I guess you think television is a 'scourge on culture' as well then? Get a grip.
lookdangerous 6y ago
'Desire to offload more processing to end user machines to save compute' strikes me as a real possibility
- badfrog 6y ago
  I think this is very unlikely. Making the page load one second faster pays Facebook more in terms of user retention and engagement than it costs them in server usage.
  - core-questions 6y ago
    Do Facebook users really quit Facebook because the page is too slow? Maybe a minute, but one second?
badfrog 6y ago
> Facebook rendered just fine a decade ago. What changed between now and then It does way more things. In particular, there are a lot more interactive experiences. A decade ago, it just loaded a web page and nothing changed until you refreshed. Now live videos and other content types have streams of comments and reactions pushed to the client in real time.
- dullgiulio 6y ago
  I really don't want a video to autoplay on the side of the screen when I'm reading some news article, for example. It was so much better before when there just were less ways of doing what the website wanted and more ways of doing what you wanted with your browser and your computing power.
  - badfrog 6y ago
    Sure, it's totally reasonable for somebody to dislike these features. I just object to the claims that it doesn't do anything substantially different than what it did 10 years ago.
- AlexandrB 6y ago
  > Now live videos and other content types have streams of comments and reactions pushed to the client in real time. Many of these are anti-features I’d love to be able to turn off.
- core-questions 6y ago
  None of that stuff has improved anyone's life worth a damn.
  - sanxiyn 6y ago
    What? For example, "X is typing..." message in messenger is great for pacing the conversation. It makes online conversation closer to offline conversation. Not all "dynamic HTML" stuffs are good, but some are indeed a big plus.
AgentME 6y ago
I don't think it's any of those. It's about interactivity in the webpage. Imagine you have the template for the HTML of comments implemented in PHP. Now if the user posts a comment and you want to show the comment on their screen before it gets to the server and back, then you need the template itself on the client. The template being on the server in PHP isn't any help. You could imagine the server filling the template in with dummy values, and then giving that to the client to fill in, but that only works for the simplest of templates where a few values need to be substituted in. You have to create another template language both the server and client understand if you have more complicated logic like many conditional or repeated parts. When you have one part of the UI the client needs to render on its own, it's easy to make a one-off solution for it, but in Facebook's case, I imagine they have a ton of UI that they want to be server-rendered but also renderable on the client. React is a template system that can run on both the server and client, and can live-update already rendered elements on the client as the user interacts with the page.
- gfodor 6y ago
  I agree with this assessment of the 'why' - and it's why I mentioned things like turbolinks and liveview. What you mention here seems like a convoluted solution to the problem, but I realize it's how it's done, and I've written thousands of lines of code doing it. In fact, the original AJAX stuff in the early 00's typically did a primitive version of this since it was the most obvious solution during the era of server side rendering: just have the server render the new comment and slap it in as-is. Instead of extending the reach of that concept instead we shifted towards generic data access APIs and pushing all the complexity to the client, which has resulted in the gigantic mess we see. I remember writing a basic client-side templating system in literally 2002 that naively regenerated the whole page in Javascript in response to AJAX API updates - you wouldn't notice unless you looked at the CPU being pegged and realize your computer was useless for multitasking if that site was open. It was clearly a bad idea. Little did I realize at the time that the next ~20 years of web software development would take that approach and just try to optimize it.
  - AgentME 6y ago
    Asking the server for new HTML means you can't show changes until you've done a roundtrip with the server. That means no optimistic rendering or immediate feedback for local changes, such as a comment being made or an option being set in a modal that opens up related settings, etc. I think it's extremely useful to have a system that allows the client to respond to changes locally on its own as the default case rather than treating local interactions like a strange one-off exception. React only re-renders the components that have their own props or state change. There seems to be a popular misunderstanding that React that makes you re-render the whole page in response to changes, but that's not how it works.
ahupp 6y ago
I worked on FB site performance a decade ago and I assure you it was abysmally slow.
- core-questions 6y ago
  I used it a decade ago and it was fine for an end-user, so why should I care? Raw advancements in CPU power would have been enough to keep the old backend going just fine.

reaperducer 6y ago

Duct tape on top of abstractions on top of duct tape in order to make a document platform behave like an application platform. Isn't it time to just replace web browsers with something that doesn't suck? It's not the browsers that suck, it's what companies like Facebook do with browsers that sucks. And then all the other non-thinking middle managers in other companies who want to copy these terrible things because they're incapable of leadership.

core-questions 6y ago
> It's not the browsers that suck, They're great at rendering documents, yep. Applications delivery platform? Not so much, not until you tack a shitty language on top of it and then a bunch of crap on top of that language to make it remotely useful....

laggyluke 6y ago

> Duct tape on top of abstractions on top of duct tape in order to make a document platform behave like an application platform. Isn't it time to just replace web browsers with something that doesn't suck? Be careful what you wish for. You just described native mobile apps.

core-questions 6y ago
I do prefer native apps on mobile in many cases. At least the UI is idiomatic.

aeyes 6y ago

A lot more features? Facebook of 12 years ago didn't have groups, marketplace, dating, live videos, stories, ...

core-questions 6y ago
99% of that could have been implemented fine using the same technology. Live videos etc. are a scourge on the culture and I wouldn't miss them.
- dbbk 6y ago
  I guess you think television is a 'scourge on culture' as well then? Get a grip.

lookdangerous 6y ago

'Desire to offload more processing to end user machines to save compute' strikes me as a real possibility

badfrog 6y ago
I think this is very unlikely. Making the page load one second faster pays Facebook more in terms of user retention and engagement than it costs them in server usage.
- core-questions 6y ago
  Do Facebook users really quit Facebook because the page is too slow? Maybe a minute, but one second?

badfrog 6y ago

> Facebook rendered just fine a decade ago. What changed between now and then It does way more things. In particular, there are a lot more interactive experiences. A decade ago, it just loaded a web page and nothing changed until you refreshed. Now live videos and other content types have streams of comments and reactions pushed to the client in real time.

dullgiulio 6y ago
I really don't want a video to autoplay on the side of the screen when I'm reading some news article, for example. It was so much better before when there just were less ways of doing what the website wanted and more ways of doing what you wanted with your browser and your computing power.
- badfrog 6y ago
  Sure, it's totally reasonable for somebody to dislike these features. I just object to the claims that it doesn't do anything substantially different than what it did 10 years ago.
AlexandrB 6y ago
> Now live videos and other content types have streams of comments and reactions pushed to the client in real time. Many of these are anti-features I’d love to be able to turn off.
core-questions 6y ago
None of that stuff has improved anyone's life worth a damn.
- sanxiyn 6y ago
  What? For example, "X is typing..." message in messenger is great for pacing the conversation. It makes online conversation closer to offline conversation. Not all "dynamic HTML" stuffs are good, but some are indeed a big plus.

AgentME 6y ago

I don't think it's any of those. It's about interactivity in the webpage. Imagine you have the template for the HTML of comments implemented in PHP. Now if the user posts a comment and you want to show the comment on their screen before it gets to the server and back, then you need the template itself on the client. The template being on the server in PHP isn't any help. You could imagine the server filling the template in with dummy values, and then giving that to the client to fill in, but that only works for the simplest of templates where a few values need to be substituted in. You have to create another template language both the server and client understand if you have more complicated logic like many conditional or repeated parts. When you have one part of the UI the client needs to render on its own, it's easy to make a one-off solution for it, but in Facebook's case, I imagine they have a ton of UI that they want to be server-rendered but also renderable on the client. React is a template system that can run on both the server and client, and can live-update already rendered elements on the client as the user interacts with the page.

gfodor 6y ago
I agree with this assessment of the 'why' - and it's why I mentioned things like turbolinks and liveview. What you mention here seems like a convoluted solution to the problem, but I realize it's how it's done, and I've written thousands of lines of code doing it. In fact, the original AJAX stuff in the early 00's typically did a primitive version of this since it was the most obvious solution during the era of server side rendering: just have the server render the new comment and slap it in as-is. Instead of extending the reach of that concept instead we shifted towards generic data access APIs and pushing all the complexity to the client, which has resulted in the gigantic mess we see. I remember writing a basic client-side templating system in literally 2002 that naively regenerated the whole page in Javascript in response to AJAX API updates - you wouldn't notice unless you looked at the CPU being pegged and realize your computer was useless for multitasking if that site was open. It was clearly a bad idea. Little did I realize at the time that the next ~20 years of web software development would take that approach and just try to optimize it.
- AgentME 6y ago
  Asking the server for new HTML means you can't show changes until you've done a roundtrip with the server. That means no optimistic rendering or immediate feedback for local changes, such as a comment being made or an option being set in a modal that opens up related settings, etc. I think it's extremely useful to have a system that allows the client to respond to changes locally on its own as the default case rather than treating local interactions like a strange one-off exception. React only re-renders the components that have their own props or state change. There seems to be a popular misunderstanding that React that makes you re-render the whole page in response to changes, but that's not how it works.

ahupp 6y ago

I worked on FB site performance a decade ago and I assure you it was abysmally slow.

core-questions 6y ago
I used it a decade ago and it was fine for an end-user, so why should I care? Raw advancements in CPU power would have been enough to keep the old backend going just fine.