Keep seeing react native pop up in the comments, there has never been any indication that Messenger used any react native from fb feom all their presentations I have see . RN is used in the Marketplace tab on the Facebook App, the Ad manager app and a few other places.
LightSpeed: Rewriting Messenger’s codebase for a faster, smaller, simpler app
281–290 of 333 posts
Re: LightSpeed: Rewriting Messenger’s codebase for a faster, smaller, simpler app
#282RN isn’t the right tradeoff for Messenger — whose new core is written in plain C — but its use at FB in general is growing, with 750+ screens in RN. So the rumours of its death are greatly exaggerated.
I think it’s great to have different options with different tradeoffs available to choose from. But hey, that’s just me.
Re: LightSpeed: Rewriting Messenger’s codebase for a faster, smaller, simpler app
#283Earlier quoted context omitted.
> that includes payments, camera effects, extensive social integrations, stories, GIFs, reactions, games, polls, voice recording, calling, video chat To be fair, this is part of the problem ^
Just because there are features that you don't use doesn't make it a problem. In fact people who like stories and camera effects likely way outnumber the people that don't.
The number of people that use camera effects as anything other than a gimmick is even smaller.
Maybe a different age group?
Re: LightSpeed: Rewriting Messenger’s codebase for a faster, smaller, simpler app
#284At first look, I thought it is 36k, that would be truly great.
Re: LightSpeed: Rewriting Messenger’s codebase for a faster, smaller, simpler app
#285Earlier quoted context omitted.
Thank you for saying this. The overwhelming majority of comments on this thread are pedestrian - as if FBs engineers have been making decisions out of naivety, incompetence or self interest.
> as if FBs engineers have been making decisions out of naivety, No. > incompetence Yes. > or self interest Yes.
That said, I’m happy with React.
Re: LightSpeed: Rewriting Messenger’s codebase for a faster, smaller, simpler app
#286So, 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…
I'm really not a fan of this virtue shaming that people often tend to do as developers, where if you're not working to solve world peace then you're a waste of a developer.
Sometimes people just like getting paid? Sometimes people just don't really care, they just want a job or want to write code?
Re: LightSpeed: Rewriting Messenger’s codebase for a faster, smaller, simpler app
#287Earlier 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…
To be clear, Messenger wasn’t being rewritten from React Native. It was a fully native app before, too.
I guess many native developers feel negatively towards it because a lot of companies will be asking "why aren't we using React Native instead of building two separate apps?" which I can imagine feeling somewhat threatening towards your area of specialisation
Re: LightSpeed: Rewriting Messenger’s codebase for a faster, smaller, simpler app
#288Earlier quoted context omitted.
I would love to read more about why large apps are so big. I currently work on a project that is much larger than I would expect it to be, both in terms of codebase and people, and while I don't know who to jank, I also don't understand why it has to be so big.
Short answer: because it's way more feasible to remodel your kitchen than to tear down your entire house and rebuild it. And then your bathroom. And then convert the garage. And then add an addition. And in 10 years you have this cobbled-together monstrosity
Now your entire house is built with those screws, but they’re not produced anymore so you’ve set up a small smelter next to your home where you’re making them yourself.
Unfortunately the quality is a good bit worse, so parts of your house start degrading faster and faster, but meanwhile you’re still building all new parts with your shitty screws.
Nobody wants to replace the screws because “It’s a proven method”, ignoring all signs to the contrary.
All new parts of the house are only as good as the worst part, the screws, and the moment anyone steps on the wrong plank the whole room comes crashing down. But nobody worries, next time they’ll just use two screws.
Re: LightSpeed: Rewriting Messenger’s codebase for a faster, smaller, simpler app
#289Earlier quoted context omitted.
Just because there are features that you don't use doesn't make it a problem. In fact people who like stories and camera effects likely way outnumber the people that don't.
I strongly doubt that. The number of people in my list of friends (400ish) that use stories is marginal. The number of people that use camera effects as anything other than a gimmick is even smaller. Maybe a different age group?
I think that most of people of HN have friend groups which are wildly unrepresentative of world population at large. We're talking not even an average US or European citizen here - we're talking 1+ billion. People from developing countries who very often access internet only from a smartphone (they don't own a computer) and who almost don't visit plain http websites outside of the few social apps.
It's a completely different world out there.
Re: LightSpeed: Rewriting Messenger’s codebase for a faster, smaller, simpler app
#290From: https://engineering.fb.com/data-infrastructure/messenger/ > We accomplished this by using the native OS wherever possible Does this mean this application does not use React Native?
Man, I hope so. There has beens so much cargo cult built up around React Native that suggesting other approaches is almost guaranteed to kick off many rounds of contentious design meetings. Fortunately, nothing quite takes the wind out of a platform's sails like watching the creator back away from the platform.