Electron vs React Native: What are the differences?
Electron belongs to "Cross-Platform Desktop Development" category of the tech stack, while React Native can be primarily classified under "Cross-Platform Mobile Development".
Some of the features offered by Electron are:
- Electron is open source
- maintained by GitHub and an active community.
On the other hand, React Native provides the following key features:
- Native iOS Components
- Asynchronous Execution
- Touch Handling
"Easy to make rich cross platform desktop applications" is the top reason why over 50 developers like Electron, while over 170 developers mention "Learn once write everywhere" as the leading cause for choosing React Native.
Electron and React Native are both open source tools. React Native with 78.3K GitHub stars and 17.5K forks on GitHub appears to be more popular than Electron with 74.4K GitHub stars and 9.72K GitHub forks.
Yahoo!, hike, and Webedia are some of the popular companies that use React Native, whereas Electron is used by Slack, WebbyLab, and triGo GmbH. React Native has a broader approval, being mentioned in 701 company stacks & 781 developers stacks; compared to Electron, which is listed in 213 company stacks and 366 developer stacks.
What is Electron?
What is React Native?
Need advice about which tool to choose?Ask the StackShare community!
Sign up to add, upvote and see more prosMake informed product decisions
Sign up to get full access to all the companiesMake informed product decisions
Sign up to get full access to all the tool integrationsMake informed product decisions
The Slack desktop app was originally written us the MacGap framework, which used Apple’s WebView to host web content inside of a native app frame. As this approach continued to present product limitations, Slack decided to migrate the desktop app to Electron. Electron is a platform that combines the rendering engine from Chromium and the Node.js runtime and module system. The desktop app is written as a modern ES6 + async/await React application.
For the desktop app, Slack takes a hybrid approach, wherein some of the assets ship as part of the app, but most of their assets and code are loaded remotely.
Slack's new desktop application was launched for macOS. It was built using Electron for a faster, frameless look with a host of background improvements for a superior Slack experience. Instead of adopting a complete-in-box approach taken by other apps, Slack prefers a hybrid approach where some of the assets are loaded as part of the app, while others are made available remotely. Slack's original desktop app was written using the MacGap v1 framework using WebView to host web content within the native app frame. But it was difficult to upgrade with new features only available to Apple's WKWebView and moving to this view called for a total application rewrite.
Electron brings together Chromium's rendering engine with the Node.js runtime and module system. The new desktop app is now based on an ES6 + async/await React application is currently being moved gradually to TypeScript. Electron functions on Chromium's multi-process model, with each Slack team signed into a separate process and memory space. It also helps prevent remote content to directly access desktop features using a feature called WebView Element which creates a fresh Chromium renderer process and assigns rendering of content for its hosting renderer. Additional security can be ensured by preventing Node.js modules from leaking into the API surface and watching out for APIs with file paths. Communication between processes on Electron is carried out via electron-remote, a pared-down, zippy version of Electron's remote module, which makes implementing the web apps UI much easier.
For a front end dev like me, using a mobile framework for side projects makes more sense than writing a native app. I had used Apache Cordova (formerly PhoneGap) before (because React Native didn't exist yet), and was happy with it. But once React Native came out, it made more sense to go that way instead. It's more efficient and smooth, since it doesn't have the simulation overhead, and has more access to hardware features. It feels cleaner since you don't need to deal with #WebView, using native UI widgets directly. I also considered Flutter . It looks promising, but is relatively new to the game, and React Native seems more stable for now.
I've recently switched to using Expo for initializing and developing my React Native apps. Compared to React Native CLI, it's so much easier to get set up and going. Setting up and maintaining Android Studio, Android SDK, and virtual devices used to be such a headache. Thanks to Expo, I can now test my apps directly on my Android phone, just by installing the Expo app. I still use Xcode Simulator for iOS testing, since I don't have an iPhone, but that's easy anyway. The big win for me with Expo is ease of Android testing.
The Expo SDK also provides convenient features like Facebook login,
MapView, push notifications, and many others. https://docs.expo.io/versions/v31.0.0/sdk/
The capability of style customization is one a large deal breaker for frontend SDKs. To solve this, we decided to use styled-components in our SDK, which makes it easy to add support for themes on top of our existing components. This practice reduces the maintenance effort for stylings of custom components and keeps the overall codebase clean.
I am starting to become a full-stack developer, by choosing and learning .NET Core for API Development, Angular CLI / React for UI Development, MongoDB for database, as it a NoSQL DB and Flutter / React Native for Mobile App Development. Using Postman, Markdown and Visual Studio Code for development.
Our application began as an HTML5 browser game, however we decided to leverage certain native parts of desktop applications by wrapping our client code into Electron. This also allowed us to not have to worry about compatibility across all the various browsers.
React Native is great in that it reduces the overhead of writing native code based on a web app. If written in a good style, Redux part of the app can often just be copied or shared in the Native app - and it just works! What a timesaver.
Our Web Applications are served on our Desktops by Electron. This allows us to have native apps running on our Workstations without having too many Browser Tabs open at the same time.
The framework used to write the mobile apps in this project. I've chosen this because of the "write once run all" (ios and android) mentality.
We are not currently using this product but we have very high interest in learning and using this for mobile apps.
Electron is the current preferred method to convert games made in the Game Pencil Editor for desktop support.
Implement a web-service using your favorite tools but sell a desktop application for oblivious windows users.
New features of our app are developed on React Native, so we could maintain a small dev team.
100% of our mobile codebase is shared between iOS and Android. Using along with TypeScript.