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

161–170 of 489 posts

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

#161

Post by lookdangerous »

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…

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

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

#162

Post by aeyes »

amelius wrote: post #13

Did they fix the "back" button? (I.e. if you click a link in the middle of a feed, then "back", do you get back at the same position in the feed?)

I think the Facebook feed is completely random on purpose to make it feel more up to date.If the app crashes on your phone then good luck on finding a post in your feed again.

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

#163

Post by the_other »

5cott0 wrote: post #94
dewey wrote: post #40

Earlier quoted context omitted.

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…

>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. I've always suspected that the Div-itis plaguing fb's website is a result of React's dependence on the 𝚘̶𝚟̶𝚎̶𝚛̶𝚞̶𝚜̶𝚎̶ misuse of higher order components.

It’s not.

HoCs don’t add nesting. If they do, you’re doing it wrong.

React <15 (2yrs old), did nudge you in the direction of div-itis, because all components that rendered something had to render a single root element. The more recent versions did away with that constraint. HoCs don’t even need to return markup; they’re functions which return functions. The general expectation should be that an HoC behaves like a factory for the components it wraps.

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

#164

Post by axyz »

suyash wrote: post #113

Atomic CSS is a bad idea, read more here https://www.browserlondon.com/blog/2019/06/10/functional-css...

nowadays is quite rare to write classes in pure html, using any framework like react, vue and similar we are used to pass classes in a JS environment. Obscure and minified class names can be imported from a package using a perfectly meaningful name, also the same set of classes can be exported with many different names to even better usage specificity with no cost in size.

We overcome most of those issues using a mix of postcss compose and css modules with a custom hashing solution based on the actual css rule content, this allowed us to have virtually infinite semantically named components with a css bundle size that tend to stabilize around 20/25kb gzipped for a very big e-commerce use case and I doubt any other use case would go much higher than that size.

https://github.com/utilitycss/atomic If you want to have a look (documentation needs some love, but the samples generated by the init do give a good idea of the concept)

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

#165

Post by dylkil »

panta wrote: post #51
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.

Stealing data about the users as accurately as possible requires more code than one would think.

>Stealing data about the users

its not stealing when the users agreed to it

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

#166

Post by notyourwork »

lancesells wrote: post #45
notyourwork wrote: post #32

Earlier quoted context omitted.

Agree whole heartedly, Facebook is a disgrace of a website and has been for years. Crazy how slow it is to load.

I think you could add Twitter and New Reddit to the list as well.

Yes! I use old.reddit.com and am not a twitter user so I don't have much exposure there.

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

#167

Post by ipython »

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 agree with you; however, the key disconnect is that Facebook is not a photo, video, post and message sharing website. It's a marketing platform intended to extract the most value out of you, the viewer, and transfer that value to Facebook and its advertisers.

If you think of it this way, you can see how you may need 2MB of CSS: to battle the bots trying to scrape your information and replicate your network, to sidestep the evil developers of adblocker software that threaten to destroy the sweet value transfer, the JS required to track every single movement you make both online and off, the A/B testing framework that allows you to determine how to most efficiently extract that extra 0.001% of valuable eyeball time, and so forth...

Connecting the world? Well, I guess that could be a nice side-effect...

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

#168

Post by lookdangerous »

janitor61 wrote: post #36
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.

The frontier of web design is apparently digital Rube Goldberg machines, existing probably more for job security rather than consideration for the end-user.

The all-but defacto use of javascript transpilers especially invokes the image of 'Rube Goldberg' machines.

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

#170

Post by saagarjha »

bzb3 wrote: post #65
edhelas wrote: post #60

Earlier quoted context omitted.

Everyone have 4G and Fiber, and a Core i7 and 16Gb of RAM :) Seriously…

That's not what I've said, and I somewhat agree with the original point, but this trend of wanting to cater to the lowest denominator rubs me the wrong way. Some guys think the web should be usable with a 50€ smartphone on GPRS, and I say no, because there's a middle ground.

Have you read anything about Facebook’s emerging markets? They want to cater to those people themselves!
Post reply on HN