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.
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.
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.
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.
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.
