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.
Rebuilding our tech stack for the new facebook.com
331–340 of 489 posts
Re: Rebuilding our tech stack for the new facebook.com
#332Earlier 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.
Re: Rebuilding our tech stack for the new facebook.com
#333Earlier 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?
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
#334Earlier 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.
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
#335Earlier 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?
Re: Rebuilding our tech stack for the new facebook.com
#336Earlier 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…
Re: Rebuilding our tech stack for the new facebook.com
#337I'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
#338This 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…
Re: Rebuilding our tech stack for the new facebook.com
#339Earlier 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.
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
#340Earlier 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…