10 ms·

The real problem with Facebook at least is build times -- using the native stack incurs something insane like several hundred hour build times IIRC. So the nati

by lwb 5y ago

The real problem with Facebook at least is build times -- using the native stack incurs something insane like several hundred hour build times IIRC. So the native stack is just a non-starter once you get to a certain (ludicrous) codebase size.

72deluxe 5y ago
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?
- swiley 5y ago
  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.
  - nawgz 5y ago
    Infinite scroll was around in the 90's? Wow, I learn something every day on this site
    - nawgz 5y ago
      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
    - zozbot234 5y ago
      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.
      - nawgz 5y ago
        Imagine trying to argue UI development was solved in the 90s and then telling me you use manual pagination as the follow up
        tspike 5y ago
        > 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.
      - swiley 5y ago
        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.
- csande17 5y ago
  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.
  - tester34 5y ago
    I always thought this was some anti ad-block feature, huh.
- lwb 5y ago
  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.
  - munk-a 5y ago
    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.
    - traek 5y ago
- jayd16 5y ago
  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.
  - lwb 5y ago
    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.
- mlcrypto 5y ago
  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
dijit 5y ago
Errrrr. I make games, like, big games… compile times are a problem but it’s in the realm of 12hours at the absolute most. Are you saying Facebook would take more time to compile natively than an open world game including baking maps?
- deleted 5y ago
  [deleted]
clarkcox3 5y ago
That is simply not true. Building the entire client app from source takes about a half hour.

by lwb 5y ago

72deluxe 5y ago

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?

swiley 5y ago
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.
- nawgz 5y ago
  Infinite scroll was around in the 90's? Wow, I learn something every day on this site
  - nawgz 5y ago
    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
  - zozbot234 5y ago
    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.
    - nawgz 5y ago
      Imagine trying to argue UI development was solved in the 90s and then telling me you use manual pagination as the follow up
      - tspike 5y ago
        > 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.
    - swiley 5y ago
      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.
csande17 5y ago
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.
- tester34 5y ago
  I always thought this was some anti ad-block feature, huh.
lwb 5y ago
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.
- munk-a 5y ago
  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.
  - traek 5y ago
jayd16 5y ago
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.
- lwb 5y ago
  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.
mlcrypto 5y ago
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

dijit 5y ago

Errrrr. I make games, like, big games… compile times are a problem but it’s in the realm of 12hours at the absolute most. Are you saying Facebook would take more time to compile natively than an open world game including baking maps?

deleted 5y ago
[deleted]

clarkcox3 5y ago

That is simply not true. Building the entire client app from source takes about a half hour.