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

171–180 of 489 posts

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

#171

Post by strictnein »

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…

Remember when working at a FAANG company was supposed to be some mark of pride?

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

#172

Post by pathseeker »

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.

>Some guys think the web should be usable with a 50€ smartphone

You went to the other extreme though. Most people in high-income countries don't even have FTTH.

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

#173

Post by tiborsaas »

edhelas wrote: post #50
tambourine_man wrote: post #39

Earlier quoted context omitted.

Sorry, I won’t take blame for that. Still haven’t found a use case for React/Angular or SASS/whatever. If I’m guilty of something is not recognizing the validity of those tools, as I’m sure there are. But 2MB CSS is simply inconceivable to me.

Big +1. I would be really interested to find one, only ONE, website where React/Angular was really bringing a better experience and better final product than a standard pure JS with simple Ajax system.

These are parallel things. Frontend frameworks let you build more predictable and solid apps than vanilla JS.

Indirectly it leads to better UX since the developers can spend more time on UI tweaking, than doing it vanilla.

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

#174

Post by strictnein »

duckfruit wrote: post #152
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...

The unquestioning supplication at the alter of 'engagement' (a sterile marketing term if there ever was one) is what lead to where we are now in the first place. This is an affliction that pervades the entire consumer internet sector, but the folks at facebook seem to have refined it to its fullest potential. The other day I got a facebook notification on my phone, which said something along the lines of "You have 4…

The new "Person X has posted a photo" notifications are the worst. Their abuse of the notification icon is getting ridiculous. It used to be focused on when someone interacted with something you had done, now it's just used to drive "engagement".

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

#175

Post by marcodave »

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…

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

Good counterpoint. Parent comment sound too much like the "TRUE programmers don't use data structures" old meme

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

#176

Post by infogulch »

dylkil wrote: post #165
panta wrote: post #51

Earlier quoted context omitted.

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

Using a website does not imply informed consent.

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

#178

Post by vbezhenar »

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…

Yep, works fast for me too. Random profile opens in 2-3 seconds max for me. But for some people websites are slow for some reason. I've heard complains about Gmail loading 30 seconds, while it takes 2-3 seconds cold start for me.

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

#179

Post by benbristow »

Drip33 wrote: post #127
scalableUnicon wrote: post #76

I rarely use Facebook, but when I do I use https://m.facebook.com instead of the main site. Similarly i.reddit.com and the HTML version of Gmail. Which aren't great looking, but pretty usable. I hope these versions will be maintained for a long time.

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

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

#180

Post by axyz »

Groxx wrote: post #158
axyz wrote: post #142

Earlier quoted context omitted.

we use this approach since more than a year with very good results. Regarding the data transfer it is not much of a problem because those classes usually get repeated a lot across the elements and having lot of repeated string is the best case scenario for gzip compression leading to basically no size impact. https://github.com/utilitycss/atomic This is the framework we developed to create atomic CSS component librar…

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 interesting to see when it actually may be a bad idea and when it is totally fine

Post reply on HN