Hacker News Reader

Comment by dewey | Hacker News Reader

I guess they probably could build a nice and fast website if it was up to them. But there's probably a lot more requirements than just that.

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",...)

View on HN

They already did: https://mbasic.facebook.com.

90's versions, like mbasic, of almost every website is better. More content, less noise. Mbasic could still use a flaming <hr> tag though

> 90's versions, like mbasic, of almost every website is better.

I mostly disagree and assume this is slightly hyperbolic, but I take your point. The web used to be documents, even for things that needed to be apps (like email). Now, the web is apps, even for things that should be documents.

Beyond that, the web was not the capitalist/SEO/marketer battleground that it is today, where many sites have so many costs behind them (devs, videos, etc.) that they need a boatload of ads just to try to stay in the black.

In the 90s, you could have a very popular message board with millions of pageviews a month for $30/mo.

> In the 90s, you could have a very popular message board with millions of pageviews a month for $30/mo.

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.

For me on FF this is only a tiny bit faster to load the main page, but way less readable and pictures are so small you have to open them to be able to see what's in there. So not a net positive result imo.

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

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.

I'm not sure why FB's site has unnecessary DIVs... But to defend React, HOC or render prop techniques but don't have to output DOM. In other words, every React component does not map to a DOM element.

React components aren't a 1:1 mapping to the DOM, so you could in theory have 50 HoCs wrapping a single component and it still only output one div or whatever.

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

You can use hooks with redux now, so what’s the purpose of using connect instead of useDispatch or useSelector?

Two big reasons: Values passed via connect can be validated by proptypes, and by using connect you can mount your component without redux. That may make sense for building shared components that may be used with redux in one part of your app, but without redux in another part. There are a lot of smaller reasons to prefer connect, but those are the big ones to me. FWIW I use both approaches depending on needs.

It’s not.

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.

So every React app can be effortlessly refactored to use whatever shiny new latest and greatest architecture abstraction React comes up with?

No, and FB themselves discourage this in their documentation.

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.

Since the <Fragment> component was introduced (React 16?) excessive wrapper divs are no longer necesssary fortunately!

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

All these things can be true and yet people will still frequently misuse them.

The extra divs are an obfuscation technique, intended to frustrate scrapers and browser extensions.

Heh just yesterday I was trying to click on a zoom meeting link for a Facebook event, and it wasn't working for whatever reason, so I tried to pull the url out of the page with the inspector, and I saw the same thing -- hopelessly deep nesting of the element, with the URL hard to find and its text version obfuscated ... and that's not even an ad!

> Things like ... are probably not decided on and implemented by the engineering team but are coming down as a requirement from the top

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

Reply on news.ycombinator.com