Rebuilding our tech stack for the new facebook.com • Hacker News Board

Re: Rebuilding our tech stack for the new facebook.com

#391

Post by core-questions » Fri, May 08, 2020, 10:53 PM UTC

reaperducer wrote: post #27

core-questions wrote: post #20

Earlier quoted context omitted.

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 o…

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 th…

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

Re: Rebuilding our tech stack for the new facebook.com

#392

Post by core-questions » Fri, May 08, 2020, 10:53 PM UTC

badfrog wrote: post #217

core-questions wrote: post #20

Earlier quoted context omitted.

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 o…

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

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

Re: Rebuilding our tech stack for the new facebook.com

#393

Post by core-questions » Fri, May 08, 2020, 10:54 PM UTC

ahupp wrote: post #386

core-questions wrote: post #20

Earlier quoted context omitted.

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 o…

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.

Re: Rebuilding our tech stack for the new facebook.com

#394

Post by core-questions » Fri, May 08, 2020, 10:54 PM UTC

aeyes wrote: post #159

core-questions wrote: post #20

Earlier quoted context omitted.

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 o…

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.

Re: Rebuilding our tech stack for the new facebook.com

#395

Post by core-questions » Fri, May 08, 2020, 10:55 PM UTC

badfrog wrote: post #219

lookdangerous wrote: post #161

Earlier quoted context omitted.

'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?

Re: Rebuilding our tech stack for the new facebook.com

#396

Post by core-questions » Fri, May 08, 2020, 10:55 PM UTC

laggyluke wrote: post #87

core-questions wrote: post #20

Earlier quoted context omitted.

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 o…

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

Re: Rebuilding our tech stack for the new facebook.com

#397

Post by core-questions » Fri, May 08, 2020, 10:56 PM UTC

gfodor wrote: post #319

AgentME wrote: post #317

Earlier quoted context omitted.

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 templ…

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 serve…

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

Re: Rebuilding our tech stack for the new facebook.com

#398

Post by core-questions » Fri, May 08, 2020, 10:56 PM UTC

AgentME wrote: post #317

core-questions wrote: post #20

Earlier quoted context omitted.

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 o…

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 templ…

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.

Re: Rebuilding our tech stack for the new facebook.com

#399

Post by toast0 » Fri, May 08, 2020, 10:57 PM UTC

kungato wrote: post #389

tarsinge wrote: post #383

Earlier quoted context omitted.

There is something between 10ms and 10s, especially when it's after the initial load. The point of contention is not the website vs webapp debate, it's more that a webapp doesn't have to be that bloated. The whole point of SPA initially was better use experience, notably through faster response time and loading.

If you are not building for the first time experience I do not understand why you would have a problem with initial load of a web app taking seconds. It's like an install just way faster. No one uses facebook only once and so shouldn't care. Android apps are so shit the "slow" webapps are still miles ahead. I do not understand why android google drive app takes 5 seconds to load

> I do not understand why android google drive app takes 5 seconds to load.

The Android UI framework is simply amazingly slow. Instanciating widgets takes forever, and you have to do it in the UI thread.

Re: Rebuilding our tech stack for the new facebook.com

#400

Post by SilasX » Fri, May 08, 2020, 11:08 PM UTC

dewey wrote: post #40

raphaelj wrote: post #19

Quite sincerely, it's a total failure. I got the chance to try the new interface, and it's so slow that it's barely usable. It's even slower than the old website, that was already painfully slow. Loading a random profile takes 8 seconds. Opening a messenger discussion takes 6 seconds. It reminds me of the new Reddit website. Facebook was more enjoyable to use 12 years ago. It's really sad that in 2020, 10k+ engineers…

I guess they probably could build a nice and fast website if it was up to them. But there's probably a lot more requirements than just that. Things like https://twitter.com/wolfiechristl/status/1071473931784212480... are probably not decided on and implemented by the engineering team but are coming down as a requirement from the top. This is probably the case for a lot of other decisions that slow down the page ("We…

Heh just yesterday I was trying to click on a zoom meeting link for a Facebook event, and it wasn't working for whatever reason, so I tried to pull the url out of the page with the inspector, and I saw the same thing -- hopelessly deep nesting of the element, with the URL hard to find and its text version obfuscated ... and that's not even an ad!