I'm personally excited about things like turbolinks and phoenix liveview, which may provide a path out of this mess.
My guess is:
- Desire to offload more processing to end user machines to save compute
- More and more ads and user analytics in order to pick which ads to show
- More engineers that irrationally hate the simplicity of PHP
Duct tape on top of abstractions on top of duct tape in order to make a document platform behave like an application platform. Isn't it time to just replace web browsers with something that doesn't suck?
It's not the browsers that suck, it's what companies like Facebook do with browsers that sucks. And then all the other non-thinking middle managers in other companies who want to copy these terrible things because they're incapable of leadership.
They're great at rendering documents, yep. Applications delivery platform? Not so much, not until you tack a shitty language on top of it and then a bunch of crap on top of that language to make it remotely useful....
Be careful what you wish for. You just described native mobile apps.
Facebook of 12 years ago didn't have groups, marketplace, dating, live videos, stories, ...
It does way more things. In particular, there are a lot more interactive experiences. A decade ago, it just loaded a web page and nothing changed until you refreshed. Now live videos and other content types have streams of comments and reactions pushed to the client in real time.
It was so much better before when there just were less ways of doing what the website wanted and more ways of doing what you wanted with your browser and your computing power.
Many of these are anti-features I’d love to be able to turn off.
In fact, the original AJAX stuff in the early 00's typically did a primitive version of this since it was the most obvious solution during the era of server side rendering: just have the server render the new comment and slap it in as-is. Instead of extending the reach of that concept instead we shifted towards generic data access APIs and pushing all the complexity to the client, which has resulted in the gigantic mess we see.
I remember writing a basic client-side templating system in literally 2002 that naively regenerated the whole page in Javascript in response to AJAX API updates - you wouldn't notice unless you looked at the CPU being pegged and realize your computer was useless for multitasking if that site was open. It was clearly a bad idea. Little did I realize at the time that the next ~20 years of web software development would take that approach and just try to optimize it.
React only re-renders the components that have their own props or state change. There seems to be a popular misunderstanding that React that makes you re-render the whole page in response to changes, but that's not how it works.
So like, fat clients done badly? I had a Usenet client in 1993 that provided just as good of a forum experience as we have now, in 16 bits and 4 megs of ram.
(funnily enough, it actually parsed ES6 stuff fine, but was missing the `Object.fromEntries` method)
It’s huge and pretty impressive.
Too many people in this thread seem to be projecting that I'm somehow saying this complexity speaks poorly of Facebook's product or engineering. On the contrary, my point was that it's tragic that brilliant minds at Facebook are forced to build all the stuff described in the post just to achieve simple goals like "the page loads quickly", instead of focusing on other problems.
You have to draw the line somewhere, or it becomes meaningless.
tbh I think the vast majority of this engineering absurdity is to prevent teams from stepping on each other unknowingly, not for any direct end-user benefit. a lot of work goes into "make it so I don't have to work with X to get my work done" in all businesses, and... I dunno. it's not always a bad thing, but it does feel like quite a lot of waste.
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 features no one cares about? Also, for a photo and video sharing site, is CSS size really important? I just loaded the page and it loaded 13.2mb worth of data while making 249 requests. Thanks for cutting down your 400kb CSS file though I guess.
f.lux works well with normal UI, replicating natural light.
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.