Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rebuilding our tech stack for the new facebook.com

engineering.fb.com

Post reply on HN
Print view View original

311–320 of 489 posts

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

#311

Post by EGreg »

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…

Can you please compare the speed of https://yang2020.app/events ?

On the mobile web or desktop, either one. (We're running it off of one server, it might get the HN effect, we'll see.)

We have been building our own, open source social networking platform and we have tried to make a lot of things more efficient while doing so. The site I linked to didn't minify any files or optimize images. However, it loads things on demand as needed, and even lazy-loads entire components.

Is it faster than Facebook? We have our own component system, not React.

Here is a site that did minify and combine all files: https://intercoin.org

And here is the platform we used: https://gitub.com/Qbix/Platform (warning: not all of it is documented, but enough, at https://qbix.com/platform/guide).

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

#312

Post by sopromo »

bzb3 wrote: post #52
pier25 wrote: post #12

> as little as possible I just opened FB with the cache disabled and it downloaded 5.85MB (19.76MB uncompressed). Most of it happens after the page has rendered, which is great, but that's a lot of stuff. There are 13.74MB of uncompressed JavaScript.

With a standard 4G/FTTH connection that's less than one second of download time.

If I have to download 5mb of js for every page I visit on my phone I would be out of data in less than 15 days.

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

#313

Post by gfodor »

cosmotic wrote: post #191
gfodor wrote: post #47

Earlier quoted context omitted.

On the contrary, it does seem like jumping through these kinds of hoops has become strictly necessary if you are building web apps you would like to be responsive.

Are you sure? Media queries handle layout changes font size has been proportional to user agent since the beginning the web. A little SCSS preprocessing makes writing complicated CSS a lot easier.

I didn't mean responsive in the CSS sense, I meant responsive as in the "not slow to load" sense, which is the point of this article.

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

#314

Post by gfodor »

Groxx wrote: post #89
gfodor wrote: post #48

Earlier quoted context omitted.

take a screenshot of facebook - it's a website.

I can run Linux in my browser. Is Linux a website? https://bellard.org/jslinux/ You have to draw the line somewhere, or it becomes meaningless.

sure, for me the line is clearly on the side of "scrolling through boxes of text and basic commenting" = website, since that was the case in 1995. my point was that if you took a screenshot of facebook today and when it launched, other than some cosmetic improvements, you couldn't tell me which version warranted extreme dynamic application logic and which was just a dumb server generated HTML page. the point being that it shouldn't be necessary to do all the stuff in this post to get this result, but it is, because our field has failed to build better generalized solutions to these problems.

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

#315

Post by huijzer »

hckr_news wrote: post #257
jawns wrote: post #209

Earlier quoted context omitted.

Imagine this: A "free" ad-driven social networking site that brings in gigantic revenue, but that has to pay thousands of high-priced engineers to implement all of the cruft you just described. versus ... A subscription-based, non-ad-driven social networking site (perhaps operating as a member-owned cooperative?) that brings in much more modest revenue but that also can operate with many fewer engineers because it ca…

People just don’t want to pay for social networking platforms. We’ve been conditioned to think that these things should be free.

I think social media is as social as sitting in a bar where everyone tries to get you to listen to their stories and look at their photos. To respond to someone in the bar you can send a text, which they might respond to somewhere in the future. Therefore, I am not planning to pay for it, since it is not adding (much) value to my life.

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

#316

Post by gfodor »

gorgoiler wrote: post #283
gfodor wrote: post #4

This is 100% incidental complexity. It's painful to consider that this level of sophisticated engineering is needed to render a website quickly in 2020. What went wrong? I'm personally excited about things like turbolinks and phoenix liveview, which may provide a path out of this mess.

You have a ten digit user base that you need to engage, so you have a four (five?) digit engineering team that somehow needs to coordinate their patches in a way that doesn’t cause the complexity of the site to explode. It’s huge and pretty impressive.

I never said it wasn't impressive. I was saying that it's sad that this level of incidental complexity is necessary to run, what is for all intents and purposes, a website.

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

#317

Post by AgentME »

core-questions wrote: post #20
gfodor wrote: post #4

This is 100% incidental complexity. It's painful to consider that this level of sophisticated engineering is needed to render a website quickly in 2020. What went wrong? I'm personally excited about things like turbolinks and phoenix liveview, which may provide a path out of this mess.

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

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

#318

Post by uryga »

goatlover wrote: post #278
the_other wrote: post #231

Earlier quoted context omitted.

When you don’t use transpilers, you have to write ES5 code. No-one wants that.

Even in 2020? Isn't ES6 standard now across all supported browsers?

that might well be, but just recently i got a crash report and it turned out the user had some "unsupported" version of Safari... and i'd rather transpile/polyfill than be that site that asks you to upgrade your browser to use it

(funnily enough, it actually parsed ES6 stuff fine, but was missing the `Object.fromEntries` method)

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

#319

Post by gfodor »

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

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

#320

Post by todd3834 »

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…

At a company I used to work for, we worked so hard to make sure our web app would load extremely fast… just to end up losing the battle with the data and analytics team for analytics scripts. They used a tag manager (tealium) which by itself can be used for good but it ultimately gave the other team the ability to overload our site with 3rd party scripts.
Post reply on HN