mrkcsc

OK but thats simply doesn't perform.

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.

> I feel like virtualization is not the right way to handle things.

How would you handle it?

Optimizing for the P95/99 case of performance typically makes everything better as a whole.

What are you even talking about, this post is about rendering code diffs in the context of the web.

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

We called them servers because our early adopters were coming from Ventrillo and Teamspeak (eg: Vent server, Teamspeak server, etc) and we wanted to use familiar terminology.

Our core team - and indeed our original team - were native developers not React JS ones.

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.

Blog author here - this is correct (mostly Kotlin :)

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.

Thank you for the kind words!

The strongest RN teams and engineers I've seen tend to be those that either already have or are willing to acquire knowledge about how native app development works under the hood.

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.

Thanks for the read, and the support!

I've made many native apps (including our own native Android app) and performance issues are definitely still a thing with native code :P

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.

Blog author here. As a native app developer, I would say that the trade off is similar to developing an app on native Android vs. native iOS.

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.

Thats true, I appreciate the discussion and the clarification.

Well it’s been three years so far - we shall see :P

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.

Based on our experience yes I would certainly consider doing the Android side in React Native starting today.

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