You can't say "only rendering what is visible should be handled by the browser" and call that a solution unless you have a magic wand to make Chrome/other browsers do this.

The browser doesn't do this, and so you can either do what you say and have your browser freeze when you load up a million line diff, or you can fix things within your control which is what the author is doing.

How would you handle it?

Whether or not it would be "trivial" in a native terminal application is irrelevant.

We chose React Native because it was a pragmatic choice and the best tool for our situation. As our startup gained traction and we decided to build mobile apps - we already had a React JS app so it made sense to try out RN.

As it turns out, we were able to build an almost feature parity versions of the React app in a weekend that shared all the business logic - so it made a ton of sense for us.

React Native for Android did not exist at that time (not open sourced) and so I had to build out our initial Android app in native - I can tell you it took me a lot longer than a weekend :P

That isn't to say there are not pros and cons to each approach - but I think it's important to be always open to new tools/languages vs. going with the "devil you know" so to speak.

This is primarily an artifact of history for us. When we first set out to build the mobile apps, React Native for Android had not yet been open sourced so we had no choice but to build it in native.

That being said, the Android side of RN has always been more nascent and so one of the benefits for us has been not having to deal with some of those early bugs/issues while building our our current iOS app.

It's since become much more mature however - so we may explore RN for Android again someday.

It greatly augments your ability to write elegant solutions to hard problems.

Some argue this is a large cost to bear - however I'd say it's one that is very reasonable to acquire. Having experience and knowledge in several languages/frameworks helps make one stronger engineer.

The amount of work was non-trivial, however, in absolute time it was a few weeks of work that we have only done once after first creating the app many years ago.

It's likely that we we would have considered doing something like this even if the app was in pure iOS - Discord has gotten much bigger.

Mobile teams I have seen for apps at scales similar to Discord tend to run anywhere from 10-20+ dedicated engineers. By comparison I believe we have been able to accomplish a lot with a much smaller team.

You inevitably must solve problems on Android that iOS has not yet solved (or are trivially easy to do) and vice versa, but each framework also has its own strengths that come with it.

React Native is no different in this regard. We sometimes solve different problems that occasionally area easier to do on Native (although as mentioned by this post, this is the first time in years we've actually had to sit down and focus on performance).

That being said, some of the pros are that we save a tremendous amount of time through code sharing, web team contributions, etc.

I know this comment is a joke but in all seriousness even if we did move away I think it would still mean we got several years of great utility out of the framework.

No tech lasts forever and it’s important to be open to change as well as being mindful to not chase the latest trend - as in all things, balance is key.

While the performance footprint is mostly the same - the ecosystem and feature set around it has improved a ton to the point where I believe you could get it 90% there very quickly.

One of my friends has a small startup and they went full React Native as a team of two and they describe the Android side as "free" as in they really just focus on iOS and it 90% of the time it also works fine on Android (they care less about older devices at the moment so they don't spend time optimizing for those).

Android inherently will always have challenges due to the vast number of devices and hardware/performance problems but going native isn't a silver bullet either and doesn't shield you from the challenges entirely - it's just a familiar form of pain ;P

I believe it's something we may eventually take on - just not currently planned - there are a lot of ways we could make the nitro experience better.

Native iOS would have been a better example as that code is not open source at all.

The team - myself included - works normal eight hour days and there is no "crunch time" (other than very rarely when we have external dependencies like when we launched our Spotify integration).

As an engineer we all want to have agency and be able to make impactful decision on the products we work on. Over-hiring too quickly is often what can lead to organizational bloat and can make things get built slower.

Instead, I think it's better to grow slowly, hire great people, and only hire when it's needed. I've found that as a company, staying small has made us always ask ourselves to make tradeoffs and constantly be thinking about what are the most important and impactful things we can be working on.