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

301–310 of 489 posts

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

#301

Post by jimbokun »

asdkhadsj wrote: post #258
hbosch wrote: post #223

Earlier quoted context omitted.

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

People instinctively know the value of something when asked to part with their money. :D Yet they still spend their time on it. Huh.

People know their friends are not on App.net, but are on Facebook.

Or in other words:

https://en.wikipedia.org/wiki/Metcalfe%27s_law

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

#302

Post by rickyvetter »

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?

Hey - maintainer of ReasonReact here. We don't believe in mandating the tools that people use and there are plenty of good reasons to use TS, Flow, PureScript, Rust, etc. Folks on the Messenger Web team in Facebook like Reason as their language of choice. Reason is used heavily on Messaging code in the old facebook.com and in this rebuilt version.

The rebuilding of facebook.com was done quickly and involves almost every web team at Facebook. Almost all of these folks are familiar with Flow and only some are familiar with Reason. Asking every engineer at FB to learn Reason at the same time in addition to the already massive number of new things would have been adding unnecessary risk to this already incredibly risky project.

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

#303

Post by rhizome »

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.

Well, one primary benefit seems to be to make loading indicators/spinners into first-class components.

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

#304

Post by pier25 »

kolanos wrote: post #268
pier25 wrote: post #106

Earlier quoted context omitted.

> And we should really go back and stop using those frameworks I think you are cherry picking. There are plenty of examples in the modern web of terrible React/etc implementations but that doesn't mean the approach in itself is bad.

> There are plenty of examples in the modern web of terrible React/etc implementations but that doesn't mean the approach in itself is bad. If the creators of React can't get it right, then what hope is there?

React is bloated and slow, but there are dozens of frameworks other than React.

https://krausest.github.io/js-framework-benchmark/current.ht...

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

#305

Post by pier25 »

deanCommie wrote: post #201
pier25 wrote: post #106

Earlier quoted context omitted.

> And we should really go back and stop using those frameworks I think you are cherry picking. There are plenty of examples in the modern web of terrible React/etc implementations but that doesn't mean the approach in itself is bad.

Please name some.

Some good React alternatives?

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

#306

Post by ng12 »

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…

Thank you. This is one of the first things I tell people in my web-dev workshop. They're probably not going to be building websites, they most likely will be building web applications.

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

#307

Post by pier25 »

the_other wrote: post #225
speedgoose wrote: post #123

Earlier quoted context omitted.

They aren't though. You have a cache.

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

If you have code splitting many chunks will remain the same.

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

#308

Post by rhizome »

freedomben wrote: post #226
jdavis703 wrote: post #216

Earlier quoted context omitted.

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.

Related: "I don't watch or even own a TV" [watches Netflix/YouTube on a laptop six hours a day]

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

#309

Post by mgraczyk »

schkkd wrote: post #64
pier25 wrote: post #12

> as little as possible I just opened FB with the cache disabled and it downloaded 5.85MB (19.76MB uncompressed). Most of it happens after the page has rendered, which is great, but that's a lot of stuff. There are 13.74MB of uncompressed JavaScript.

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.

Not so, refresh the page to see how large the second download is (much smaller)

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

#310

Post by lawn »

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…

> It's really sad that in 2020, 10k+ engineers can't make a photo, video, post and message sharing website that is not a pain to use.

Too many cooks spoil the stew.

I might even go so far to say that 10 engineers would have a larger chance of success than 10k+ engineers.

Post reply on HN