Live data from Hacker News

LightSpeed: Rewriting Messenger’s codebase for a faster, smaller, simpler app

engineering.fb.com

81–90 of 333 posts

Re: LightSpeed: Rewriting Messenger’s codebase for a faster, smaller, simpler app

#81

Earlier quoted context omitted.

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"?

“I was instrumental in making Messenger twice as fast?”

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.

Re: LightSpeed: Rewriting Messenger’s codebase for a faster, smaller, simpler app

#82
Am I the only one who thinks 86mb for an app is about 86 times too much?

Windows Messenger was about 900k. Sure, it only did text, but Skype wasn't that big either. I'd accept 20mb for stickers, givs and stuff but 80? And 300k lines of code? For a messaging app? It just seems... unreasonable to me.

Re: LightSpeed: Rewriting Messenger’s codebase for a faster, smaller, simpler app

#83

Earlier quoted context omitted.

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"?

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.

Re: LightSpeed: Rewriting Messenger’s codebase for a faster, smaller, simpler app

#84
post #75

> We extended SQLite with the capability of stored procedures, allowing Messenger feature developers to write portable, database-oriented business logic I wish the article was a little more fleshed out, I'd be interested in finding out more about how and why they went down this path

I just listened to the Changelog's (a podcast) episode with Richard Hipp, the author of SQLite -- I wonder if he had any part on this extension. But in any case, great to see SQLite thrive.

Re: LightSpeed: Rewriting Messenger’s codebase for a faster, smaller, simpler app

#85
So, they've reduced 1.7M lines of code to 360K. Let's pause here for a moment:

- NumPy is 360K lines mostly C

- Postgres is around 2.1M of C

- Go 1.13 is around 1.5M of Go code

- Rust 1.37 is around 1.2M of Rust code iirc

- core llvm is around 3M of C++ iirc

...

A chat app is 1.7M. A chat app...

Makes me feel sorry for all the time spent/wasted by all those devs, many of whom are unquestionably brilliant and could've worked together on something truly awesome, big and useful. But we all know that doesn't pay the bills and so here we are.

Re: LightSpeed: Rewriting Messenger’s codebase for a faster, smaller, simpler app

#87
post #80

Earlier quoted context omitted.

React Native isn't necessarily a great fit for something that is intended to be "a simple, lightweight utility" - there is a reasonable start up overhead, for example, with RN, and it also involves bundling quite a few libraries and dependencies. That doesn't mean React Native is not a good fit for any kind of application - for many kinds of apps, start up time and app size are a much smaller issue - but seems Facebo…

React Native (or any framework) isn’t good when you can literally afford billions of dollars of R&D given the financial value of the app. Just like the Mars rovers don’t run Python but it is a great language for a experimental SaaS app testing a new market, RN is great for a team of 3 engineers to get a multi platform app shipped, but not a great choice for an app worth ~$100 billion to its parent company.

Interestingly, there was news on some satellite running javascript. But I wonder if the core was running something else, and peripherals were run with js -- and simply restarted when they died, Erlang style.

Re: LightSpeed: Rewriting Messenger’s codebase for a faster, smaller, simpler app

#88
post #63

This is an interesting business decision. To rewrite such a large app must have cost a fortune. Going full native is probably going to increase the cost of future development as well. Aside from the costs of writing/maintaining the code, pushing more work to the servers is an ongoing cost. Realtime, always-connected, apps are costly to run even when you push the majority of the state management to the client and just…

> To rewrite such a large app must have cost a fortune. Going full native is probably going to increase the cost of future development as well. it's a freakin chat app, and it's freaking facebook ! come on, people were doing full rewrites in entirely different languages of software insanely more complex than fb messenger back in the 90s and with near-zero tooling, eg from cobol to pascal to C or similar horrors.

I've built a few "chat apps". I wouldn't discount the complexity. They carry with them a wide array of problem spaces. And of course anything at FB scale user counts is going to be a challenge.

Re: LightSpeed: Rewriting Messenger’s codebase for a faster, smaller, simpler app

#89
post #47

Earlier quoted context omitted.

UIWebView was deprecated for years, everyone's had plenty of time to move to WKWebView, and it has nothing to do with React Native to boot. Apple legitimately doesn't seem to care about hybrid frameworks, they've been there since day one. Any time it's seemed like it got difficult Apple has backed down. The lack of JIT in WKWebView is probably the only thing that you could stretch here.

WKWebView is out-of-process and has a JIT.

Ah, you're correct - not sure why I thought otherwise, especially when I touch WKWebView pretty often.

Re: LightSpeed: Rewriting Messenger’s codebase for a faster, smaller, simpler app

#90

Here's a way in which they can save 100% of the size: Stop stubbornly barring mobile clients from using the web interface. This is why I don't use Facebook Messenger at all.

For some reason I can access the chat using Firefox Mobile on iOS but not through Safari.

I used mbasic.facebook.com for a while when it was not possible to use it from the regular mobile web. But for like a year or something they appear to have turned the web back on (at least for firefox, haven't tested anything else).
Post reply on HN