What are the top 3-10 things holding react-native back?
I think React Native works great already for many applications. Some things that are preventing it from gaining even wider applicability and adoption, I believe, are:
- ListView: no view recycling, so certain things (eg: contact views) are difficult and others (eg: feeds) use tons of memory.
- Gestures: difficult to have related gestures on a view, needs to be written monolithically right now using PanResponder.
- No high-quality, blessed solution for navigation -- this is problematic because the fragmentation leads to duplicated efforts and lots of confusion for newcomers. This is being addressed with react-navigation: https://github.com/facebook/react-native/wiki/Roadmap#core-libraries
- Many one-off native implementations of components that should just be implemented in JS. Often this is done because of some current limitation in React Native. For example: https://github.com/exponentjs/exponent/issues/14#issuecomment-262836018 -- rather than implementing a custom activity loading spinner natively, it would be better for people to find the underlying reason why they think they need to do that and resolve it. In this case it would be implementing Animated.loop and supporting
useNativeDriver: trueon it. This leads to people installing tons of libraries that end up not being maintained and having many more native dependencies than they need.
Can you talk about Exponent's road map? What are your plans for custom components?
The Exponent project roadmap is guided by the needs of product engineers. The feedback and requests we get from Exponent developers helps prioritize our projects across our mobile apps, APIs, and developer tools. One part of our APIs we get a lot of questions about is native modules.
How do I become a badass programmer like you guys?
Are you ever gonna support web? With something like react-native-web?
I've been surprised by how much I like react-native-web. I actually find I prefer React Native development over React web development because of things like CSS-in-JS and having React feel more first class rather than just grafted onto the DOM. Excellent work by necolas.
I would be happy if someone build a tool for Exponent apps that would let them be easily targeted at the web via react-native-web, but we probably won't build it anytime soon.
We have a small team and our focus is supporting iOS and Android.
When people build for those things, there aren't always analogs for react-native-web that work, so lots of Exponent apps would feel really broken if you just tried to run them on a web browser with no changes.
A more straightforward way to target desktop computers would be for us to support the React Native on Windows and OS X targets. I'd love to do this as well, but its another thing we won't have time for anytime soon.
I do wish there was an easy solution to this though since so many developers end up frustrated when they have to build a mobile website and a mobile app, that end up slightly different. It would be a huge win for developers and users if it was possible to target iOS and Android native apps and also get a fully functional moblie website out of it as well; would be very tricky to get that right though.
Thanks for doing this AMA. I am starting to explore React Native. What advantages will I get if I use Exponent as opposed to working with React Native directly?
Hi Justine! That's a great question, I'm glad you asked.
I think there are two key differences:
React Native itself gives you the core components that you need to build almost every app: Text, TextInput, View, Image, ScrollView, Switch, Slider, Touchable (the React Native equivalent of a link), ActivityIndicator, and a few more. It also gives you access to some useful APIs, like Geolocation and CameraRoll.
But what happens when you want to add a bar code scanner, map, Google sign in, Facebook sign in, video, fetch a user's contacts, add blur or gradient or OpenGL effects, SVG, push notifications, local notifications or sensors like gyroscope and accelerometer? In each of these cases, you will need to track down a native module that someone has implemented and published to npm, make sure it's actively maintained, install it in your project (not always easy! and you need to do it on both projects), update it each time you update React Native, or possibly just write it on your own in ObjC/Swift and Java.
So, we take care of this for you. Here's a list of some of the APIs that we support on top of React Native currently: https://docs.getexponent.com/versions/v11.0.0/sdk/index.html On Friday we'll publish another update that includes a handful more, and every release this grows. We test the APIs and update them for you, you don't have to think about installation except where an API key is required (eg: Google sign in), and you can expect it to just keep working as you update. If we do make some breaking changes, we'll list them in our release notes and you can update at your convenience.
#2. Makes React Native development even more like web development, for example in terms of publishing and sharing.
With Exponent, as soon as you create a project anybody in the world can open it on their phone and watch your changes live. When you want to deploy it, run
exp publish or hit publish in our development tool called XDE -- this will give you a permanent URL that anybody with the Exponent app can access. If you want to deploy it through the App Store and Play Store, run
exp build:ios and
exp build:android and we'll give you the store-ready binaries, then all you need to do is upload them (we'll be automating this part in the future too!).
It's really incredible how liberating this is -- to be able to share native mobile experiences in the same way that you would share websites. We (and increasingly, other people in the React Native community) use this all the time to share examples on the React Native Community Facebook group (https://www.facebook.com/groups/react.native.community/), for example:
We want to make building and sharing mobile experiences as fun and frictionless as it can be, we see ourselves as philosophically similar to now.sh and Ruby on Rails -- we want to remove the incidental complexity so you can just build cross-platform apps, no hassle.
How difficult is it to eject from Exponent if someone bumps into a wall? In other words, is it possible to paint yourself into a corner with Exponent?
We are actively working on this! See: https://blog.getexponent.com/answered-on-slack-ejecting-from-exponent-154bdca57dc1#.7pv1qlakn
- Exponent is open source, so you can take the code anywhere with you
- But that isn't always super convenient, so we're building a way for you to partially "eject" -- so you can continue to use most of Exponent but still have Xcode / Android Studio projects and add whatever native modules that you like. Our rough timeline for this is January.
What is the future of ex-navigation? Are you planning to add more docs? (the "more docs coming soon" has been there for quite some time now). The RN roadmap says that skevy is co-working on another navigator which should be part of RN core, is there a ETA for that? Thanks!!
Hi Vojtěch! The roadmap is referring to "react-navigation" - what we believe and certainly hope will be the end of navigation related API thrashing in the React Native community. ex-navigation is going to stick around until we’re confident that react-navigation can fully superscede it. We are working on providing a clear migration path from ex-navigation to react-navigation, but understand that not everybody can migrate immediately because neither can we, and we use it on several projects. If for whatever reason ex-navigation users decide that they would like to stick with it, we could hand the project over once react-navigation has surpassed ex-navigation in terms of stability and feature completeness.
What is Exponent's path to profitability?
Hey- good question.
We don't want to charge developers to use Exponent for a couple of reasons.
I think back to when I was 14 and was learning how to program and didn't have any money or a credit card, but was able to make some basic websites with free tools and resources that were available. If we made Exponent something you had to pay for, all kinds of kids and students and hobbyists would miss out.
The second is that I don't think it would work to charge developers to use it. There are enough good free tools out there that I think it would be very hard to charge a seat license for something compelling in this space.
What I think we can do instead is eventually help developers make money, and make a little bit ourselves if we do a good job of that. This is sort of like how YouTube makes money when people who make videos make money but doesn't charge anyone to upload videos or use it.
In the meantime, we have a small team and we keep things pretty lean so that we can stay focused on just building great tools for the moment instead of trying to make money on this just yet.
Are there any plans to expand support to other platforms with Exponent (Windows, macOS, AppleTV, etc.)?
Thanks for doing this AMA session. My question is simple, as a non react, react-native experienced developer I have had trouble finding a nice way to structure my project. I've read we should set apart containers from components but I'm not sure where to place my reducers, action and constants. Do you have an structure you'd recommend me? thanks
I'm of the opinion that this far less important than many people think it is -- it's another form of bike shedding. I'd like to get to the point where we have a recommended directory structure that people can agree on, which allows you to jump between projects easily and know where things are, but given the diversity of tools used in the React and React Native communities at the moment that may be difficult to achieve. Ruby on Rails does a fantastic job of this; I think that's half due to the relative stability of the MVC pattern and the Rails implementation of it, and the other half because the structure is enforced programatically and a principle of the framework (convention over configuration).
My advice would be to not stress about it, start with something simple and evolve it over time.
Thanks for making Exponent! We are planning to use it to build our mobile app. Just curious - How big is the Exponent core team?
Which is the better way/framework to handle routing in react-native among options like navigator,react-native-router-flux,react-native-navigation or something else?
We currently recommend @exponent/ex-navigation, but we are working with @evv at Facebook (who wrote Navigator and NavigationExperimental) to improve on the ex-navigation architecture and create a single "blessed" library for navigation, called react-navigation. See: https://github.com/facebook/react-native/wiki/Roadmap#core-libraries
We'll be providing a migration path from ex-navigation, so there's no harm in using that today.
Which of your react-native contributions are you most proud of?
There's no particular commit I can point to and say that I'm most proud of this thing. I think that a lot of open source work is about grinding away together at a big problem -- fixing bugs here and there, adding a feature that you need, updating some documentation that you saw was missing. There's also a story beyond the commits themselves -- @ide and I have spent countless hours helping people on issues, discussing React Native with people at Facebook and in the community and pushing forward various initiatives to improve it, in particular to make it more powerful without forcing you to drop down to native code.
Are there eventually plans to open up a custom Exponent store for apps built with Exponent, just like Play Store, and App Store?
Nope! We instead give you a way to build binaries to ship on the App and Play Store :) Check it out here: https://docs.getexponent.com/versions/v11.0.0/guides/building-standalone-apps.html
Are there any plans to include SQLite support for more complex data storage?
Since AsyncStorage works quite well and lets you get quite far, we've prioritized other native modules ahead of this.
We're still figuring out whether we should use SQLite or Realm or something different.
One thing that's tricky is that we include multiple versions of the native code within a single binary--so that we can support developing older projects and still move forward with that--and, with Realm in particular, there are some things that would make it technically hard to version.
Do you have a use case in mind that you need this for?
What features in Exponent do you want to add in the future?
@ide is answering this one in https://hashnode.com/ama/with-exponent-ciw1qxry118wl4353o9kxaowl#ciw3sx78k009q5d53agfa3doq :) Expect an answer from him shortly!
Is there a publicly available directory of exponent apps?
We all know your react-native contributions well, and it must take up the majority of your time, but what other technologies, frameworks, etc do you have your eyes on currently?
There are so many!
Some things that I've come across lately that I think are well done are:
- now & next from Zeit (instant deployment for node, universal JS application framework).
- Sentry & Amplitude - really nice error logging and analytics respectiely
- BuddyBuild & Fastlane. You mostly don't need these if you use Exponent, but if you are doing old school native mobile development, these tools can help you a lot. We use Fastlane.
I've been learning about OpenGL recently because @nikki, our resident OpenGL expert, has been working on our WebGL implementation in Exponent: https://docs.getexponent.com/versions/v11.0.0/sdk/gl-view.html (try it here: https://getexponent.com/@community/gl-test or here: https://getexponent.com/@community/breakout). That's not really new technology though!
@perry, who recently started working with us (yay) is a Rust enthusiast. @skevy writes some Go and loves Docker and Kubernetes.
What's the current state of things when it comes to building standalone apps destined for app stores with Exponent?
It works well and lots of people do it :) You probably noticed that our docs (https://docs.getexponent.com/versions/v11.0.0/guides/building-standalone-apps.html) mention that it's in beta -- perhaps we should clarify that it isn't related to the actual build product but the infrastructure itself. For example, we just pushed an update last week to make the error messages fantastic when a build doesn't work for some reason (invalid credentials, too many certs on Apple developer account, etc). You still need to download the ipa and apk files manually from a link that's shown to you on the command line and run
exp build:status to see updates in the build process.
So it's marked beta because the process of building doesn't feel as smooth and streamlined as it will in the future.
Thanks for the answer Mohammed! You might also want to check out my reply: https://hashnode.com/ama/with-exponent-ciw1qxry118wl4353o9kxaowl#ciw1sttqp19924353jqbc1av6
Also, we'll be releasing something in the coming months that will allow you to use most of Exponent and still write ObjC / Swift / Java if you need to! See: https://blog.getexponent.com/answered-on-slack-ejecting-from-exponent-154bdca57dc1#.bmq65vk6e
Are there plans to create app templates, e.g. social, login, firebase, chat, etc?
It's conceivable that we will create some example repos for these, eg: https://github.com/exponentjs/hello-graphql shows you how to set up Exponent with a GraphQL backend, using Apollo Client. We currently have a blank, tabs (with some other features such as push notifications pre-configured) and a game template (https://github.com/exponentjs/game-template).
It would be great for the community to create some of these templates as well, we're still a small team of 8 and building and maintaining a bunch of these could add a lot of overhead.
The development of React Native goes at a very fast pace. How often do you update Exponent to reflect the React Native updates?
We update about every month. Currently we're on React Native 0.36, tomorrow we're submitting an update to the app store with 0.37. So we're usually at most 2 versions behind, although we cherry-pick in any very useful and stable commits in advance. For example, we had native animations on Android for months before they were in React Native core. There are talks about changing the React Native release cadence from bi-weekly to monthly, in which case we may adjust our release cycle to align more closely with it.
What's the future of mobile app development? What are some important patterns that you see and what's your prediction?
I think that over the next few years, almost everyone making mobile apps will be using something like React Native/Exponent.
It's too much trouble to worry about iOS and Android separately. It takes more time and money. So I think we'll see most people who are Swift developers or Android Java developers move over, slowly. And most people who are new to mobile will just start with React Native/Exponent (or something else like it that might come along).
There is some chance that the mobile web gets good enough that that becomes a viable alternative--every time phones get faster, this gets more and more reasonable. But I think using the mobile web for apps is still pretty far away from feeling really good and not moving that fast towards getting there, even though Ionic is a good effort and people at Google and elsewhere have been doing a lot of good work to improve PWAs. The last really lauded web app I saw was Lyft's PWA, which I think falls into this valley of "I'm really impressed; I don't think I could build something that good and slick" but at the same time noticeably not as good as the native mobile apps Lyft already has. Web technologies evolve pretty slowly--for good reasons!--and so I don't expect this to be awesome soon.
I also think the building blocks of mobile aren't all supported really well by the web. If you look at the newer apps that are super popular--Snapchat and Instagram--they are very image and video focused. The building blocks of mobile web and even React Native aren't good enough to do the things you want to do with photos and videos yet, and they'll need to be in order to let people build the things people want to do on their phones in the future.
For games--at least games like the current set of games that fill the app stores--people will probably continue to use Unity for most things which seems to work well and most people seem to like.
There are some pretty gnarly problems with distribution, etc., but there are some interesting things on the horizon to address that, like Facebook Messenger Instant Games. I don't know how that will play out.
Exponent is not the right fit if my project requires custom native modules. Which other use cases might Exponent not be a the right fit for?
Exponent is not the right fit if my project requires custom native modules.
Which ones? :) This will be less of an issue after we release eject: https://blog.getexponent.com/answered-on-slack-ejecting-from-exponent-154bdca57dc1
Which other use cases might Exponent not be a the right fit for?
Any plans for creating module for healthkit?
it's not on our list currently since not too many people have asked for it, but we're not against it.
One thing that's tricky about HealthKit in particular is that it doesn't have an exact analog on Android (though there are some similar things on some Android phones I believe). We try to make all our APIs work the same on both platforms whenever possible, and it's not totally clear what that means here or what cross platform developers would want.
Let us know more about your use case and that will help shape the way we approach HealthKit! Though it probably isn't something we'll work on in the next few months.
Do you guys meet up with Facebook engineers working on React Native? If yes, what sort of things do you discuss?
Yup, they are great people that I feel really honoured to be able to collaborate with and learn from. We are working on a project alongside them right now to make the initial React Native getting started experience easier! The goal is to reduce the TTHW (Time To Hello World), which is currently absurdly high because users need to install Xcode or Android Studio.
We also discuss pull requests that we think need attention or that they want us to comment on, roadmap, problems that we run into building apps with Exponent (or that our users run into), and all sorts of other things. You can see some of the discussions on this Facebook group: https://www.facebook.com/groups/reactnativeoss/ -- we also chat a lot in Messenger.
Forgive me for the triviality of this question, but how did the dev team decide on the name "Exponent"? Were there any other names the team strongly considered?
The first thing we thought we could use it for was an gallery of React Native components. Or, you might say, an "expo" of "components" --> exponent.
We also liked the idea of a non linear increase in developer productivity and thought it sounded cool! It has the right level of nerdiness for a product that is mostly about software developers.
After that, we spent a couple of nights trying to think of a better name but we couldn't come up with anything better so now we're kind of stuck with it.
Would it be unwise to use Exponent now as currently building standalone “shell” apps to publish in the app stores (Play Store and iOS store) has not reached a point of stability?
Hi Hamish! I answered this one here: https://hashnode.com/ama/with-exponent-ciw1qxry118wl4353o9kxaowl#ciw6mxdj5016qjl53p00o5utd
Short answer: you are totally safe using it. The beta flag is with respect to the pipeline itself, and not the end product. If you run into issues we are very fast to solve them. We want to help you build and ship awesome apps.
What is the story of Exponent? How/When/Who decided to build a tool on top of React Native; and how did you take this forward, form the team, raised a fund from YC — tell us the whole part. 😄
A short version that leaves out a lot!
James Ide and I had a vague idea that mobile development was too hard and that someone should make it better, so we started researching the problem a few years ago.
When React Native native came out, we realized it was basically the exact same approach that we'd been taking but was a little further along. Since it was open source, we just decided to use it as the basis for everything else that we wanted to do. We built a very rough MVP of Exponent that we could show people and then we joined up with Brent, Jesse, and Nik. And later Ben, Skevy, and Adam and Jess to make it into something real.
And there is a great community of people who are interested in this stuff now that we've been able to collaborate with. Some of those people help make Exponent better like the team at Facebook who works on React Native (hi girls and guys!) and Janic and Satya and Tienson. And also developers who are making super cool stuff on Exponent. One of my favorite feelings is when I see something nifty that someone made with Exponent and our work feels like a part of making that happen.