Hacker News Reader

Comment by 72deluxe | Hacker News Reader

Are you saying that the client includes all of the Facebook logic or something?? Surely displaying forms (essentially what a post is) and ability to scroll through a list and click on a button or view/upload a photo is the essence of the app?

Where's the magical bit that means they can't use a native UI toolkit?

View on HN

The magical bit is that they have hundreds and hundreds of cooks in the kitchen, who all need to justify their existence by creating tons and tons of little one-off UI screens for obscure features that hardly anyone sees or uses.

This kind of team structure also causes other strange-looking technology choices, such as CSS-in-JS: they have to do stuff like that because they literally cannot prevent different members of the team from writing CSS class names that collide.

I always thought this was some anti ad-block feature, huh.

I think that number of classes is the main issue. It's in the many, many millions.

Also, the app has sooooooo much more functionality than people realize. Plus, there is a lot of functionality that ships with the app but is behind a feature gate, meaning that it is turned off for the majority of users. There's lots of internal tools for adjusting feature gates on a per-user, per-region, per-whatever basis, in the name of user research as well as just safely deploying new features at scale.

Speaking as someone focused on code maintenance this isn't a good thing. If the highest complexity of your product exists at a level where users can't interact with it then you're spending a lot of dev time inefficiently.

But I don't believe you're correct, honestly feature flag rollout, even among insanely specific cohorts, isn't actually a hard problem and it's essentially been solved at this point - it isn't easy, not by any measure - but the components and how they interact are rather easy to comprehend. Facebook's main complexity (IMO) is from trying to build essentially a full OS on top of the browser from which to serve a variety of integration apps into their platform and, while I'm not a board member of Facebook or at all familiar with their earnings, that particular goal seems to have been, essentially, a dud.

Being able to play farmville with your friends may have been a decent income source once upon a time but it's very far from what their core competencies now are. Facebook now primarily uses API hooks into other native standalone apps for that particular class of data collection, but their pure web based collection seems to be where they really get value. The fact that they can see precisely where users are going on the web is, IMO, their main value proposition at this point - the social network stuff needs to exist to support that and ease the process of identifying users - but anything related to games seems utterly unnecessary and that core platform they have could be vastly simplified while still delivering the same value to the company.

That all said, they've invested a whole lot into their existing platform so I can see why business would be very very hesitant to try anything that might rock the boat, if they can sustain their platform being fast and responsive they can minimize their corporate risk.

They aren't saying that the feature gating code adds to app size, but rather that there's a lot of code behind feature gates (for tests/staged rollout/locale-specific features/etc) that most users won't see which still add to app size.

Fail fast and KISS are pretty celebrated virtues of sustainable project development. I understand that on the scale of Facebook you have issues with project management but if there is a significant amount of code that is locked to specific cohorts of users aren't you opening up the door to unprofitable levels of complexity and long running poor investments?

I'm sure a lot of developers on here try and minimize their use of integration branches in the day-to-day (they are necessary for some things but keep them short and sweet) and try and get in-progress features into master ASAP - that's largely due to the fact that maintaining multiple copies of the same basic logic can quickly become extremely difficult to manage.

Localization is a really big exception to this but that's why, whenever possible, you'll see game companies limit localization to strings only - including logical statements in the realm of information to be localized can make security issues extremely fun to track down along with causing frequent usability breaks in less used localizations.

I don't know - whatever the reasons for it and no matter the resources FB has - this stuff increases in cost exponentially and if they do have a really fragmented codebase it's likely that the majority of their labour goes into process definition and QA to make sure that they don't break the Swahili language version of the landing page for China when they change their contact us link.

Fail fast works on the web, where you can redeploy the app with the next page refresh.

It works poorly on mobile, where users are not keen to reinstall an app every few days, and some do not update for months and years, because of lack of space, scarce bandwidth, old hardware, or just neglect.

It doesn't just apply to the web though - it can even apply to OS design. On the web it's usually (ab)used to leverage users as the metric of whether something is failing, but in theory fail fast is just about learning that something isn't working through any means - whether that be user reports, automated tests or proofs of concept.

Additionally, at least where Facebook is concerned and IIRC, they actually do heavily utilize out-of-app data in their mobile app. There is a good deal of code, but a lot of the UI ends up being tweaked by data that's being served to the client.

Almost as if the user is the product instead of the app. The app is doing everything in the background to monetize the user

I don't disagree with the sentiment - but I still think the app is poorly tuned if it's been allowed to accrue this much complexity in the relatively non-essential UX that we all interact with through the web. My point is that the complexity of FB's landing page is unmaintainable and misaligned with business goals - if we view those goals to be about data collection and not actually running a social network then the misalignment is actually worse.

Literally, Facebook reverse engineered Android's vm solution to monkey patch in a longer method table instead of reducing the method count. I have no idea why but their massive amount of client code seems very important to them.

Part of it is FB’s company culture — generally the ethos has been to enable engineers, technical precedent be damned, and to never say no to a product idea. It is really impressive and a major part of why FB can move so fast despite being a very large corporation.

It's always absolutely fascinating how complicated people can make scrolling and displaying forms.

This stuff was solved in the early 90s and everyone's bored now.

Infinite scroll was around in the 90's? Wow, I learn something every day on this site

Yup. Browsers used to render all pages incrementally, so you could simply keep the HTTP connection open and add more HTML text to the page, and it would just get tacked on to the bottom. Then you had a CGI endpoint in a separate footer frame (sort of like an iframe but arranged in a Grid-like layout) with a "Read More..." form button for requesting more data. It worked really well and didn't even need to use JS.

You can still do this. I wrote a chess game that checks arg 0 for "cgi" (otherwise it uses a VT interface) and renders a new board in the browser every time the other player makes a move. It works with absolutely no javascript.

Imagine trying to argue UI development was solved in the 90s and then telling me you use manual pagination as the follow up

> In Comments

> Be kind. Don't be snarky. Have curious conversation; don't cross-examine. Please don't fulminate. Please don't sneer, including at the rest of the community.

> Comments should get more thoughtful and substantive, not less, as a topic gets more divisive.

> When disagreeing, please reply to the argument instead of calling names. "That is idiotic; 1 + 1 is 2, not 3" can be shortened to "1 + 1 is 2, not 3."

> Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith.

You know, maybe sass isn't appreciated on this site, but it's pretty pathetic to imagine someone could unironically imply any part of UI was a solved problem in the 90's and not face a challenge here. UI engineering is a discipline which most software engineers grossly underestimate the complexity of

Lol you are very naive if you think all Facebook does is show posts and messages. You need to track the users, collect sensitive date, and all the other malicious stuff

Reply on news.ycombinator.com