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

201–210 of 489 posts

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

#201

Post by deanCommie »

pier25 wrote: post #106
edhelas wrote: post #58

Earlier quoted context omitted.

In France we have a Craiglist-like website. They recently moved to ReactJS : https://www.leboncoin.fr/ The website features didn't changed in between. It's basically a pagination + a search based on radius (so DB related) + name (so DB related) + categories (so DB related). The complete website could be build in pure HTML + CSS and a bit of JS + Ajax to refresh parts of it. But no, it's build with ReactJS, and it tak…

> And we should really go back and stop using those frameworks I think you are cherry picking. There are plenty of examples in the modern web of terrible React/etc implementations but that doesn't mean the approach in itself is bad.

Please name some.

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

#202

Post by karmakaze »

ipython wrote: post #167
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 side…

These views are aligned. A site that's fast and a pleasure to use advances both agendas. It's still a failure.

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

#203

Post by gkoberger »

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'm not a Facebook (the company) apologist by any means, and only use it because there's a few groups on it relevant to a company I own.

That being said, I find the new FB to be insanely fast. I don't even block ads on it.

I do agree Facebook was way better 12 years ago (I saw real updates and photos about friends, rather than companies and ads). But speed right now hasn't been the problem.

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

#204

Post by marcodave »

lgl wrote: post #107

Can we now sanely read comment threads with several hundreds or thousands of comments without clicking 200 times on "show previous comments" only to then lose all "progress" if we click somewhere else? Also looking at you Instagram.

One minute of contemplation for those who scroll for 10 minutes on mobile, to finally find something interesting to read/click, just to click by mistake the back button, and the whole timeline completely changed. Youtube recommendation feed also terribly guilty of that.

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

#205

Post by lukevp »

s-km wrote: post #150
5cott0 wrote: post #94

Earlier quoted context omitted.

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

React components aren't a 1:1 mapping to the DOM, so you could in theory have 50 HoCs wrapping a single component and it still only output one div or whatever. Also, HoCs have somewhat fallen out of favour over time, with hooks and the child as a function/render prop style becoming more popular. I think the only HoC I consistently use these days is `connect` from `react-redux`.

You can use hooks with redux now, so what’s the purpose of using connect instead of useDispatch or useSelector?

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

#207

Post by ccmcarey »

benbristow wrote: post #179
Drip33 wrote: post #127

Earlier quoted context omitted.

>Similarly i.reddit.com Try https://old.reddit.com It's so bad that people made Browser Extensions for Firefox[0] and Chrome[1] [0] https://addons.mozilla.org/en-US/firefox/addon/old-reddit-re... [1] https://chrome.google.com/webstore/detail/old-reddit-redirec...

Old Reddit is so damn ugly though apart from the Subreddits which have nice custom themes (although does make for a 00's Myspace-like inconsistent interface) The new Reddit definitely seems a lot faster nowadays than it did when it first launched.

I don't think old reddit is ugly, though it takes some getting used to. Combined with RES for some minor enhancements (navigation etc) and it's great.

It's similar to HN. Not fantastic design, but incredible information density and usability.

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

#208

Post by Groxx »

axyz wrote: post #180
Groxx wrote: post #158

Earlier quoted context omitted.

Your HTML is still undeniably larger than something with dramatically fewer class attributes though, if you minify the same way. Hence my "single page" vs "many" difference. gzip helps for sure, but I doubt ` ...` ends up larger than ` ...`.

there is of course a bit of difference in some use cases, my point is that in a real world scenario you often do not have vs but more something like vs so in the long run you tend to have more repeated strings across even completely unrelated elements and that usually balances out the possible increase in non gzipped bytes. But to be honest we did not had a detailed comparison with edge cases and it would be interest…

when you're less "component-y" with your styles, yeah, that happens pretty frequently. careful styling is mostly rare (like all careful things)... but atomic styling seems to make the savings of careful styling effectively impossible, though I absolutely believe it helps the less-careful (especially the least-careful) cases.

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

#209

Post by jawns »

ipython wrote: post #167
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 side…

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 can be largely cruft-free.

I know there have been a gazillion attempts at the latter and none has succeeded in any way comparable to the "free" sites. It's too bad, because if any of them were to ever achieve Facebook scale, the subscription price would probably be quite modest.

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

#210

Post by ben_w »

mnd999 wrote: post #135
jseliger wrote: post #116

Earlier quoted context omitted.

Facebook was more enjoyable to use 12 years ago We'll see what the data show. I have been reading comments about Facebook's supposed decline for as long as I've been aware of Facebook and yet their published numbers continually show greater engagement. https://jakeseliger.com/2018/11/14/is-there-an-actual-facebo...

There’s a lot of fake profiles though and I think a lot more than they’re prepared to admit. Even brazen binary options trading scam profiles don’t get removed - it appears that they’re happy as long as the number are going up.

They’re trying to police 2.5 billion accounts with 45 thousand employees (including HR, developers). I’m not surprised they stuck. Don’t get me wrong, it’s not OK for them to suck, but I’m not surprised given the 55,555:1 accounts:staff ratio.
Post reply on HN