HN user
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
Thank you! :)
It's been discussed a lot internally - I would love to gift Nitro to folks myself ala Reddit Gold :)
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.
It's a valid point :) that probably wasn't the best example - although it would likely be quite a journey to somehow ship the forked support library.
Native iOS would have been a better example as that code is not open source at all.
Thats really cool :D I think getting it to the point where it's not just occasionally synced is really helpful for upstreaming contributions and bug fixes.
It's not about cost, it's about impact.
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.
Not an expect but as I understand it the Windows API for idle tracking is sometimes wonky.
Certain programs can keep your computer in a non-idle state indefinitely even if you don't move the mouse.
We are actually starting work on allowing pasting images from the clipboard this week :D
So stay tuned!
Thanks for the kind words, the team really appreciates it.
To be fair though this exists in Native land too :P but it's sometimes even worse.
EG: In Android in the past there have been bugs in core components like the `RecyclerView` (thing that renders lists) that forced us to downgrade and unlike with React - there is no option there to fork the source and make our own bug fix.
The iOS application can safely pull data and perform actions from just about every Store (we don't use redux but the idea is the same https://redux.js.org/api-reference/store) and Action Handler (https://reactjs.org/docs/handling-events.html) that exists in the main Discord React application.
So if one is writing a feature that say allows one to ban a user - they don't need to write any of the banning logic or worry about fetching the user data/validating it against server roles permissions - if it exists on the main Discord app, it can be safely imported.
Other helpful examples are perhaps things like markdown parsing - iOS was able to just import and use the exact same system desktop uses to handle markdown and things like user/channel mentions, custom emoji, etc. On Android we had to write one ourselves: https://blog.discordapp.com/how-discord-renders-rich-message...
On Android since there is no code re-use everything had to be written from scratch.
* Mentioned in another comment, but generally the performance of animations was poor with mixed in with any other kind of UI rendering - particularly on older phones (when we prototyped iOS we really only focused on the latest two generations of iPhones).
* This can be worked around by deferring work when doing transitions/animations based on user interaction but at the time we only had a single Android Engineer (myself) and I felt it would be an overly large hurdle to cross. The team is however still interested in trying again some point in the future now that we have more time for it.
* The minimum version we support is API level 16 which is quite old and we may eventually bump that to 17.
* We have not evaluated any native-ish alternatives mostly due to bandwidth but also because the goal is to re-use our stores/business logic from the desktop/ios clients so we can move faster.
* On 64-bit support https://github.com/facebook/react-native/issues/2814 it ca be worked around without much consequence but is a consideration as ones application grows in complexity and dependencies.
I'd suggest reaching out to our CX team (support@discordapp.com) - we really do care and you will get a reply :)
I'm not an expect on voice but iirc we do use a different codec than Skype so the audio is not going to be identical however, we have advanced settings in the `Voice and Video` section of the settings that allows you to enable/disable things like Echo Cancellation and Voice Suppression that could be the cause of the feedback.
It's less that it's bad (in my opinion) and more that on Android you have a much wider range of hardware to support ranging from quite new and recent, to basically ancient almost flip phone level.
I am hoping that in the future something like React Fiber (https://www.youtube.com/watch?v=aV1271hd9ew) will make its way to React Native and unlock a new level of performance.
The core Android team is four engineers so about double in size.
This makes some sense since on Android we have to re-write most of the stores/business logic and not just UI. We have modeled the architecture similarly to things on the Desktop/iOS side so we still are able to move fast and stay lean as a team.
Sure,
When we originally got it running on Android (without the chat view since that component is native in the iOS app) we found that it performed quite poorly due to most of our pages being heavy on data and UI - as well as being very reactive (a typical discord server might have hundreds of permissions, messages and users all changing/updating in real time). React Native is single threaded and while iPhone’s have great single threaded performance, Android phones are more reliant on multiple cores and RN as I understand it mostly can’t take advantage of that.
On higher end Android phones the performance was actually fairly acceptable out of the box, but our user base has a lot of gamers who are running very old Android phones from many years ago - and in those situations the lag was unacceptable. For iOS, most users tend to only last one or two hardware generations behind.
Additionally, at the time React Native for Android had just been released and there were a whole host of other issues at the time - bugs and lack of Android specific components like the Navigator (which have since mostly been ironed out).
Today I think it is possible to build a fast React Native Android application and I would recommend someone starting from scratch do so :). However now the challenge is that we have an existing Native Android app so our users already have a baseline expectation of feature parity and performance. If we switch over we must meet or exceed that bar.
Hi all, Discord engineer here! If anyone has any questions about the post or our experience using React/React Native the team would be happy to answer them!