I can't remember the last time I loaded FB on a computer. At this point it's clear that they care far more about the mobile experience than the desktop. Even if I'm sitting at my computer I'll still use my phone for FB.
Rebuilding our tech stack for the new facebook.com
261–270 of 489 posts
Re: Rebuilding our tech stack for the new facebook.com
#262Earlier quoted context omitted.
It has 96 .js scripts on a single page.
This used to be a bigger deal before HTTP/2 increased the number of concurrent requests to be virtually unlimited. Unless I'm missing something, it's "optimal" for a site to have many split files. If their JavaScript were 1 file, a change to a single character would mean the need to re-download every bit of JavaScript. Instead, with 96 files, it would mean 95 of them are still cached client-side and only 1 is need of…
It looks to me like these scripts are asynchronously-loaded components that load only once they're needed. In this case it looks suspiciously like they're nested and each script download causes another script to be downloaded once the component renders, which would make HTTP/2 a moot point. I can even watch the requests pile up in the dev tools when they're cached, so my guess is if they dumped everything in one file (or even 10 files, just not 95) they'd get noticeably improved performance.
Re: Rebuilding our tech stack for the new facebook.com
#263Earlier 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 know there have been a gazillion attempts at the latter and none has succeeded in any way comparable to the "free" sites. It's too bad, because if any of them were to ever achieve Facebook scale, the subscription price would probably be quite modest.
MeWe is freemium (paid extra stickers and storage) and is actually nice, at least the parts I've seen, a lot like Google+ - a friendly neighborhood full of photographers, chili enthusiasts etc.
Of course most people are going to go with twitter, but if you'd like something more like Google+ or what Facebook could have been you might want to try MeWe.
Re: Rebuilding our tech stack for the new facebook.com
#264Earlier quoted context omitted.
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…
Yeesh, you've badly misinterpreted my comment. Re-reading it, I'm partly to blame here. >That's not an argument to have no cabinets. This isn't the point I was trying to make. I didn't mean to piggy back on this part of the parent comment: "Have you worked on a platform that uses nothing but pure JS and fetch calls?" I meant to respond to this part of the parent: "they are tools for developers to streamline developme…
Well, if we take a step back from React and talk about a sort of data-first approach to UIs, I think they are definitely, much easier than the old jQuery era.
Mutable state, notably knowing all possible variations of said mutable state and how it relates to everything, is very difficult imo.
Is React the best implementation of this? Definitely not. It will evolve as time goes on. But I don't think I could ever manage state in the jQuery mutate-everything model again.
Re: Rebuilding our tech stack for the new facebook.com
#265A 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 management, frontend/backend separation, with an API in between, modular application structure, etc).
Apps don't load in 10ms, but they also can support some offline functionality given their independence from the server. Overriding browser behaviour and managing your own loading behaviour makes sense, because the default browser behaviour is not the experience you're striving for; it's not the app experience. These people are usually those who have worked on large web projects too— the developer experience that web developers have built for themselves in "userland" (JavaScript) is pretty good, and has evolved a lot to have features that makes developing the exact behaviour you want easier, and correctly iterating on a codebase, quicker.
A separate school of thought wish websites stayed true to their origins as enriched documents, and think trying to evolve them in the direction of applications is counter-productive to their true purpose as interactive surfaces to get and send information. If I am just going to scroll and see a few pictures, why do I need to download anything other than the structure of the page and the pictures themselves? If all the building blocks are already there, in the browser, why do people need to re-invent them and ship them as yet more JavaScript?
What should a website be though? The fact there isn't consensus about this is indication that there really doesn't seem to be a clear answer.
Per the document-like school of thought, facebook.com just keeps straying further and further away from the ideal, but as far as as the app-like school of thought goes, the new facebook.com is a pretty remarkable achievement.
Re: Rebuilding our tech stack for the new facebook.com
#266Earlier quoted context omitted.
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.
I don't think old reddit is ugly, though it takes some getting used to. Combined with RES for some minor enhancements (navigation etc) and it's great. It's similar to HN. Not fantastic design, but incredible information density and usability.
Not to go off on a rant about reddit here, but I still use the old reddit (old.reddit.com). The new reddit layout is horrid,. Using additional whitespace to improve readability, has done the opposite. Counter-productive iconography sizing and font styling, it goes on and on. Some of this is to make it more mobile-friendly. I get it, but as a singular design, it's worse for desktop users.
Re: Rebuilding our tech stack for the new facebook.com
#267Quite 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…
Looking at the internet today, I think we need to lower our expectations and be realistic. At least in the US. We are still driving 60mph on freeways and what trains we have do not travel at 300kph. Perhaps many of us flipped out when we only had 9600 baud modems, but you could get up, brew some tea, walk the dog, or read a book while waiting for a page to load. We all had so much more patience back then. Why do we n…
Because the underlying computing technology has gotten so much faster, unlike the case with cars and roads.
Re: Rebuilding our tech stack for the new facebook.com
#268Earlier quoted context omitted.
In France we have a Craiglist-like website. They recently moved to ReactJS : https://www.leboncoin.fr/ The website features didn't changed in between. It's basically a pagination + a search based on radius (so DB related) + name (so DB related) + categories (so DB related). The complete website could be build in pure HTML + CSS and a bit of JS + Ajax to refresh parts of it. But no, it's build with ReactJS, and it tak…
> 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?
Re: Rebuilding our tech stack for the new facebook.com
#269Earlier 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…
> the subscription price would probably be quite modest
Yes. It would be set to the minimum required to dissuade banned users (e.g. spammers) from continuing to create new accounts. This amount would still likely be well above cost.
Re: Rebuilding our tech stack for the new facebook.com
#270Earlier quoted context omitted.
>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…
Dark mode is very important. Do you use Flux by the way?
Supporting dark mode == 2 bad UI instead of 1 good one.
f.lux works well with normal UI, replicating natural light.