Live data from Hacker News

Rebuilding our tech stack for the new facebook.com

engineering.fb.com

341–350 of 489 posts

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

#341
post #66
post #33

Earlier quoted context omitted.

Looking at the graphical design changes, they haven't rolled this out yet.

They did roll this new interface on some users (like me), and this new experience genuinely sucks. It's easy to guess what happens under the hood: "Legacy" programmers implemented working solution. A newcomer comes into the company, doesn't really give a shit about the company because he is #XXXX, follows textbook processes, has a very nice pay-check so no pressure, and decides to rewrite because "code sucks". A seco…

This is not a big bang rewrite. All the technology here is stuff that's been built over the last decade. Haste is a decade old, React is 8 years old, GraphQL is around 7 years, Relay must by 5 years old by this stage. This is simply bringing them all together.

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

#342
post #316

Earlier quoted context omitted.

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.

I think you're unfairly trivializing it by labeling it a "website".

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

#343
post #122

I'm actually really surprised by the number of comments in this thread about how the new redesign is slower. I've had it since yesterday and it genuinely feels much faster and more responsive than the old Facebook UI - though, to be fair, that's not a huge accomplishment give that the old UI would take forever to finish painting or respond to input. I'd consider it a success, especially when compared to the disaster…

Considering Facebook engineering has gone into detail about how the new site is much faster and transmits much less JS and CSS, I would be a little surprised if the opposite is true. I tend to not implicitly trust HN comments about things being extremely slow, because for whatever reason there are so many of these complaints I’ve never experienced myself. I still haven’t even had performance problems with Electron apps, and those seem to be widely panned on HN as having abysmal performance. They work fine for me.

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

#344
post #65
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.

The web should be usable on a 28.8k modem from the mid 90s. Why wouldn't it be?

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

#345
I don't think there's a single piece of software (if you can call facebook's website a piece of software) that I've used longer than facebook.com. I was one of the earliest users in 2004 and have had an account the entire time. It's really interesting, in sort of a morbid way, to see how it really has become a shittier experience every year. I'm sure it's hard to get right and I wouldn't claim to know better than them but it is quite amazing that they have so many engineers being paid so much money and the product from a usability standpoint manages to get worse. I really think that will be their ultimate downfall one day.

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

#346
post #343
post #122

I'm actually really surprised by the number of comments in this thread about how the new redesign is slower. I've had it since yesterday and it genuinely feels much faster and more responsive than the old Facebook UI - though, to be fair, that's not a huge accomplishment give that the old UI would take forever to finish painting or respond to input. I'd consider it a success, especially when compared to the disaster…

Considering Facebook engineering has gone into detail about how the new site is much faster and transmits much less JS and CSS, I would be a little surprised if the opposite is true. I tend to not implicitly trust HN comments about things being extremely slow, because for whatever reason there are so many of these complaints I’ve never experienced myself. I still haven’t even had performance problems with Electron ap…

For me, it is decidedly slower and clunkier

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

#347
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…

I think the biggest assumption you're making here is that most people care about ads - and they don't. Fundamentally, when I'm scrolling through Facebook or Instagram or Reddit or whatever, I just don't care that I see ads while I'm scrolling. I'm not going to pay $1/2/3/4/5 a month to avoid something I don't care about, and that's really only the value add of a subscription-based service. I'd also say most folks don…

I'd really like to understand how does one not care about ads. To me it's like potholes on road. It would require terrific willpower to ignore them.

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

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

>This is 100% incidental complexity. The article talked a lot about their new dark mode feature, how they wouldn't have been able to implement it in their old tech stack, and how they were able to reduce their CSS size while adding a dark mode. But is dark mode all that important? Even as a developer I don't care at all about FB having a dark mode, did they really need to rewrite their entire site to implement featur…

"I don't care about this feature" !== "nobody cares about this feature." I feel like this is a fallacy a lot of programmers (myself included) tend to fall into, but it's a dangerous trap.

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

#349
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…

Your comment made me remember being amazed by BigPipe and how damn fast that made the app (still called page back those days).

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

#350
post #40

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…

> Things like ... are probably not decided on and implemented by the engineering team but are coming down as a requirement from the top

Yeah, welcome to the real world. We _all_ have to handle requirements like that, except maybe when we build our portfolio site

Post reply on HN