> In the React Native repo, we sometimes see hot issues with limited activity in response from Facebook. Lack of visibility into such a large company can bring about frustrations when so many people depend on their open source contributions.
On the other hand, it forces us to dive into the core codebase in order to figure out the problem, which admittedly one of the best ways to learn an open source platform. By understanding the React Native platform deeply, we were able to maintain a fork that fixes issues for our own use cases and reuse their core modules.
I guess that's one way to sugarcoat the fact that you're at the mercy of Facebook being timely in fixing bugs here…
This right here. I hope companies stop fearing contributing to React / React Native (and ANY open source project they rely enough on). I think companies that make plenty of revenue off of certain open source projects should invest resources into said projects. If you patched some part of the project, contribute it back! It will only benefit you in the long run instead of running frankenforks of the code, and ultimately if it gets abandoned, offer to continue to maintain it!
I wish more companies would give developers about 10% of their time to develop things they think would benefit the company, whether it's internal tools or open source projects they rely on (or building new things). Just give devs every Friday or every other Friday with free reign to code or learn new things.
Ah well... If the projects they rely on stop being maintained they just suck it up and let it foster eternally till forced to migrate.
Dear Discord:
Your bread and butter seems to rely upon React / React Native. It's an open source project, pay your employees to contribute to it!
Hi! I'm from Discord and we do contribute to React/React Native! I have to say it's quite an adventure to dig through React Native's issue tracker only to find that your CTO's PR has been merged :P
That's good to know, thanks for the context, didn't mean to assume just wasn't sure, been so busy at work today so hadn't read the whole article yet. That does sound pretty awesome! I hope more companies do contributions like you guys do. Facebook kickstarted the project, doesn't mean they will run it forever, eventually the torch must be carried by the community.
It is actually quite hard to keep up to date to many open source projects: issues, new features, and the whole are of knowledge it works on... if they really need to take another direction and still want to keep the framework that would become a huge big ball or technical debt which many companies cannot pay or would rather invest on moving to another framework.
This is a common gripe with a lot of open source software, but from issues I've had to track down, Facebook is downright inviting on saying if you have an issue and you know how to fix it, submit a PR and we'll merge it.
Their priorities may not align with yours, but it's not such a bad policy. If you don't like it, fork it?
They will absolutely merge in fixes, though they may well not be timely if they're not from internal engineers. I've had broken behaviour sit in a PR for over 6 months before.
Recently watched Angular Material first dismiss a glaring problem with datepicker, then sit on their hands [0] while some bloke made a complete fix, adjusting anything they brought up, then sit on their hands again [1] after it was finished until someone started building pressure again.
[0][1]: I didn't actually verify that. They might have had some really busy days. Point is they stuck to Google communication policy: try to not say anything at all.
"as long as you sign our CLA, which requires you give our lawyers your personal information, including information that you might not have. Don't have a phone or permanent address? hahahaha get lost".
Facebook's lawyers did some very questionable things to "open source" here.
They need to be absolutely sure that accepting contributing is not going to bite them,so you have to sign over all rights to the code to the project owner. They own the code from that point on, not you. This is standard behaviour.
Facebook differs from the standard in that they require your address, but I assume that is to make sure the CLA has the correct form
Signing over rights is one thing. Discriminating against people without a permanent address, or a phone, or any other person who can afford a laptop and not much else, and has high value contributions to make if only they would be accepted, is being an ass to humanity and you should feel bad and change that.
They even require you to sign their CLA just for README.md updates - that's not "being safe", that's "being willingly idiotic".
Facebook legal is not interested in changing the CLA requirements to something that doesn't discriminate, and despite the rather large number of people who work on their open source projects, who would all love for that CLA to fuck off so they can do open source properly, Facebook as an organisation is still not a good citizen in the open source space. They're still trying to put up a walled garden as much as they legally can, even if you think you can't see the wall anymore.
Its free & open-source. You're not at anyone's mercy. You can fix it yourself if you like, pay someone else to fix it, or use a paid solution that pays its devs to maintain it.
Complaining about FB not prioritizing/fixing the particular issues that affect you the most seems a little bit insane to me. Of course they have their own priorities.
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 support library sources have been published to AOSP for a long time now. And as of recently, they're even developing most of them in AOSP (as opposed too merely syncing changes there occasionally):
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.
Maybe a bit pedantic, but, isn't RecyclerView in the support library which is open source? And since the support library is bundled with each app, you actually could fork it and ship a customized version with your app if you wanted.
Embarrassingly, I work for a company that has copied several of the recycler view layout managers out and customized them. And that new Work Manager is unusable right now without in house fixes...
I think the point is that they took the time to ensure they're not at the mercy of Facebook.
Regardless, you're really at the mercy of _any_ maintainer of components you depend upon heavily. It's a fact of life unless you feel like building it all from scratch.
It's leagues better than what they do with some of the less popular FOSS projects they run, such as HHVM/Hack. What FB have done there has become an existential threat to some tech companies that heavily bought into Hack.
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.
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!
Is Discord really using 2GB of RAM for you? Can you clarify what you mean by regularly? Discord (including all of its helper processes) is only using 190 MB of RAM for me at the moment.
The screenshot below was a particularly bad day... but Discord, Skype and Slack (all javascript "applications") compete continously for eating more ram than my actual work stuff.
Edit: for those who don't want to click, it's a screnshot of the os x activity monitor showing the worst memory consumption, in order: Discord Helper 1.98 Gb, kernel_task 1.67 Gb, Skype Helper 1.58 Gb, Slack 1.20 Gb :)
Modern RAM doesn't work the way people who complain about Slack/et al think it does. The operating system will cull it from other places when it needs it; even a native Cocoa app will not dump memory you're done with until the system decides it needs it for something else, because on the off-chance your app ends up needing it again, it's already allocated. "purge" exists for a reason.
It's like when you pull up a StackOverflow answer for "how can I judge how much memory usage my process has?", and the top voted answer is some bash script to determine peak ps, when every other answer tries to explain that that's only one measure of memory and isn't even totally accurate.
Furthermore, that nice feature of most modern apps where you're scrolling up rapidly and an image is nice and ready to present? Images are big, especially when we all use retina displays. They take up memory. There was a blog post that went on HN a few months ago but didn't seem to make the front page, wherein the author determined that forcing Electron to dump image cache junk lowers the memory usage substantially.
Could Electron & co do better? For sure. Loading an entire browser for a UI does kind of suck. But stop acting like all the stuff that the browser does for you _for free_ is or should be zero-cost.
If the memory consumption of a process grows from 200 M (which is about what the chat apps use when freshly started) to 2 Gb, something is rotten by any metric. The system was responding slowly when I made that screenshot because it started using swap. Which got instafreed the moment i restarted the memory hogs.
If i don't restart the machine for a year, is the pretty chat app going to keep in ram, uncompressed, all the cat pictures that people posted in the last 12 months then? Do you think that's sane?
> If the memory consumption of a process grows from 200 M (which is about what the chat apps use when freshly started) to 2 Gb, something is rotten by any metric.
That is just not how memory works anymore, at least not how the OS reports it to you.
> The system was responding slowly when I made that screenshot because it started using swap.
How did you determine this? If you're looking at swap usage in activity monitor, this is also not an accurate metric. I'm sitting here with 14GB used, 18GB free and 2GB of swap usage. Using swap does _not_ mean you are out of ram, it just doesn't work like that.
Is the memory pressure graph in activity monitor yellow or red? If not, which is likely the case, you don't have memory issues. You don't need more memory and it doesn't matter how much memory your applications are using.
I don't know the details of "how memory works anymore", but I do know that on my Fedora 27 laptop, everything stays nice and snappy, with under 200mb swap used, as reported by the system monitor...
...until I hit 8 gb of ram (the amount installed on my machine). The second that happens, the entire OS grinds to a halt. It starts with 5-10 seconds to change focus, and can go as high as 5 minutes if I don't do something about it. My best option for dealing with it is usually opening a new console (Ctrl-Alt-F3) and killing Android studio or the gradle daemon (the most common culprits). If I'm able and patient enough to open system monitor at this point, I can see that my swap usage has increased dramatically.
Again, I can't speak to "how memory works", but I am absolutely the expert on how my computer performs, as described above.
I've had similar experiences. Often Firefox is what's eating all the RAM, and I'm viewing it with htop. I've had cases where the freeze is indefinite and I had to hold in the power button. Couldn't change to another TTY or even ssh into the machine. When people say SWAP isn't needed, I just get mad. I've delayed these halts a bit by having some SWAP available. If I ever get slowed mouse movement, I panic and quickly check RAM usage and determine what has to be killed or restarted. I don't really understand why people pretend this doesn't happen and that unused RAM is always wasted RAM.
> ...until I hit 8 gb of ram (the amount installed on my machine).
I'm assuming you mean 8GB of ram 'used', by some metric of 'used'. What tends to confuse the hell out of people is what 'used' means. It varies by how it's measured, what OS you are using and how that OS is configured. I haven't a clue how Fedora 27 is configured nor how you are determining 'used' RAM, so my comment may well not apply to your use case.
And frankly, it seems to me like the issue is the OS being unoptimized or apps being leaky on it, because my Windows 7 machine with worse specs almost never has such issues, under any kind of similar load (and exactly the same apps).
Quit it. It was 32 Gb used (i.e. all of it, maybe 1-2 G left for cache) plus 5-6 G of swap.
I don't know how your OS X works, but mine tends to not go into swap before running out of ram. It does not come out of swap when ram is freed indeed, but when you freshly boot it it will stay at swap used: 0 bytes until someone posts too many cat pictures in Slack or Discord.
Or until i forget how many VMs I opened, but that's work and actually useful.
Edit: I can't reply to your reply because HN doesn't like so many indents. I also don't want to continue a flame war about observed behaviour vs the theory of shared libraries and memory mapped files etc so I'll stop here.
RAM is fast, disk is slow, network is really slow. Your operating system optimises for performance. Minimising RAM usage is bad for performance, because empty RAM is wasted RAM.
If your RAM is full, there is a probability that something will need to be read from disk. If your RAM is empty, there is a certainty that something will need to be read from disk or from the network. A probability of a slow operation is preferable to the certainty of a slow operation. Something in RAM is preferable to nothing in RAM.
The pretty chat app will not keep all of your cat pictures in RAM indefinitely, because the OS won't let it. If something else needs that RAM, then the cat pictures will be paged to disk. The OS is incredibly good at figuring out what belongs in RAM and what belongs on disk at any given moment.
> RAM is fast, disk is slow, network is really slow.
(all speeds are read time)
RAM speed: 35 GB/s
Disk speed: 3.2 GB/s
Network speed: 0.87 GB/s
While you aren't wrong, I have no problem loading cat pictures at network speed instead of ram speed.
I think the real issue here is network consumption is expensive. It's better if you store all your cat pictures for as long as possible. People would complain in discord generated gigabits of temporary disk files, but RAM usage can always be freed if the OS demands it.
Paging to disk makes it act much slower than simply releasing the memory when that cat has been off the screen for a moment. It is not a good solution.
The 2GB in his screenshot means that 2GB has been malloc'd and used. RAM reported as in use by an application is not being used by the OS to cache things.
RAM that's reported as "free" by OS X's activity monitor/windows' task manager is used for disk caching.
RAM reported as in use by an application is in use by that application. It could be using some sort of internal cache, but it does not give that memory up to other apps under memory pressure except by the OS swapping it out which gets very slow.
If I understand correctly this is true for the memory allocated by the os to cache files which makes intuitive sense as a file can just be read from disk if needed.
Its not clear to me how it would apply to other memory how does the os communicate to Firefox that it needs to clear out some memory for Chrome save by moving less used pages to swap with the probable high cost, of moving it back later. Further while some intelligence may be exercised insofar as which pages to swap it won't be made with the benefit of the app deciding which chunks of data to keep closer at hand.
Modern memory works the same way it always has and the best performance has always been maintained by staying within the boundaries of available ram and not needing to swap much.
When most computers have no more than 8gb of ram and consumer machines are likely to have 4 its kind of silly for a chat app to use 1-2 sillier yet to claim that the os will fix the matter.
When you calculate the sum of the so-called "memory consumption" of all processes, you generally end up with a number ridiculously above your the amount of physical memory installed on your box.
The only reliable way to learn the memory consumption of a process is to somehow make sure other processes don't allocate/deallocate memory, kill the process in question and watch the difference in global memory consumption.
The post says, "it’s roughly 1.5s startup delay to load a 15mb bundle on an iPhone X."
I've seen startup latency much slower than that on my iPhone SE. In the best case, the application takes about six seconds to cold boot when I tap on a notification. Sometimes it's closer to fifteen or twenty seconds if the app sits on the "connecting" screen for a while. It's difficult to understate how much slower the app feels than everything else on my phone.
Hey, blog author here! The startup delay is the extra initialization time that React Native needs. Translating into our discord iOS app, it is the duration of the screen with spinning mascot and quote rather than the entire duration fully connect to our gateway socket. In our test case, its about 4s delay on iPhone SE.
Meanwhile, we keep working towards to improving our user experience on all the devices especially the lower-end ones (I personally use iPhone 6 as my go-to test device). For instance, we will add caching very soon to shorten the interaction waiting. Hopefully you will enjoy more using Discord on your SE then :)
The X is the most expensive iPhone you can buy right now, and the SE is the cheapest. Too bad engineers practically always have the top-end models, so they don't really have to dogfood the everyday pain of using the slower devices.
Actually I don't own an iPhone X :P Our core user base tends to use 6 and above (approx 2 generations behind) and we dogfood regularly with a huge group of beta testers (thousands) with a huge range of hardware. We try our best to make sure the average use case is considered.
Considering the average is good but it still pushes the performance treadmill forward.
If we had some magical way to make the dev treadmill run slower than the user treadmill, we'd see better architectures in many cases. In that alternate world it would be easy to precompile the javascript and load 20 times faster.
As an iOS dev, I use my personal phone (iPhone X) for the bulk of my dev/test cycle but also keep around an old-ish iPod Touch running the previous version of iOS that I dev/test on periodically as well. If something doesn’t perform adequately on the Touch, I tweak on it until it does.
iOS users tend to run newer devices generally which might lead some devs to feel that this extra optimization isn’t worth the time it takes, but I disagree because it doesn’t benefit only users with older devices – it’ll make your app run better on newer devices too and make it that much more unlikely that your app gets killed or causes the OS to kill other apps in multitasking scenarios (iOS kills resource hogs much more readily). In short, everybody benefits.
With this same thought process, I plan to pick up one of the 120hz iPad Pro models to test on soon. It’s one of the most powerful iOS devices available, but driving 120FPS isn’t easy and given how many apps fail to hit the target of 60FPS on similar hardware I’d bet that a huge number, perhaps even most, don’t come anywhere close to running at 120FPS even with the extra horsepower.
* 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.
This is not related to the post but I have an honest question. I use nitro(and absolutely love it) and I'm constantly getting inquiries about how I use blobs. There are literally 5 accounts I would happily gift a nitro subscription to but dont have the option. When is discord going to allow people to gift nitro to other accounts. It's a huge potential revenue stream and something I would happily engage in if I had the chance to. Thank you for your work. I love discord.
Awesome post, and it's really impressive what you have managed to build with such a small team! Could you go into more detail regarding your problems with Android? Poor performance of touch events seems like the kind of thing that would make RN/Android unsuitable for most teams, so why does it have such widespread adoption?
Any other insights would be great, as I'm planning to start converting my web app to RN in the next months and didn't know Android would be a problem.
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.
As a user of the iOS app it used to have some admittedly frustrating problems, but pretty much every complaint I had previously has since been fixed, huge kudos on the progress you've made!
The only thing left that really bugs me is the fact that you can't paste images from the clipboard into the message field. It's made me change my entire workflow, from copying images to saving them.
Sorry to use this as a soapbox for my pet issue, but I saw the opportunity :P
Thanks a lot for the writeup. We've been using react native for a while now at our org and while we aren't native developers, we are getting along really well.
One question that popped up in my while reading the article was would you consider doing the android app in react native if you had to start now ? Or do you still feel it lacks the coherency it has with iOS.
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
Why, starting I think about 30 or so days ago, does Discord start using insane amounts of CPU time when it is started on a system that doesn't have network connectivity? On a Surface 3 Pro, A newer laptop, and a desktop system I have seen this happen. It will just use 20-40% of available CPU unit networking is restored.
Not related to React/React Native, but I was wondering if there was a way to show a users online/idle/offline status through an API call or if there are plans too.
I've been using Discord's OAuth and that's been nice, but I what I'd really like is to display that status on my site.
Why on earth don't you have a separate button for emoji on iOS like you have on Android? Having to manually type :emojiname: every time is absurd. Yes, I know it shows a list when you start typing but it's still horribly cumbersome.
Sorry to hear that your Canary experience is not great :( Have you tried our stable Discord release? Canary will always have instability to it. If stable Discord still jitters for you please contact us (https://support.discordapp.com/hc/en-us) and we can diagnose better.
Why do I get feedback on discord, but not Skype for Business ? Have tried 3 different mics of different types and messing with the settings constantly. When I say feedback I mean my speaker output going as input to everyone else.
I'd suggest reaching out to our CX team ([email protected]) - 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.
I quit Facebook lately and moved to Discord for my group chats, cause we already had the channels from gaming.
It is good, but we all have trouble with the notifications. (this has nothing to do with react native but you are here and this is a gripe). Like if you have it running on a computer it doesn't come to your phone. So we have tons of miss-communication for stuff like "yo I am drinking near your house meet-up". Discord just sits running all the time on your PC, which for most is running all the time. So I stopped using it for time sensitive messages which sucks. I would never dare use it for a "Hey I am buzzing outside your house answer". You literally have no idea where the notification for the person is going to go. FB-Messenger never had this issue.
My biggest issue with notifications on Android is that when I tap on them, they rarely take me to the same server, channel, and ___location where the notifications came from which leads to me trying to hunt them down from the brief time that I saw them.
My group of friends did the same thing, we moved from group texts (Which became a huge mess) to Slack — not because we like it better than Discord or anything, mostly we're using Slack for work anyway, so it made sense to make a group there.
Works a lot better than group texts, and with better file sharing to boot. We'll still text each other for 1:1 conversations where we're not near a computer.
We'd switch to Discord if Slack's free offering is ever gimped.
I keep Discord running on my desktop at work, plus I tend to have browser windows connected to it on my both my desktop and laptop at work. I still get phone notifications.
It does have that. No idea why it wouldn't work for GP. If I lock my computer, or don't look at the Discord tab for a few minutes, my phone gets notifications.
Just to add my experience, I feel like it's hit or miss. It seems like I get notifications with zero issues. Then I'll randomly have a week or two in a row where I don't get notifications or get 50% of them. Not sure why this happens, but I use Discord as my only means of contact with multiple people.
Interesting. For what it's worth I am using Discord on Mac Safari (not TP), Win Chrome 69 (dev channel), and iOS. In one year I have not had any of the issues mentioned above. Perhaps using the desktop app can introduce problems.
Yeah it just doesn't work well for me or my friends we are always complaining. I don't know why and I don't really want to have nerd out with my chat app (just want it to work!).
As for using Slack, I am too scared of dropping 3am Friday/Saturday messages in my work chat instead of my group chat so keep separate apps.
The usual idea I hear is that React Native might be a good idea for a small company with an uncomplicated app, especially if they use the React stack on the web.
However when one grows and starts competing head to head in the App Store or Google Play with the other top social or finance or music or whatever apps, the ones who have expert teams with familiarity with the specific Android or iOS platform will pull ahead. Particularly as you can still have a (mostly) common REST API backend, base things off the same design mockups with some modifications, and so on.
Discord is actually an extremely complex app and run almost entirely off React Native, with 2 engineers, only 1 of which who is an iOS expert :P! We have millions of users, and we typically rank in the top 10 of Social Networking on the iOS App Store. We are excited to share our success story of being a "big" company using such a product.
I was very surprised to hear discord used RN because I found that I had to break down and use native code to deal with a lot of multimedia and a few other things that aren't just displaying text. I still loved RN, I just maybe naively hoped I could do everything with it.
Is that your experience too, that a good bit of native code is required (with RN serving as glue and handling simple screens), or have you avoided that somehow?
Personally I have found that RN does require some amount of native platform knowledge to be successful. However, the bulk of our app is actually in React Native. The times we've had to bridge into native is mostly around our voice modules or things that, in RN, were not very performant (like poor list performance) or required synchronous updates (like the keyboard problem mentioned in the post). Certain multimedia objects RN doesn't support out of the box but the community has come to the rescue (ie: https://github.com/cornedor/react-native-video-player for video).
In practice, most of it is wrapping "RCT_EXPORT_METHOD" around native code and importing it into JS.
Even if you had to write half the app in native code (which you won't), you're still far ahead of having to write it all in native code on both platforms.
Agreed. Creating bridging modules aren't that complicated. For anyone interested, I've linked a sample of a bridging module from my open-source project, for both IOS and Android. See [0] & [1]
The bridge creates an interface between an embedded webserver to react native.
Things to note:
1. Always dispatch bridging methods to their own threads. On IOS you can do this via. dispatch_async. On Android, you can utilise native threads or some kind of task management library. I like Bolts [2].
2. Always create bridging methods that resolve promises. This makes it easy to utilise async / await paradigm on the JS side.
This post is interesting because at the bottom, Discord is soliciting for engineers. Gabriel Peal from AirBnB came and gave a talk at our company a few weeks ago and he shared at after AirBnB published their 5 part medium series[1], they got a huge flood of mobile developer resumes.
Yeah. I guess my point is that they are trying to get web/mobile engineers, but the data from AirBnB shows that the opposite of this post is what actually attracts mobile engineers.
What AirBnB showed is that there are a load of mobile engineers out there who don't want to work with React Native.
What Discord might show is that there are also a load of mobile engineers out there who do.
Personally I find it baffling why anybody would choose to work with anything based on JavaScript (I'm grumpy enough about having to work with something as primitive and loosely-typed as C#, so I find JavaScript an endless horror show), but there are people sitting right near me in my office who work on frontend web code all day and chose to do that and actually enjoy it.
So really, I guess I'm saying we're all different. And that's a good thing, because there are lots of different jobs we need to get done to keep all these systems running.
They probably got a flood of applications from native mobile engineers who want to work for a successful company who's new architecture direction aligns with their existing (native framework) skills.
If the announcement was the other way around (we're going from native to react native!) I bet they would have gotten a similar flood of web/rn engineers.
I don't really see a problem with them doing that. I'm not even sure I'd consider it manipulative. They walk through some design decisions, talk about their codebase, at the end say "if this sounds interesting to you, think about working for us."
Just because it benefits them doesn't mean it's exploitative or bad.
What tool/service/library are you using for OTA updates? Could you share any best practices around managing the roll out (do you push to everyone, a subset, etc.)?
Hi! Not Fanghao but another Discord iOS engineer. We wrote our own library for OTA updates but React Native Code Push (https://github.com/Microsoft/react-native-code-push) is a pretty reasonable out of the box solution. Because our OTA solution is designed for hotfixing issues rather than feature releases we push to everyone, and we also have a flag that forces our users to relaunch the app if the bug is app breaking.
How do you comply with Apple's App Store Review Guidelines when using this (specifically, this clause):
2.5.2 Apps should be self-contained in their bundles, and may not read or write data outside the designated container area, nor may they download, install, or execute code which introduces or changes features or functionality of the app, including other apps.
Also,
> we also have a flag that forces our users to relaunch the app if the bug is app breaking
Apple allows updates to Javascript outside of the review process as long as it subscribes to certain guidelines (1), including but not limited to: not changing core feature functionality, being limited to bug fixes, and also that the app doesn't provide unlimited access to native SDK or system functions. React Native provides a limited API to js code so it's fine.
As far as your second question, we simply deploy store logic that loads a Modal telling our users that they must relaunch the app.
Since OTA updates can only impact JS, we can offer a button that essentially calls something like `window.refresh` and it reloads the JS bundle within the container. We actually recently leveraged ErrorBoundaries in React 16 to do something similar in our app as well.
That doesn't quite answer the question like victoriasun did–you can execute code not in the binary (e.g. JavaScript), but it doesn't say that you can download new code and execute that.
I've used code push before and didn't really love the lack of visibility into what was running on the other side, it also feels really risky to make it a core part of my app considering that microsoft has already changed direction on backend hosting for code push at least once.
Any chance you could share any info about the architecture design of your homegrown system? I've seen a few snippets where devs build their bundles and host them in s3, how complicated was it for you to roll your own OTA solution? Would you guys do it again or would you use Code Push?
Our architecture design is honestly pretty simple. Before the app fetches the JS bundle it checks a hash to see if it's on the right version, and if not, it fetches the other one instead. I honestly don't know enough about code push to speak to it, so I can't really answer this question. Generally speaking however, we try to be cognizant of increasing the amount of dependencies we have while still optimizing for speed.
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.
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.
The Discord iOS app has millions of daily active users and 4.8 stars with over 240k ratings. This has all been accomplished with a team of two engineers!
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.
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.
I wonder if, one day, Discord will get around to fixing the fact that once you have more than 3 channels and get a notification in more than one, your mobile notifications do not go to "newest" they go to the "channel highest on the sidebar".
This is why I really hate tools like react native. They try and create a code symmetry and that's not unreasonable, but then they go too far and create behavioral symmetry and that's pretty much unacceptable for as wide a gulf as browser apps and mobile apps. They have such radically different use cases.
Actually, behavioral symmetry is not an issue with React Native so much as its an issue with poor UX design. Nothing about RN mandates that the apps behave similarly. That the iOS app and the desktop app look and behave similarly is simply a design choice made by the team to maintain a consistent look/feel/UX across the apps, not RN itself. We do not share Views. All Views across all the apps are custom.
However, as Discord's mobile teams grow and expand we're exploring alternative UX designs that are significantly more mobile friendly. So your feedback is heard loud and clear at HQ :)
> Actually, behavioral symmetry is not an issue with React Native so much as its an issue with poor UX design. Nothing about RN mandates that the apps behave similarly.
I think the economics of RN strongly do though. Why would you use RN if you aren't planning to reuse code between environments?
The economics of RN allows us to share the last 4. However, sharing the first is actually more or less impossible without tooling like react-native-web as the components that exist on a native iOS app and the components that exist in HTML are just different. Certainly you can argue that sharing this much business logic would necessitate that the UI layer looks all the same, but I fundamentally disagree. That is like saying that because all your clients use the same API, they all must look the same.
I guess there is an implicit value judgement here that React+Redux's approach is desirable for your team, so that motivates using utility libraries not optimized for the constrained environment and a FRP framework with those characteristics.
Yes, this is 100% correct. That being said you can also create a React app using FRP framework such as Cycle JS and share exactly the same amount of code that I've listed above. Our team has chosen to go the React/Redux approach; I would argue that as an untyped language Javascript is unsuitable for FRP in the first place, despite FRP's advantages in handling reactive UI.
It was that you had disabled right click on the join server page in Chrome, it is generally considered bad practice, but somehow I liked it since it reinforced the game interface feeling.
I guess that's one way to sugarcoat the fact that you're at the mercy of Facebook being timely in fixing bugs here…