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

221–230 of 489 posts

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

#221

Post by gonehome »

reaperducer wrote: post #23
motoboi wrote: post #5

I have been using Facebook for like +10years. Facebook used to be reference for speed and usability. I left it ~4 years ago. Last day I entered again for curiosity. It's so sad. Strange interface, slow, unresponsive. It's sad.

Facebook used to be reference for speed and usability On web, for a while. Remember when Facebook's iPhone app came out, it was a disaster. It was so slow, I could open the app, then take the elevator down to the basement of my building, drop off some outgoing mail, and return to my apartment before it finished updating the news feed. It was legendary in its time for its slowness. At first, nobody complained because…

Steven Levy talks about this in his new book (which is really good).

Zuckerberg's focus on mobile first was a major focus to save the company and ultimately a success story (this happened right after the IPO).

Their big mistake was non-native applications.

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

#222

Post by rhizome »

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…

That's probably something that can be measured: if the profile/wall fills out over several seconds, when do the ads appear? First, before everything else? In that case it would be cynical, but I agree that they might monetize the delays by ensuring ads appear before anything else.

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

#223

Post by hbosch »

jawns wrote: post #209
ipython wrote: post #167

Earlier quoted context omitted.

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

> 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, too, loved App.net. Alas, seems that people won't even pay a couple bucks a month to see what their friends are eating for lunch.

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

#224

Post by andirk »

tenebrisalietum wrote: post #200
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…

They already did: https://mbasic.facebook.com .

90's versions, like mbasic, of almost every website is better. More content, less noise. Mbasic could still use a flaming tag though

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

#225

Post by the_other »

speedgoose wrote: post #123
schkkd wrote: post #64

Earlier quoted context omitted.

That's pretty much size of a mobile app. But the thing with web apps is that they are downloaded every time and hence the outcry.

They aren't though. You have a cache.

Facebook release multiple times a day (or they did), so the browser cache is irreLevant.

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

#226

Post by freedomben »

jdavis703 wrote: post #216
OkGoDoIt wrote: post #118

Earlier quoted context omitted.

For a certain kind of developer who drinks a certain kind of Kool-Aid, sure. Personally I am a lot less productive when I’m forced to work on a React codebase. It’s kind of like using an ORM, it can feel like it makes things easier, but really you end up fighting with the abstraction more than if you had just learned the underlying technology itself.

The thing is, every place I've worked that was against ORMs or frontend frameworks wound up evolving their own half-documented, half working framework. I find it's easier to spend as much time learning the abstraction as the underlying technology, and then that knowledge can be ported from system to system.

My experience too. The whole "we don't use a framework" sounds great but it always turns in to some sort of home grown framework that is poorly documented, has bugs, and isn't open source so you can't take it with you when you leave.

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

#227

Post by vosper »

dgellow wrote: post #78
vosper wrote: post #25

I saw no mention of Reason or ReasonReact. I thought they rewrote Messenger in Reason, and so I figured facebook.com would be next. Did Reason fall out of favor or something?

Was Reason ever more than an experiment?

ReactReact just had a release (0.8) a few days ago, so it's apparently not dead

https://github.com/reasonml/reason-react/blob/master/HISTORY...

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

#228

Post by Octoth0rpe »

lukevp wrote: post #205
s-km wrote: post #150

Earlier quoted context omitted.

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?

Two big reasons: Values passed via connect can be validated by proptypes, and by using connect you can mount your component without redux. That may make sense for building shared components that may be used with redux in one part of your app, but without redux in another part. There are a lot of smaller reasons to prefer connect, but those are the big ones to me. FWIW I use both approaches depending on needs.

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

#229

Post by jaywalk »

smhinsey wrote: post #105
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…

All this and the chronological sort mode is still totally broken. Third post in my feed is 3 days old followed by one 2 hours. Total joke.

They really don't want you sorting chronologically. That negates The Algorithm™.

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

#230

Post by Benjammer »

aerovistae wrote: post #117
Benjammer wrote: post #95

Earlier quoted context omitted.

Humans have been using physical and mental systems to manage complexity for eons, I simply can't understand this argument. React doesn't automatically fix spaghetti code if you don't know how to organize a platform-sized code base efficiently in the first place.

This is like saying "cabinets don't help organize a kitchen if you don't put anything in them" -- I mean, duh, you have to use it right. That's not an argument to have no cabinets. There's a reason nearly ALL major web applications rely on a _framework_....rails, django, laravel, you name it. These exist because it's really hard to organize vanilla code without a framework. React and FE JS are no different. If you're…

Yeesh, you've badly misinterpreted my comment. Re-reading it, I'm partly to blame here.

>That's not an argument to have no cabinets.

This isn't the point I was trying to make. I didn't mean to piggy back on this part of the parent comment: "Have you worked on a platform that uses nothing but pure JS and fetch calls?"

I meant to respond to this part of the parent: "they are tools for developers to streamline development and make maintenance easier." I often find that the most ardent React fans will see "not React" and jump immediately to "spaghetti of vanilla js and fetch calls," with no further questions asked.

I'm trying to argue against React dogmatism, I'm not arguing in favor of "no framework" dogmatism.

Post reply on HN