Hacker News Reader

Comment by core-questions | Hacker News Reader

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?

View on HN

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.

> 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....

> 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.

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.

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.

> 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.

None of that stuff has improved anyone's life worth a damn.

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.

A lot more features?

Facebook of 12 years ago didn't have groups, marketplace, dating, live videos, stories, ...

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.

I guess you think television is a 'scourge on culture' as well then? Get a grip.

> 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.

I do prefer native apps on mobile in many cases. At least the UI is idiomatic.

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.

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.

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.

I’m aware of how react works. Server round trip time alone is not a reason to push to the client. Light is fast. Computers are fast. See: Phoenix LiveView

> 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.

So like, fat clients done badly? I had a Usenet client in 1993 that provided just as good of a forum experience as we have now, in 16 bits and 4 megs of ram.

I don't have to imagine any of that, I used it. In fact, it's basically how HN works now, and we seem to be commenting fine.

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

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.

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

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.

Do Facebook users really quit Facebook because the page is too slow? Maybe a minute, but one second?

Reply on news.ycombinator.com