Rather than reinventing the wheel, we used the UI framework available on the device’s native OS to support a wider variety of application feature needs. This reduced not only size, by avoiding the need to cache/load large custom-built frameworks, but also complexity. The native frameworks don’t have to be translated into sub-frameworks. We also used quite a few of the OS libraries, including the JSON processing library, rather than building and storing our own libraries in the codebase.
This is awesome. It shows the benefits of building an app leveraging the OS, instead of fighting or abstracting it.
They make it sound like the clouds parted and a ray of sunshine struck the programmers at Facebook and they realized that they didn't have to ride the framework-go-round to hell.
These are supposed to be the smartest people in SV, but from the outside, it strikes me more as a "No shit, Sherlock" moment.
Which, for example, gets you more sway with your employer, personal "branding" value, and future income / ease of switching jobs: "I was instrumental in inventing React" versus "I was instrumental in realizing we didn't need to invent React"?
Well yeah, but first someone has to get the credit for creating some "high-productivity" hog of a framework to make it slow, then someone else can come tear all that crap out and claim they made it fast.
I guess it depends on if you frame it: "I was instrumental in adding complexity under the false promise of ease of development" versus "I was instrumental in saving the company time, money, and improving the product for our users."
Things like this are why I'm glad I'm not in the bubble anymore.
"I was instrumental in a major rewrite for [REASONS]" vs "We kept it the way it was because it was good enough and a rewrite would've improved [X] but hurt [Y]"
At a previous employer, I was dumped a client lib and server whose purpose was to maintain a data cache with realtime updates. It was fragile and slow as fuck.
When I got ahold of the source and started diving into it, discovered the client had 2 copies of the data, which was kept in memory. The server had 3 copies of the data in memory! Worse yet, the primary cache would be updated, then a multicast message was broadcast to update all the clients and the server's secondary and tertiary caches...thats right: the server would update the 2 other caches by broadcasting a multicast message, receiving it, then updating the other 2 after message receipt. A re-architecture was definitely in order. Took 3 months. Took another 3 months to get the interface to be backwards compatible with the original version.
Mind, the server was responsible for serving up relatively static market data for finance. But, considering we traded globally, we had +400 objects we cached, more than a few had 100ks of record. Memory usage for the server was many GB.
The rewrite involved moving to a single cache, instead of multiple for both client & server. It was also architected to handle large volumes of updates. Original implementation could even handle 100 updates per hour without bringing the server's and all clients to their knees. The write could handle +10k updates per second amd clients would barely notice a slowdown. Write locks were only held for a pointer swap. Memory usage for the server went down by close to 2/3. Client memory usage by 1/2.
During that time, also moved from static libs to dynamic on both Linux and Windows, so I could make nonbreaking changes without a firm wide recompile/relink, which typically took 3 days. HUGE productivity boost. A small bugfix didn't require a firmwide recompile/relock for the smallest bugfix.
I dunno -- you make it sound like it's a priori easy to figure out what is going to be better: one codebase ala react or multiple implementations per platform. Where the definition of better is some admixture of user experience, hardware requirements, maintenance costs, ease of hiring / training people for the necessary skills; and all these may shift over time.
But could it be that the OS functionality also evolved until today where it’s finally feasible to do this?
I’m guessing the oldest code in Messenger stems from a time when the OS-provided libraries were not up to par or simply didn’t exist yet. Partly because it’s not until now that the OS manufacturers finally see what there is demand for in apps.
Oh yeah, this is a problem with a lot of developers, reinventing the wheel because the native JSON parser might be improved upon. I mean it's a clear case of NIH, and yet it's also defensible because I'm sure most native / builtin JSON parsers are not as fast as a custom solution. And for an app like Messenger, moving to something else like grpc would be very defensible.
> For any cross-platform logic, we used an operating extension built in native C code, which is highly portable, efficient, and fast. We use this extension for anything OS-like that’s globally suboptimal, or anything that’s not covered by the OS. For example, all the Facebook-specific networking is done in C on our extension.
C was the universal donor 30 years ago, and it's the universal donor today!
If you look further down the article, it describes their extensive use of sqlite, and a layer around it for managing synchronization with FB servers, also written in C.
I write a lot of Python and a lot of Go, and I love C. So I enjoy imagining the subgroup of HN commenters who wail that Go is ignorant of the last 30 years of CS technology, or that no one should be allowed to write C these days, reading this.
And then there are those ignorant of the 10 years of systems programming that preceded the inventation of C, and how the computing world looked like at Xerox PARC, IBM, DEC, Wang, Olivetti,....
Rather than reinventing the wheel, we used the UI framework available on the device’s native OS to support a wider variety of application feature needs. This reduced not only size, by avoiding the need to cache/load large custom-built frameworks, but also complexity. The native frameworks don’t have to be translated into sub-frameworks. We also used quite a few of the OS libraries, including the JSON processing library, rather than building and storing our own libraries in the codebase.
This is awesome. It shows the benefits of building an app leveraging the OS, instead of fighting or abstracting it.