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

191–200 of 489 posts

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

#191

Post by cosmotic »

gfodor wrote: post #47
janitor61 wrote: post #36

Earlier quoted context omitted.

The frontier of web design is apparently digital Rube Goldberg machines, existing probably more for job security rather than consideration for the end-user.

On the contrary, it does seem like jumping through these kinds of hoops has become strictly necessary if you are building web apps you would like to be responsive.

Are you sure? Media queries handle layout changes font size has been proportional to user agent since the beginning the web. A little SCSS preprocessing makes writing complicated CSS a lot easier.

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

#192

Post by otabdeveloper4 »

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…

Try it with a normal computer for normal people, not with your monstrous 'developer machine'.

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

#193

Post by gonehome »

I miss information density.

HN is great for this and you can change enough settings on reddit to get it where it used to be, but FB is really bad for it and Twitter is just ok (though with the tweet deck app you can get a lot on macOS).

In that FB screenshot you can see half of one post?

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

#194

Post by tomduncalf »

5cott0 wrote: post #94
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…

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

Since the component was introduced (React 16?) excessive wrapper divs are no longer necesssary fortunately!

Edit: not sure they ever were actually, I think you could just return props.children in most cases?

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

#195

Post by shp0ngle »

garaetjjte wrote: post #100
shp0ngle wrote: post #31

Earlier quoted context omitted.

I don’t get the hate for the new Twitter, to be honest. It loads fast, is simple, it’s to the point.

It's slow, requires JS, and fails around.. 50% of loads, I think?

ok I guess YMMV. It doesn’t fail for me, so I guessed it’s like that for everyone.

everything requires javascript nowadays, that’s just a default

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

#196

Post by 5cott0 »

5cott0 wrote: post #94
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…

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

All these things can be true and yet people will still frequently misuse them.

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

#197

Post by trevor-e »

What I find weird about the article is that they spend so much time talking about the performance of the new design, yet fail to include any hard numbers comparing the old vs new implementations. They do throw out a few numbers like how the new page only downloads 20% of the previous 400kb CSS for the homepage, etc, but I'm surprised to see no actual browser benchmarks for what they claim. How else would they be measuring this internally?

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

#198

Post by toohotatopic »

gfodor wrote: 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.

>What went wrong?

From yesterday:

https://news.ycombinator.com/item?id=23101483 Hello, World – Zerodha, India's largest stock broker

Facebook most likely has a different attitude towards software development.

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

#199

Post by 5cott0 »

the_other wrote: post #163
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.

It’s not. HoCs don’t add nesting. If they do, you’re doing it wrong. React <15 (2yrs old), did nudge you in the direction of div-itis, because all components that rendered something had to render a single root element. The more recent versions did away with that constraint. HoCs don’t even need to return markup; they’re functions which return functions. The general expectation should be that an HoC behaves like a fac…

So every React app can be effortlessly refactored to use whatever shiny new latest and greatest architecture abstraction React comes up with?

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

#200

Post by tenebrisalietum »

dewey wrote: post #40
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 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.
Post reply on HN