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.

As an analogy: some pop-up books are amazing works of art. But reading would be frustrating if every book was a pop-up book.

I sure wish companies wouldn’t abuse data privacy so we could instead care about user preferences for app-like functionality, but we don’t yet live in a world like that.

In any case, this argument is operating at the wrong level of abstraction, the issue here isn't the distinction between these two things conceptually, but if there would be less incidental complexity overall if what are typically called web applications took a different approach to implementing their features, while still maintaining the same user experience.

It's hard to look at all of the crap you need to do to get a functioning web app working to not think there must be a better approach.

I agree with this.

> There's a strong argument to be made in Facebook's case, since the core value proposition of Facebook hasn't changed much since it's inception, and it began its life as a server-side rendered 'website.'

Yes, but I assume that's from the perspective of the value the site brings to you, not in general and not to everyone. If someone solely gets value from facebook.com as a site to send and receive information to/from friends and the world, then yeah, it hasn't changed much.

Facebook today offers a richer experience and that might be part of its value for other people. On facebook.com you can IM a friend, while watching a video in a PIP window and engaging in a real-time conversation on the the comment thread of an event post. You can then switch back and forth between an online marketplace and a streaming service without losing the state of your chat window. The ability to do these things are part of the value proposition for many users that facebook.com now offers today, and delivering that value can be harder with a solely SSR'd website.

> there would be less incidental complexity overall if what are typically called web applications took a different approach to implementing their features, while still maintaining the same user experience.

If you've figured a way that's better do share! I'm sure there's instances in the wild, but I don't think an experienced engineer would ship their own client-side networking in JavaScript if there was a better way to achieve what they want without shipping any more JS.

> It's hard to look at all of the crap you need to do to get a functioning web app working to not think there must be a better approach.

To be clear, you can get a functional "hello world" web app with a single line a code (specifically, thanks to the fact html is very permissive with improperly formatted documents). Everything afterwards depends on the decisions you make, for the experience you want. Is getting rid of that 200ms flicker between page full page loads worth the 500ms it might take takes to load and initialize your client-side routing library? Is making your site available offline worth the effort of setting up all the extra PWA business? Some will think so, some will not.

In any case, this argument is operating at the wrong level of abstraction, the issue here isn't the distinction between these two things conceptually, but if there would be less incidental complexity overall if what are typically called web applications took a different approach to implementing their features, while still maintaining the same user experience.

It's hard to look at all of the crap you need to do to get a functioning web app working to not think there must be a better approach.

On the other hand, if you built these things with lighter-weight techniques, these separate parts of the application could be opened in separate browser tabs or windows (without your computer grinding to a halt from loading multiple instances of a gigantic SPA.)

Even rails 6 ships with webpacker by default and they have included an API mode for a while...

Phoenix live view on the other hand is totally awesome and goes along with your point

I agree, they’ve done a fantastic job. Not only that, but as far as corporate engineering blogs go, this article is one of the best I’ve ever read.

Usually I either know the subject too well to learn anything, or I don’t know the subject well enough to understand what they’re saying in the amount of time it takes to read an article.

In this case, they found the perfect depth, they had great judgment on when and how to use visuals, and what they’re conveying is so clearly valuable.

If you usually skip the article and just go straight to comments, consider actually reading this one!

The whole point of SPA initially was better use experience, notably through faster response time and loading.

The Android UI framework is simply amazingly slow. Instanciating widgets takes forever, and you have to do it in the UI thread.

Perhaps application-like school of thought probably allows for more user manipulation. metrics and tracking.

In practice things like Twitter and Facebook, interactive programs, should really be just that - programs you run. If the interface is nigh static and the purpose is content interaction rather than primarily consumption you should be opening the Facebook program that gives you this interface and uses its client / server communication to feed messages to and from the interface, not provide the whole thing over the wire spread across document addresses.

And they are that on mobile. Who uses Facebooks mobile website? Everyone uses the app. The contention only exists on "desktop" OSes because Windows and OSX don't provide a UX workflow to push an app at user (at least they didn't when it mattered) the way a mobile site can. And that the app environments on both were way worse than the Android or iOS SDKs for making a dumb GUI for something like Facebook.

I do, just like I do with every app that might feel too comfy reaching out to my contacts. Not to mention how resource hungry it is.

If you think MFC, VCL, .NET are worse experiences than Android SDK you really never coded for Android.

But seriously, where do you draw the line between enriched documents and apps?

CSS? JS used for styling? d3 for visualizations? WebGL?

Websites have gotten so bloated that the only sane future I see is serving people unix + x in wasm.

Tech has this global problem of technology products never being what they say they are on the tin. It's like those front-end/back-end iceberg memes -- what the user wants and what the business wants are just barely in alignment. This needs to end.

[1]: https://amturing.acm.org/award_winners/corbato_1009471.cfm

It's like a bad copy of "the new Twitter" and even Twitter isn't really good.

The only end-user software from FB is Messenger Lite. It's quick and does what I expect it to do.

Even the voice chat is good and I didn't expect a lite version of a messenger to have it.

The neverending quest to reduce information density is a usability disaster, despite the misheld belief that cleanliness = usable. Zooming out on the new fb interface, to restore some information density, leaves a comical amount of whitespace. Wells Fargo has turned its desktop interface into a giant stretched mobile app. Nothing is hyperlinks that support right click or new tab anymore.

https://medium.com/signal-v-noise/why-i-love-ugly-messy-inte...

The cluster f of the old old facebook interface was beautiful.

They generally work fine. They just annihilate battery life and processing capacity while doing so.

Startup takes tens of seconds.

Typing messages with formatting is visibly sluggish.

And in common cases it just crash's and restarts.

Memory usage is also an issue if you compare it to the usefulness of Slack.

Just communicating with my team shouldn't take 1/5th of my laptop's resources.

If they need to talk straight away they can call :)

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.

They've probably just accepted that consuming is more popular than producing, though.

Surely they are hiring world-class devs, so what’s holding them back?

I recommend everyone the old.reddit.com experience while it's still available. There's browser plug-ins that force the subdomain everywhere on reddit

Facebook Engineering has a notorious "not invented by me" culture, it's not unique there but a lot of our "world-class" engineers are just acting economically rationally and hole-digging on some new bespoke framework or tool to cement their position in the company. You end up with a massive amount of churn and over-engineered vanity projects, and it's manifesting downstream in basically every product we've turned out for the last five years. That's why the applications bloated and terrible.

The joke inside the company is that it used to be "move fast and break things" but now it's "breakfast, vest and move things around". It's really an engineering culture of decadence and waste these days.

What makes you think that?

Reddit seems like a place where the kind of experienced and talented people needed to turn it around could make a lot more money (via stock grants in addition to salary) and frankly have a lot more impact, at any of FAANG.

I've not seen anything to indicate that Reddit is hiring, or trying to hire, "world-class devs".

Ultimately, reddit made no attempt to lean into the the thing that might attract world-class people to come there: a passion for the product. Or, at most, any attempts made were surface level. Some of the best engineers I've worked with are at reddit. They just happen to be outnumbered, and some have golden handcuffs on.

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 can't make a photo, video, post and message sharing website that is not a pain to use. We collectively failed as a profession. If one needs 2MB of CSS for such a website, there is clearly a problem.

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 sidestep the evil developers of adblocker software that threaten to destroy the sweet value transfer, the JS required to track every single movement you make both online and off, the A/B testing framework that allows you to determine how to most efficiently extract that extra 0.001% of valuable eyeball time, and so forth...

Connecting the world? Well, I guess that could be a nice side-effect...

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 can be largely cruft-free.

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.

I can see that if you consider ads to be inherently offensive, you would notice them wherever they appear, and be annoyed.

But that's not where most people are.

I wouldn't say it's as bad as potholes on the road, since ads are more predictable.

Think of it as the difference between a for-profit bank and a credit union. The bank exists to maximize returns for its shareholders. The credit union exists solely for benefit of its members. So the credit union isn't going to try to employ sneaky fine-print fees, because that's not what the members want.

In a similar vein, you might not care about ads and may have trained yourself to ignore them, but you might care about performance, which is sluggish because of all the cruft, or you might care about privacy, or you might care about being marketed to in more subtle ways than display ads.

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 system mercilessly

5- go freemium, and suffer the same fate that news organizations do- find that far too few are willing to pay to go ad-free, stick ads back into the free version, and end up leaking data anyway

I suppose 4 might be the most feasible option, but once it is obvious that some people pay more for the exact same value, they are likely to assume that the product has less value than it actually does, feeling that they are being ripped off.

In short, there is probably a good reason that paid services will never reach Facebook scale.

At ardour.org, we offer 3 tiers of subscriptions ($1, $4 and $10 per month) named to target different economic conditions. We also offer a single fixed payment with a suggested but editable cost based on OECD data about the cost of dining out.

We're not trying to maximise revenue, which is perhaps an important difference between us and, oh, Facebook :)

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

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.

Yet they still spend their time on it. Huh.

Or in other words:

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

The reason I bring it up is that in changing user norms, it's much less helpful to think about them in stimulus response terms, than in terms of modelling other users behavior - which itself is guided by limitations on our capacity to process information, and heuristics which though adaptive are poorly adjusted to the modern media landscape. So people didn't flock to facebook initially because they were conditioned to prefer it - they used it because (in addition to offering a peek into the lives of others, it was cool). Conditioning is an important part of why people become addicted to the reward loops of social networking sites, but it's an insufficient explanation for their appeal and often misapplied.

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.

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.

That's by design, of course - it benefits Facebook greatly that its herd is addicted, and unlike people addicted to alcohol, nicotine or other substances - there's not even another supplier they can turn to: It's either feed your addiction or suffer withdrawal symptoms.

And I think the success rate of quitters (as a percentage of those who actually want to quit) is also comparable, at single digit percent.

The actual ads on FB desktop are the newsfeed ads, which you see as you scroll.

Things like https://twitter.com/wolfiechristl/status/1071473931784212480... are probably not decided on and implemented by the engineering team but are coming down as a requirement from the top. This is probably the case for a lot of other decisions that slow down the page ("We need this A/B test framework", "this needs to be hidden to increase retention",...)

You can still do that. A bare-metal dedicated server with an 4-core CPU, 32 GBs of RAM and SSDs can be rented for that price with unmetered bandwidth and it'll be more than enough to sustain that level of traffic.

I've always suspected that the Div-itis plaguing fb's website is a result of React's dependence on the 𝚘̶𝚟̶𝚎̶𝚛̶𝚞̶𝚜̶𝚎̶ misuse of higher order components.

HoCs don’t add nesting. If they do, you’re doing it wrong.

React <15 (2yrs old), did nudge you in the direction of div-itis, because all components that rendered something had to render a single root element. The more recent versions did away with that constraint. HoCs don’t even need to return markup; they’re functions which return functions. The general expectation should be that an HoC behaves like a factory for the components it wraps.

Regardless of upgrade paths, React <15 would still let you use HoCs w/out adding excess element nesting.

I don’t contest that the older React tended towards div-itis if you weren’t careful with how you used it. But this thread was about Higher Order Components (or wrapper functions), which don’t have any inherent effect on nesting.

Also, HoCs have somewhat fallen out of favour over time, with hooks and the child as a function/render prop style becoming more popular. I think the only HoC I consistently use these days is `connect` from `react-redux`.

Edit: not sure they ever were actually, I think you could just return props.children in most cases?

Yeah, welcome to the real world. We _all_ have to handle requirements like that, except maybe when we build our portfolio site

It's a structural problem and little more: the website (and app) is their main money-maker, so they're going to give it a disproportionate amount of resources.

Imagine you hire ten thousand people to lay one railroad track. [note; see end of post] If any single one of them doesn't contribute directly in some way, you'll fire them. This seems kind of strange, doesn't it? Sure, it probably requires more than a single person to lay a track. But ten thousand people to lay one? How is that supposed to work, mechanically? This would be enough to warrant shareholder revolt.

Now, the railroad track gets broken a few hundred times, maybe they hammer it enough to make it twice as long, whatever. It now no longer resembles a railroad track. Certainly no train could go across it. Send a few hundred people to go ask the managers of this project for a replacement track. Okay, we're now at...maybe a tenth of people having contributed? Repeat this process until everyone's contributed. Maybe the manager gives different groups different materials for the track to fuck with them, whatever. But somehow, every single person manages to not get fired.

What's the outcome look like? You have a single railroad track, probably not even well-fit for the job (sparks fly whenever trains run on it; maybe it causes them to tilt, so on), but it's laid! And ten thousand people are employed!

It's the same thing with a website. You can't put a terabyte onto a user's device every single time they load your website; you just can't. So you have a window of performance you have to hit. Between ten thousand people trying to have things thrown onto user devices? Good luck making anything resembling 'decent'.

It's the same problem that Dave Zarzycki noted in his talk about launchd[1], but worse. Instead of 512 megabytes shared between some random abstract parties you can basically ignore, it's <10MB shared between ten thousand coders, translators, graphic designers, users, managers, etc. Does something seem strange about this?

[note]: This is the appropriate comparison here; at the scale of 'Over ten thousand people working on one program', it's grunt work, not art, science, or even programming. There's a word for implementation-grunts that's fallen out of favor in the past few decades: coders. This was seen as distinct until recently.

[1] https://youtu.be/SjrtySM9Dns?t=255

Instead, the book proposes The Surgical Team, i.e. about 10 people taking specialized roles, with the system being the product of the mind of a few key people. I wonder how well this aged.

Also, the set and scale of features in the Facebook app makes it literally one of the most complex webapps out there. It's far more than just multimedia posts+messaging -- it's a marketplace, dating, games, apps, groups, pages, and more. Nobody's "failing". And the 2MB of CSS was the "before" uncompressed. The "before" compressed was 400 KB, and this update appears to reduce it to under 80KB compressed. That's 96% less than the 2MB you're complaining about, more than an entire order of magnitude.

So Facebook seems to be improving here, no? I fail to see what is a "total failure" or "clearly a problem".

This is an anecdotal datapoint that is insanely useless in the real world, but the fact that it is the top comment is typical of this site.

I haven’t noticed it being slower either, it’s certainly not fast, but it’s not really something I notice either.

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.

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.

I'm not convinced they are successful at that either.

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.

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 arguing against using a FE framework to organize FE code, you're basically saying "We don't need frameworks in general! All code should be inherently organized!" That's not realistic. It's just not feasible when you have a large project.

Good counterpoint. Parent comment sound too much like the "TRUE programmers don't use data structures" old meme

>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 development and make maintenance easier." I often find that the most ardent React fans will see "not React" and jump immediately to "spaghetti of vanilla js and fetch calls," with no further questions asked.

I'm trying to argue against React dogmatism, I'm not arguing in favor of "no framework" dogmatism.

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.

Basically I've found that if you're doing something useful which could be done with jquery but would probably have had subtle bugs due to a combinatorial explosion of possible states, you can usually use react in that context to make a cleaner, faster, and less buggy version of that same UI that is faster to develop and easier to reason about (and thus better for the end user, since software that works consistently is more valuable than software that mostly works as long as you don't breathe wrong near it).

If you're looking for examples where a single-page app is better than server-side-rendered HTML with some javascript sprinkled in to make certain components more interactive, though, I can't help you. The successful use cases I've seen for react are of the "use it as the way you sprinkle additional functionality into your server-side-rendered HTML" type.

Browser API's and CSS have all improved drastically since then, so pure JS and Ajax isn't as bad. I still avoid frameworks for small things just to keep pages lightweight. But for heavyweight projects, if you don't use an established framework, you just end up with a shitty home-grown framework anyway, because the alternative, teams of developers working on the same site with no frameworks, is even worse.

It is incredibly frustrating to run into an issue with a home grown framework and have to ask around only to discover that the person who wrote the part you're having trouble with left the company 2 years ago and no one else understands it.

Fixed some UI bugs, made it straight forward implement features like better animations & replays, performance improved by removing stuff like a constant timer for UI & having a global mousemove handler tracking mouse coordinates

Indirectly it leads to better UX since the developers can spend more time on UI tweaking, than doing it vanilla.

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; }
      }
    }

Technically correct. The point is, it's not native.

That being said, I find the new FB to be insanely fast. I don't even block ads on it.

I do agree Facebook was way better 12 years ago (I saw real updates and photos about friends, rather than companies and ads). But speed right now hasn't been the problem.

On the other hand, navigation and clicking around is still sooo slow. My 60-year-old aunt called me and asked if she needs a new pc because facebook makes her laptop fans spin like crazy. I couldn't explain to her about all this react-redux-graphql thing and frankly, she doesn't care. All she cares is that facebook is slow and all she does is post photos and talk with friends like she did 10 years ago.

The 2MB was for the old site. The new site loads 20% or 400KB.

I wouldn't even want to know how it runs on those.

The mobile app seems to be just fine though, perhaps they want to push people to use that.

Apparently this is way more economically rewarding than performance for Facebook.

With that in mind, who cares if the site is slow (btw this is the only complaint of your rant). If the software requires a few devs to change and a few eyes to maintain, they can literally scale as much as they want. And actually now they’re probably in a way better position than they would if they had developed a super performant but unmaintainable site.

The quote, premature optimization is the root of all evil, is still very much valid imho.

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.

Facebook is still pretty slow even on a Ryzen 3900x with 32GB of 3600mhz RAM. It's a lot better than it used to be though.

We'll see what the data show. I have been reading comments about Facebook's supposed decline for as long as I've been aware of Facebook and yet their published numbers continually show greater engagement. https://jakeseliger.com/2018/11/14/is-there-an-actual-facebo...

The other day I got a facebook notification on my phone, which said something along the lines of "You have 4 new messages". Of course, thinking it was from my friends I opened the app to look at them. 3 of my 4 "messages" were notifications for friend requests from people I had never met. The last one was a photo someone had posted of cake she'd baked (not to me specifically, just in her feed). To someone sitting at her desk at facebook, looking at an engagement metrics chart, the notification would seem to have served its purpose - another data point, another person enticed to open the app in response, engagement maximized. But of course, this was deception. I found this experience distasteful enough to disable notifications entirely - probably another data point for their metrics team - and annoyed enough to complain about in an HN comment.

For example - Flame wars increase engagement, even if people feel drained and frustrated afterward.

I understand why it's a useful metric - It's particularly valuable if your business model depends on time-on-site to sell ads.

But I wouldn't recommend them as a proxy for enjoyment by any means.

Do you think this might have anything to do with the fact that, as an advertising company, it's crucial that they are able to tell companies that engagement is increasing?

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 need instant gratification with FB and other social media? Maybe, or maybe not /s.

And all these SPA, client-side rendered, sites seems guilty of this. You navigate to a page, and it loads up "instantly", except you see nothing but gray placeholder images. Then content starts loading in, but haphazardly. You see a link you want to click, and you go to click it, when BAM! it jumps down 37 pixels because some stupid widget just loaded above it on the page.

I really hate the modern web. Not the look of it, or the styling. The mechanics and slowness.

Or perhaps people involved in a revamp/redesign/unification should be well compensated to the point where they are unlikely to leave in the middle of a multi-year project. I have a feeling based on my experience that a lot of these bad rebuilds are a result of too many engineers and designers coming and going.

Design updates can be useful, but just like for engineers, "beware lots of highly paid people looking for something to do".

- V1: Focused, works, fast, lacks some features, but good enough to grow

- V1.1: More features, still performs well, exponential community growth

- V1.2: Adds chat, messages, social, loses focus, performance starts to suffer, linear or slowing growth

- V1.3: Start loading up with ads, things are getting worse, usage plateaus or teeters

[EMERGENCY! HIRE THE DESIGNERS!]

- V2.0: Huge, unnecessary re-design [1] without community input. Most features gone. More ads. Community craters. This is the Fark.com "You'll get over it" phase.

- V2.1: Saturated with ads, founders have moved on, site is on autopilot, a shell of what it used to be.

1: https://www.youtube.com/watch?v=YnVeysllPDI

Geeks prefer speed, like everyone. There are plenty of papers that show that a reduction in latency improves the conversion rate. And it's does not have to be ugly to be fast.

"Geeks", as a class, will tend to focus on technical issues before aesthetic ones. Looking at that fact and immediately equating it to an absurd extreme is a fun game, if you don't care about describing reality. I know some accomplished engineers who are also good designers, and vice-versa.

Second, if my professional opinions are not being taken seriously, that usually means one of two things: I'm too far out over my skis, or am in the wrong place with the wrong people. Especially so if you feel like a chef making burgers.

Of course, if "in total control" and "irrelevant" are the only two states of being one sees, I suppose I see how you get there.

Consumers (apparently) prefer form over function (or at least, they are more easily fooled into thinking the more form, the more function)

On the mobile web or desktop, either one. (We're running it off of one server, it might get the HN effect, we'll see.)

We have been building our own, open source social networking platform and we have tried to make a lot of things more efficient while doing so. The site I linked to didn't minify any files or optimize images. However, it loads things on demand as needed, and even lazy-loads entire components.

Is it faster than Facebook? We have our own component system, not React.

Here is a site that did minify and combine all files: https://intercoin.org

And here is the platform we used: https://gitub.com/Qbix/Platform (warning: not all of it is documented, but enough, at https://qbix.com/platform/guide).

This is all on my 8core/32gb workstation. I can't even imagine how much utterly useless crap they are running in JS to make that kind of experience.

On the bright side it does mean I am weaning myself off as keeping a pinned tab open is a non starter so I can't just have a quick refresh. And I'll be fucked if I'm installing their apps on my phone.

So I guess thanks needs to goto the FB engineers for making their new website so utterly garbage that the tiny dopamine hits driven by the FB algorithms are worth less than the pain caused when using the site.

I use mbasic.facebook.com as much as possible. Occasionally I'll use m.facebook.com. I've had the mobile apps uninstalled for ages.

Were you using a machine with a gigabit connection, 32GB RAM, and 10th gen intel cpu like the devs?

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 takes seconds to search a simple item on it.

To compare, just try the same search on the Dutch equivalent, MarktPlaats, https://www.marktplaats.nl/. The experience is way snappier, way lighter, the features are the same, and it's just HTML + CSS + a bit of JS.

We made a mistake with React/Vue/Angular. 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.

If the creators of React can't get it right, then what hope is there?

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

It's also possible to use htm with Preact for developing without a bundler if your target users support ES6.

https://github.com/developit/htm

It was super ugly, but it did the job. Now it's super ugly, but it steals my focus at every opportunity, refreshes parts of the UI I'm about to click, or has select inputs that love to play hide and seek with my cursor. It's a UX nightmare.

I must say their new payment system is nice. But boy do we have to suffer when looking for something to buy now.

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

Reddit, on the other hand, is an absolute clusterfuck from layout and usability perspective. The choices made were not made for monetary gain, they are simply really bad design choices that for one reason or another have not been fixed.

On the phone it's even worse, a large number of subreddit now require that you use the app... unless you just go to old.reddit.com.

The point of the reddit redesign still alludes me. Sure the old design isn't mobile friendly, so I can understand that they would want to fix that. Then again they mainly use the redesign to push the app. And the new design isn't that mobile friendly anyway. Certainly not if you value battery life. Comments are now also hidden by default, which is just weird. But you have infinite scroll, which seems to be the main selling point. I'm not sure I needed that though.

It's incredible that ugly old.reddit.com with RES still provides a better user experience.

Like 80% of my reddit usage is on mobile by now, though. So it doesn‘t matter that much to me.