
The Guide to React Native for the Non-Technical Founder
There are hundreds of development frameworks. They can get quite confusing to the non-technical founder which often leads the non-technical founder to leave it to the engineers. However, should you leave the very basis for an entire company up to a single group? The decision seemingly small at first but has a significant impact across an organization going forward.
React Native, developed by the Facebook engineering team, is picking up significant traction within the development community. We had one of our FirstMark founders, Dan Bersak, co-founder and CTO of HuddleUp, give the FirstMark Code Driven community an overview.
React Native Is:
- Developed by Facebook
- Based on ReactJS / JavaScript
- Written in JavaScript / JSX
- Boils down to native components
- Fast! (Sometimes)
React Native Is Not:
Highly Iterative & Great For Speed
With most frameworks, including React, the developer creates a build, tests it in a staging environment, then pushes that build live to app stores. Since React boils down to native components in JavaScript bundles, you can easily use tools like CodePush to literally swap out the JavaScript bundle and make tweaks on the fly. That means if there is a typo you don’t have to wait 48 hours for App Stores to approve your new release. These 48-hour cycles add up incredibly quickly and slow down the productivity of your engineering team.
Having this level of flexibility is incredibly powerful, especially as you scale, for everyone in the organization including growth and marketing teams. If you want to run a split test, you can easily create a new version of a bundle and serve it to half your users.
Real Native Components
React is fundamentally native. This means that the code runs as if it were built for each platform, regardless of device. This makes the application run more seamlessly and effectually.
Other development stacks like LAMP (Linux, Apache, MySQL, PHP) are built mainly for web and, in most cases, separate code bases are maintained for mobile.
Slack, for example, was built on a LAMP stack. For the Mac app they originally used MacGap which essentially transforms their current code into a Mac application.
While this is great at the onset, performance suffers as you are basically serving your website via the WebView which is an HTML interpreter. Additionally, you are not taking advantage of the client’s power, in this case macOS.
The Caveat
If you have ever used JavaScript, you know that JavaScript is single threaded. Due to this limitation, you have to be mindful of how you build your application and how much you are requesting the app to process.
Some Things you Should Know
1. You Can’t Use the Same Exact Code for Both React Native and React.js
Your code written in React Native cannot be directly applied to ReactJS or vice versa. There are differences in syntax and structure which must be considered. For HuddleUp, they have found around 60% overlap. The good thing is the changes are minor and React has parts of the logic built in allowing for easier integration.
2. You Can Mix & Match Native & React Native Components
As mentioned previously, a constraint to React is it being single threaded. To get around this limitation, React allows you to mix native code developed for Android/iOS with React code.
3. It’s Growing
There are already projects on GitHub which allow you to use React with lots of other platforms from Windows, macOS, AppleTV, Xbox, and Ubuntu.
Final Thoughts
One of the huge benefits to React comes from the talent pool. At HuddleUp, they found most JavaScript developers are able to start building and contributing from day one even without direct experience building for mobile.
A recent survey by Stack Overflow of 50,000 developers confirms that JavaScript is the most popular by far with 85.3% of full-stack developers and 90.5% of front-end developers reporting they use JavaScript. This means a much larger talent pool to hire from, especially for full-stack engineers.
Like what you see? HuddleUp is hiring talented engineers like you.
Are you a developer or want to hear from some of the brightest engineers on the bleeding edge? Come join us at the next Code Driven conference on March 22nd where we talk with Mark Wunsch (Harry’s Director of Engineering), Karl Norling (Software Engineer at Quartet Health), and Chris Dickson (Co-Founder and CTO of parsec.tv).
