Live data from Hacker News

Rebuilding our tech stack for the new facebook.com

engineering.fb.com

331–340 of 489 posts

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

#331

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.

React, Vue, and Angular all use a virtual DOM, which means they're already deprecated 5 years from now. A virtual DOM is dumb. SASS, SCSS, LESS, etc are kind of great though. It sucks you have to compile them to css, but you can do this: .App { .Topbar { .Logo { color: green } } .Content { h2 { color: orange; } } } Saves a lot of time and effort.

Angular uses an incremental-dom not a virtual dom: https://github.com/google/incremental-dom

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

#332

Earlier quoted context omitted.

Remember when reached the limit for __TEXT and had to put code in sections that weren’t really meant for it: https://blog.timac.org/2016/1018-analysis-of-the-facebook-ap... ? Remember when they were taking to long to start up that they pulled stuff into a separate framework just so they could meet launch deadlines: https://blog.timac.org/2017/0410-analysis-of-the-facebook-ap... ? Remember when the app had 18,000 Obje…

The root cause of the problem is that they have too many people working on it, and that's obviously not a problem you can hire your way out of.

Perhaps they should hire engineers who have the explicit job of ripping out things that should not belong.

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

#333
post #323

Earlier quoted context omitted.

Food for thought- the value of each user is radically different when accounting for geographic (i.e. income) markets. For subscription to work, you either: 1- undercharge users from wealthier countries 2- price poorer users out of you platform 3- give up on the idea of worldwide adoption (Facebook scale, as you say) entirely 4- attempt to charge different amounts by country of origin, and watch your users cheat the s…

What you argue here could probably be said about half the companies admitted to any YC batch, and still there are successes. Maybe the glass can be half full too?

I think the catch is focusing on "Facebook scale" in terms of users on a social network. I am not aware of any YC companies at close to their scale (or potential to get there) without being ad driven, freemium or running on borrowed money.

Small social networks are fine for what they are and, I think, have much more flexible options for getting the bills paid.

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

#334

Earlier quoted context omitted.

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.

I don't understand how you think a 2-3 second load time is "fast" for such an enormous platform and the actual content the user sees. I sure get that Facebook is way more than that, but to think a page loading in 2-3 seconds is fast is something you could've gotten away with in 2000, but in 2020..? I genuinely don't understand why you find it quick.

Almost every fast website works with that speed for me. I'd like microsecond speed, but when there are websites which truly take 10+ seconds to fully load, 2 seconds is fine. I think that for me 5 seconds is when I'm getting a little bit worried about loading speed, less than 5 seconds is acceptable. Hacker news works only a little bit faster.

That said, I live in Kazakhstan and my typical ping to EU is 100 ms, so that might make my experience a little bit worse (it's 100 Mbps in theory). May be those who connect to those resources with 1 ms latency are getting much better typical experience, I don't know about that.

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

#335

Earlier quoted context omitted.

When you don’t use transpilers, you have to write ES5 code. No-one wants that.

Even in 2020? Isn't ES6 standard now across all supported browsers?

No. And "ES6" is itself a vague term. Browser support for features and syntax varies considerably and changes constantly.

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

#336
post #209

Earlier quoted context omitted.

I agree with you; however, the key disconnect is that Facebook is not a photo, video, post and message sharing website. It's a marketing platform intended to extract the most value out of you, the viewer, and transfer that value to Facebook and its advertisers. If you think of it this way, you can see how you may need 2MB of CSS: to battle the bots trying to scrape your information and replicate your network, to side…

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't find Facebook's data policies as egregious as the tech community does.

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

#337
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'.

Do you mean 2007 year CPU constantly throttling because of kilograms of dust on Windows 7 full of malware swapping on HDD?

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

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

Just because you don't care about a feature doesn't mean no one does.

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

#339
post #56

Earlier quoted context omitted.

What makes you think React/Angular are products to increase user experience? Of course you won't find that, they are tools for developers to streamline development and make maintenance easier. Have you worked on a platform that uses nothing but pure JS and fetch calls? I have, and there's no way to make sense of a project that has to deal with so many things.

Anytime you need to stream data to or from a client, like audio/video or data. Single page apps have a much better experience. From an architecture standpoint, it does also allow a much simpler separation of concerns. That said, it does it get used more often that it should and can take more time to build than a multi-page app.

Fucking gmail, for example.

The new SPA version is far, far slower than the old HTML version, and uses a truly insane amount of memory. I have 2 gmail tabs open, and according to Firefox's about:performance page, one is using 140mb of RAM, the other is using 95mb, and both are at the very top of the list in terms of CPU usage. Above even YouTube in both CPU and memory, which is itself fairly bloated.

It is absolutely disgraceful.

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

#340
post #215

Earlier quoted context omitted.

No, but signing up for an account and agreeing to the Terms of Service does. The not-logged-into homepage is 1.3mb. Still not tiny, but definitely not the same as the web app.

No it doesn’t. Informed consent is not the same as shoving a ToS/EULA in front of someone who may not have the legal or technological education to understand it or its consequences. From the Wikipedia definition[1] of informed consent (in medicine): > An informed consent can be said to have been given based upon a clear appreciation and understanding of the facts, implications, and consequences of an action. Adequate…

Fortunately, Facebooks ToS[0] is not full of legalese or jargon, and I'm sure anybody with enough technological education to sign up for Facebook can understand it too.

[0] https://www.facebook.com/terms.php

Post reply on HN