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

401–410 of 489 posts

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

#401

Post by ryandrake »

hn_throwaway_99 wrote: post #42
starpilot wrote: post #30

Earlier quoted context omitted.

Comments like these remind of an old post on Slashdot, "What makes a good website?" Ask "geeks" what they prefer, it's usually minimalism, no images, consistent text styling. In the end, the ideal format becomes a text file without markup. I think we need to accept the opinions of techies are increasingly irrelevant in tech. It's like being fine artist getting paid to design flyers or a chef making burgers.

But, perhaps ironically, Slashdot was killed because its design updates made it more "designer-y" but much less usable. I remember one update in particular that added a ton of whitespace, gave it a "cleaner" look I guess, but it meant there were like 1/4 of the posts on the screen so it just took longer to peruse the comments. They also f'd up how they showed voting so it became much harder to just scan for popular c…

Yea, I left Slashdot after The Great Redesign, and other websites too for similar reasons. It seems to be this inevitable milestone in any website's (or, generally, software's) life:

- V1: Focused, works, fast, lacks some features, but good enough to grow

- V1.1: More features, still performs well, exponential community growth

- V1.2: Adds chat, messages, social, loses focus, performance starts to suffer, linear or slowing growth

- V1.3: Start loading up with ads, things are getting worse, usage plateaus or teeters

[EMERGENCY! HIRE THE DESIGNERS!]

- V2.0: Huge, unnecessary re-design [1] without community input. Most features gone. More ads. Community craters. This is the Fark.com "You'll get over it" phase.

- V2.1: Saturated with ads, founders have moved on, site is on autopilot, a shell of what it used to be.

1: https://www.youtube.com/watch?v=YnVeysllPDI

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

#402

Post by gfodor »

AgentME wrote: post #385
gfodor wrote: post #319

Earlier quoted context omitted.

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

Asking the server for new HTML means you can't show changes until you've done a roundtrip with the server. That means no optimistic rendering or immediate feedback for local changes, such as a comment being made or an option being set in a modal that opens up related settings, etc. I think it's extremely useful to have a system that allows the client to respond to changes locally on its own as the default case rather…

I’m aware of how react works. Server round trip time alone is not a reason to push to the client. Light is fast. Computers are fast. See: Phoenix LiveView

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

#403

Post by gfodor »

aylmao wrote: post #381
gfodor wrote: post #364

Earlier quoted context omitted.

I don't think you articulate this quite right: it's possible to both think that websites and web applications are worthy uses of the web, but also that many web applications would have been best engineered using 'classical' techniques from early websites. There's a strong argument to be made in Facebook's case, since the core value proposition of Facebook hasn't changed much since it's inception, and it began its lif…

> it's possible to both think that websites and web applications are worthy uses of the web, but also that many web applications would have been best engineered using 'classical' techniques from early websites. I agree with this. > There's a strong argument to be made in Facebook's case, since the core value proposition of Facebook hasn't changed much since it's inception, and it began its life as a server-side rende…

Yeah I mentioned in another thread but the Rails and Phoenix communities both reject the approach of thick clients driven by data access APIs, in both theory and increasingly in practice.

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

#404

Post by underwater »

runawaybottle wrote: post #272
3PS wrote: 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…

Let’s go on this tangent, why is Reddit’s frontend so sluggish and lacking quality of life improvements that should be in place by now? Surely they are hiring world-class devs, so what’s holding them back?

There are some brain-dead behaviours on Reddit's site. They do a JS render-then-fetch, which is the worst way to load data. They also seem to stick the data fetch inside a requestAnimationFrame, which means it only runs for foregrounded tabs. This is basic stuff. I don't see how this could be an accident.

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

#405

Post by Bnshsysjab »

My browser constantly pegs the CPU, Firefox performance manager indicates it might be Facebook but CPU metics never seem accurate. I use the new layout and swear the issue occurs after a tab has been left open for a long period of time (8-16 hours).

Anyone else experience this?

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

#406

Post by fastball »

gfodor wrote: post #314
Groxx wrote: post #89

Earlier quoted context omitted.

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

If you think websites from 1995 were driving the same levels of engagement that FB is in 2020 you would be really, very, extraordinarily mistaken.

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

#407

Post by SilasX »

notyourwork wrote: post #32
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…

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

Yes, in particular, for large discussions, when I get a notification about a comment I made on it, and I click to jump to that comment, it takes a while to load -- and in a way oddly proportional to the size of the discussion and frequency of the posts on that group.

I'll always see the very top post of the group, and its whole page load, and then slowly my discussion will come up and then it will scroll down to that comment; and if I do anything, that breaks the whole process.

It's like no one ever considered the concept of just loading a piece of the discussion, like reddit does.

What's more, there are all kinds of UX nightmares, like how, if I open the messenger in one Facebook tab, it opens in every tab, blotting out content I want to read.

Or how a FB livestream event will just randomly stop playing, giving me no indication that I'm lagging behind the current video -- I've done trivia nights that way and I only find out I'm behind after my team members suggest answers to questions I haven't heard yet.

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

#408

Post by paulryanrogers »

baddox wrote: post #343
3PS wrote: 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…

It's possible both are true: loads faster for newer computers/wider bandwidth, loads slower on older devices

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

#409

Post by pier25 »

mhoad wrote: post #384
pier25 wrote: post #305

Earlier quoted context omitted.

Some good React alternatives?

I’ve been plying around with lit-element lately and am finding it a much simpler experience overall. Likely a lot faster as well https://youtu.be/uCHZJy2n8Qs

Lit is excellent.

It's also possible to use htm with Preact for developing without a bundler if your target users support ES6.

https://github.com/developit/htm

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

#410

Post by Non24Throw »

aylmao wrote: post #265

A big point of contention in the comments here lies around the concept of what a website should be. A school of thought in web development believes the web to be the next frontier in application development. For them it makes sense that websites like this feel and act like apps, both as an end-user (animations, transitions without full-page reloading, rich dynamic content, etc) and as a developer (client-side state m…

> ... as far as the app-like school of thought goes, the new facebook.com is a pretty remarkable achievement.

I agree, they’ve done a fantastic job. Not only that, but as far as corporate engineering blogs go, this article is one of the best I’ve ever read.

Usually I either know the subject too well to learn anything, or I don’t know the subject well enough to understand what they’re saying in the amount of time it takes to read an article.

In this case, they found the perfect depth, they had great judgment on when and how to use visuals, and what they’re conveying is so clearly valuable.

If you usually skip the article and just go straight to comments, consider actually reading this one!

Post reply on HN