Hacker News Reader

Comment by butz | Hacker News Reader

The loop of app building: 1. Build app with native framework. 2. Re-build app with some alternative framework which is slower, but let's you deploy single code on all platforms. 3. Re-build app with native framework, because it is faster. 4. GOTO 2

View on HN

The best part about this cycle is that developers can always point to some metric which shows improvement to justify their actions, resulting in an Escher-like loop where they think they’re always going up.

These cycles pop up all the time in development as priorities shift (or as developers find more excuses to “fix” what isn’t broken). Real world coding always involves compromise - leadership is recognizing which compromises to make without continually backpedaling.

To be fair, small fast messenger 2020 is "better" (aka more features / millisecond of cold start) than small fast messenger 2016. The cycle doesn't always go up monotonically, even if developers pretend it does. But it is possible to go "full-circle" through the loop and wind up in a better place than you started, and it's even possible for each stage of the loop to be truly justified given product needs.

How much of that is simply improvement in processing speed of the device and/or better OS APIs?

indeed, it could be rational business needs. at a time when it's more expensive to hire devs, maybe it looks better to have a single codebase. at a time when performance is more valued, maybe it's better to rewrite in native.

I don't know what world you live in, but in my world developers don't have to look for excuses to do work. Perhaps some companies running on endless VC overhire, but the real working world has fewer employees for most positions than it needs.

And in the case of Messenger, I highly doubt it was the developers who said, "Hey, let's add this completely unrelated thing to our codebase - payments!". More likely it was marketing or "product" that told the devs what to add.

That's the problem with Coordinate descent[1], which is how we humans intuitively go about optimizing things.

[1]: https://en.wikipedia.org/wiki/Coordinate_descent

From TFA: "We reduced core Messenger code by 84 percent, from more than 1.7M lines to 360,000."

Sounds like not only did they make the app quicker and lighter, they improved code maintenance too. If the android app is as the same size as the new ios messenger app, they'd still have less code to maintain than the previous ios messenger app.

See also: this other comment - https://news.ycombinator.com/item?id=22468036

How in the name of everything did they manage to write 1.7M lines of code for a messenger app? That is an astonishingly large code base! We're talking about an instant messenger app with heaps of features, having a LoC footprint 3.5% of the size of modern Windows.

> Since then, we’ve added payments, camera effects, Stories, GIFs, and even video chat capabilities

Simple: they added tons of crap nobody care. On this list, I only use video. Messenger is valuable because of the network effect, but feature wise 2003’s MSN was good enough.

> nobody care

> _I_ only use

(emphasis added)

Just because you don't use those features, doesn't mean nobody cares about them

None of that justifies 1.7 million LoC.

That's not true, the application, whether you like or not, it full of micro-interactions, well-done animations and transitions, features like the payment or stories, you can take photos directly from the app, etc.

With that many features, it doesn't surprise me that the previous codebase was 1.7M LoC. Sure if you count only the messaging part, I'm fairly certain that the LoC is way lower than this.

It doesn't make sense to compare the number of LoC of messenger to the number of LoC of software like Postgres because Postgres tries to be good at 1 thing and messenger tries to have a ton of features with good UI and UX.

I don't like many of their features (I'm not using the stories or the payment), but some of my friends do and you have to recognize the work that the messenger team did to make them work that well.

Don't forget all the code to support A/B testing.

One of their points in the article was how they've decided to use more of the native OS interfaces instead of implementing their own versions (!!). For instance, using the OS's native threading library instead of writing their own. So, the number of LoC kinda start to make sense when you think about them re-implementing some not-trivial chunk of an OS's native functionality.

LOC is proportional to the number of engineers on a project. All engineers have to justify their existence, so, they will write code.

I've never felt the need to justify my own existence. There's always been a longer backlog of work than my teams would ever get through and managers who appreciated the work getting done.

Another plausible explanation is lack of code re-use and reinventing the wheel because you don't know someone else solved the same problem. Also correlates with number of engineers.

I wonder if react native library code and all the other code related to it like the js engine is included in that metrics.

There was no React Native in the Messenger app before the rewrite.

Oh my bad, i thought all facebook apps used react native

I had the same question... And that's not counting LOC on the server. And all of this is for... glorified text messaging, right? I don't use FB so I could be missing context or features.

And they ended up in hundreds of thousands of lines :)

Wonder if part of this is custom video / audio codecs? That I’d imagine would contribute a good amount...

I wonder how this will effect Lite. I use it over Messenger strictly to reduce bloat and get an app with the bare essentials of chat and calls fol friends that refuse to use Signal.

I'am curious if in 360K LOC are also included templates configurations stored in SQLite because these must be written and maintained too.

It's great, because each approach has pros and cons, so as long as you primarily focus on the pros, it's a win every time.

the reason is they're high paid engineers without skin in the game. Fb is already making money, hence a lot of engineering efforts are not related to having fb make money, but to prove the engineer's worth.

And to keep people in the game to operationally care.

Mainframe -> Native Desktop apps -> Web apps -> Native Mobile Apps -> Mobile Web apps

More like: make app hideous and bloated; make app slightly smaller; crow about your harvest of low-hanging fruit

1. Developers: YEP! 2. Developers: YEP! 3. Developers: YEP!

Munch Munch Code Munch WTF Munch AGILE! $$$ Munch.

Designers: 1. We need a new design system. 2. We need a new brand! 3. We need a new font!

Users: ¯\_(ツ)_/¯

/s <3

As far as I know messenger was never written in a cross-platform way, neither RN or otherwise.

Is there anywhere that suggets it was ever non native?

It was fully native.

Not sure why people are downvoting an insider answer from an actual FB employee

Exactly. But this was the last time the business collectively did something that short-sighted, right? Last time.

Better than plan plan plan. It is the customer or user that use it that count. Not the programmer.

You do realize that you can have one code base and write in C++ right? You don't need a slow framework to have a UI run in multiple places.

Somehow younger generations are allergic to it, you seldom see it listed as alternative for portable busines code, even though it is available out of the box in all mobile SDKs, with first class IDE support alongside the respective upper layer languages on the platforms.

And the amount of time spend writing a bit of glue code, specially on Android, is still less than debugging integration issues in all those Hybrid/Abstration frameworks.

>Somehow younger generations are allergic to it,

Because they haven't been burned by that cycle yet.

Perfect :)

Reply on news.ycombinator.com