19th February 2018, 7:00 pm
This AMA is over!Thank the host
Hi guys! Thank you so much for this AMA. I am a huge fan ❤️. Here are a few questions that I have:
Where is Expo headed? How will it monetise the product considering it is free and open source? 💸
What does it take to be a part of the Expo team? 😄
Do you plan to implement an end to end solution where Expo provides a pipeline to the app stores directly? I am talking in the terms of a Continuous Delivery platform where my build will directly be pushed on the App Stores once it is ready. 🤔
Right now anything I build in Expo has a file size of about 26 MB. I read on your website that "this is because Expo includes a bunch of APIs regardless of whether or not you are using them". Is this something which can be solved someday? 🗄
What is your take on React Navigation Library? Even though it is the one recommended by Facebook, certain GitHub threads for it are simply rants. I also see @brentvatne actively contributing to it. Do you see it being the perfect RN Navigation solution in the future? 🧐
What does Expo team do for fun fun? 🤪
A few months back, Expo experienced a down time where users could not login. What exactly happened? How did you all deal with it? 😯
Redux or MobX? 🤓
Thanks for making Expo. Cheers. 🍻
A lot of questions here! I'll try to answer some of them.
- Where is Expo headed? How it will monetize when it is free and open source?
We're trying to make Expo into something powerful enough that almost every new mobile app project starts with Expo. Each month we add a bunch of improvements and features that march us towards this goal.
In general, Expo is free and open source because that's what we all would want ourselves out of a product like this, and we think it would be pretty hard to charge money and not be open source in a world where the standard for developer tools is free (VSCode, XCode, Android Studio, vim, emacs, React, React Native, etc. are all free and open source).
We think if we can help developers make money, we'll be able to make some money as well ourselves. Sort of like YouTube or Twitch or Patreon does.
I answered this question in a blog post here a while back. https://blog.expo.io/exponent-is-free-as-in-and-as-in-1d6d948a60dc
- What does it take to be a part of the Expo team? 😄
This is a complicated question but here are some of the things I look for: (1) Good taste. This means different things depending on role, but it means making good choices about how to design APIs and what technologies to choose, and sometimes what to call things or how to make them look visually.
(2) High APM ( http://liquipedia.net/starcraft2/APM ). We have a toooonnnn of things to do to make Expo really good, and we're going to have a small-to-medium-sized team for a while, and so we need people who do lots of stuff quickly.
(3) Low overhead. I really like working with people who are self sufficient and don't require a lot of hand holding or guidance or attention. Or at least don't cause problems on the team or have many conflicts with other people.
(4) People that want to work on this problem. Everything falls into place when we follow our north star of supporting the people who want to create awesome stuff for phones. And weathering any ups and downs is a lot easier for true believers in the cause.
- Do you plan to implement an end to end solution where Expo provides a pipeline to the app stores directly? I am talking in the terms of a Continuous Delivery platform where my build will directly be pushed on the App Stores once it is ready. 🤔
We want to make this process as easy as possible and there's still more we can do there, for sure. One thing in particular that I really want is the ability to take a Snack and with a few clicks turn it into an App Store app. This will take a little while to build though.
- Right now anything I build in Expo has a file size of about 26 MB. I read on your website that "this is because Expo includes a bunch of APIs regardless of whether or not you are using them". Is this something which can be solved someday? 🗄
This is something we have a plan to work on soon. Our current thinking is that we are going to implement something we call "optional modules" where you can strip out any of the modules you don't need in your app store app. We can do an analysis of your code to figure out which ones can go, (though you may want to leave common ones you aren't using in, in case you want to add that functionality over the air later).
Until we complete that project, you can detach and then strip out the native modules you don't want yourself. Though many users, at least in the United States, don't find 26MB to be particularly big for an app!
Brent can answer this better than I can. I strongly believe that there needs to be an excellent and intuitive JS navigation solution for RN, and right now, React Navigation is the closest thing to that, but as you've pointed it, it certainly needs some more love and work, which is why Brent has recently started working on it a lot.
What does the Expo team do for fun? Lots of different things :)
We've done stuff like volunteering and karaoke and skiing and drinking together.
Ben and Jesse are in a band called The Shut Up which is super cool and plays live power hours. Quin eats rats. Edgar rides motorcycles (please be safe. Pretty please.). Jim just makes stuff all the time. Some people play video games. Switch is kind of popular and Jason is a high level Rocket League player. Adam Perry is cooking his way through every country in the world, one by one. One meal each. I think he's on Andorra right now. He also wears Rust themed clothing and attends Rust meetups.
- A few months back, Expo experienced a down time where users could not login. What exactly happened? How did you all deal with it? 😯
We were using a 3rd party auth provider and it lost a bunch of data and had an extended outage. (Search through the Expo twitter archives if you really care which one.) The way we had things setup, this left us pretty helpless. After that, we decided we couldn't rely on a third party service for something that's that critical and also just not that complicated. Quin is working on that.
We're really sorry we let that happen. I hope it didn't break your flow.
- Redux or MobX? 🤓
I like that you can use either one. Most people on the Expo team use Redux. I think its pretty nice and elegant but also could probably evolve a little further than it has and become a little easier and more intuitive.
I think it would be very healthy for RN if something came along that took care of state like Redux but also with persistence and reloading data from the server, etc. (Credit to Brent for telling me this idea last night.) A full data layer solution that would feel sort of like doing data in Rails does on the web. That's tricky because once you start doing that, you start to get opinionated about what happens on the server which some people don't want, but I think it would be good for something like this to exist.
What is your take on React Navigation Library? Even though it is the one recommended by Facebook, certain GitHub threads for it are simply rants.
The project has suffered over the last year from a lack of ownership. Some unfortunate circumstances led to the two creators of the project not working on it anymore, and it was being kept afloat by some generous volunteers but they didn't have a lot of time to dedicate to it.
One of the creators, Eric Vicenti, has since rejoined the project and his time working on it is being sponsored by Expo. I've also joined the project and I'm working on it close to full-time now.
I also see @brentvatne actively contributing to it. Do you see it being the perfect RN Navigation solution in the future? 🧐
My take on it is this: there is no perfect solution.
Many people will want to use the native APIs provided by the platform, and they will be willing to have to dig into ObjC and Java when they need to for further customization. React Native Navigation is a fantastic solution for these people, because most of it lives in native code and it leverages the native navigation APIs.
Many people will want to have the navigation APIs written from the ground up in tools that they understand, and in a way that is completely reusable across platforms. React Navigation only go into native when we find the React Native primitives available us to be lacking. For example, we worked with Krzysztof Magiera a couple of years ago on
There is room for multiple APIs in this space. Read about the pitch & anti-pitch for React Navigation here: https://reactnavigation.org/docs/pitch.html
Our north star is to serve the people who want to make awesome stuff for phones and the people who use that stuff. We've been working with React Native since that technology has done the most to push mobile development forward in a significant way but we're always looking around at other things like NativeScript, Flutter, Kotlin, etc., etc.
We don't consider Expo to be a React Native company -- instead, we think of ourselves as a mobile development ecosystem. So, we might end up working on any of those things, though we don't have any concrete plans right now.
The best way to get started is with React Native Express (http://reactnativeexpress.com/)! We covered most of the material from that and more in our workshop at React Europe last year, and it's all available on YouTube: https://www.youtube.com/watch?v=rUi2rkxKBbI&list=PLCC436JpVnK2RFms3NG9ubPToWCNbMLbT
Another good resource is the "Full Stack React Native" book (https://www.fullstackreact.com/react-native/) because it guides you through several small apps. There's no substitute for this kind of practice!
When you're comfortable with the basics, be sure to learn how to use the Animated API (https://facebook.github.io/react-native/docs/animations.html#animated-api). For gestures, dig in to react-native-gesture-handler (https://github.com/kmagiera/react-native-gest ure-handler).
I hope this helps!
Three things I like
- Development speed is faster than any other way to build mobile apps, and this is so important when building new stuff.
- Flexbox was a good choice for layout I think. It's pretty intuitive compared to pre-Flexbox CSS.
- Many people are already familiar with React, and so RN is very accessible for lots of people.
Three things I don't like
- Takes a long time to build the initial package
- Wish starting up JS VM and loading initial JS was faster
- Wish debugging were better. Doing debugging by running your JS off-device inside your web browser is just kind of wacky.
We're considering this. I am personally (not speaking for the team) not convinced that we need it, and I do not like having to integrate native APIs that are specific to a particular vendor (when we can avoid it). That said, there is clearly a lot of demand for Firebase (as per https://expo.canny.io/feature-requests). You can use the JS SDK for the database, authentication, and very shortly for storage (this will be available in March).
I'm hoping we can put it into the SDK 27 release.
This is a super popular request. We only haven't done it so far because (a) you can do a lot of the things people want to do with Firebase with just JS, esp. now that blob support will be available soon, and (b) there is some complexity with integrating it into Expo, and (c) push notifications just won't work with the Expo model since we can't give out the APNS tokens for the Expo client app to everyone, for example.
But I think it still makes sense to do it so we'll do it soon (unless there are unforeseen complications which there often are with software!! And no promises on date, etc. Just telling you what I'm hoping for.)
As part of the React Native community, we worked with other community members (Philipp from Silk Labs, Satya from Callstack, and Janic from App & Flow) to land preliminary support for Blob uploads in React Native 0.54, which is currently on npm as a release candidate. Support for Blob uploads is by far the most popular Firebase-related request and will let developers upload images to Firebase. We expect Blob uploads to be part of SDK 27.
There's a lot of discussion around this here: https://expo.canny.io/feature-requests/p/native-plugins
It's not clear to me what this would look like in practice. We have been considering making it possible to inject plugins in the build step (
exp build:ios/android), but not the Expo client.
We wrote up a page in our docs address this: https://docs.expo.io/versions/latest/introduction/why-not-expo.html
Here are the high level bullet points:
- Expo apps don’t support background code execution
- not all iOS and Android APIs are available in Expo (in particular, payments and bluetooth and real time video streaming are still in the works)
- If you need to keep your app size extremely lean, Expo may not be the best choice
- If you know that you want to use a particular push notification service
There are also reasons why you may not want to use React Native. For example, if you are doing some kind of real time fluid simulation, or having the fastest possible cold boot time is critically important.
We have plans to address all of the things listed above but it will take us a little bit of time.
I would like to tease out one of Kashish's (many) questions because I think it deserves to be addressed on it's own.
> Right now anything I build in Expo has a file size of about 26 MB. I read on your website that "this is because Expo includes a bunch of APIs regardless of whether or not you are using them". Is this something which can be solved someday?
Yes, this can absolutely be solved. We've been working on infrastructure and refactoring necessary to support "optional modules" -- this would allow you to selectively opt in and out of APIs to include in your standalone app. We'd also let you select which versions of the Expo SDK to include -- usually this would just be the one version that you're using. More info on versions in this reply: https://hashnode.com/ama/with-expo-team-cjdqxyifm04hwt3wt80z47mf7#cjdulxcq00579z0wufh2exvby
We don't have any really formal relationship but we are friends with a lot of the people who work on React and React Native there. They are just down the road so we sometimes get together and talk about things. We sometimes ask them for help when we upstream a PR and need to get that into RN (thanks to Hector in particular!!!) We've collaborated on things in the past like create-react-native-app and yarn and I think we'll collaborate a lot more going forward.
Jim Lee, who is the person behind the new design -- along with design help from Bakken & Baeck and illustrations from Timo Kuilder, had this to say:
Hey great question!
Out of the many goals for our design, two stand out.
Expo has got to be a place where professionals feel like they can publish their projects and attract people who would have never crossed paths with their projects before. We think it is really cool when any creator is able to see engagement from people outside of their network, and we definitely want way more of this.
Second, Expo wouldn't be a great platform if people couldn't come to learn and get started with our tools. So we worked to made it easy to search our documentation, learn how to get started, and soon we'll make it even easier to see example code.
Over time our design will evolve with our users, and I think today we are really well positioned for that!
How are features picked?
We pay close attention to the feature requests: https://expo.canny.io/feature-requests. In addition to that, we conduct user interviews frequently, speak to businesses who may be interested in using it or who are using it, participate in hackathons, and we build apps with Expo ourselves to get a feel for what we think it needs.
How do you discuss problems as a team?
This is a tough question to answer! Not sure I can give a concise answer to this, sorry :(
What other services do you use?
- Google Cloud
- Dropbox Paper
- Circle CI
- GitHub (of course)
- DoorDash :P
- Plenty of others..
Our way of planning stuff to do is probably close to what you would guess.
We spend some time after each SDK release planning what we want to go into the next one.
We use a variety of inputs into this, including votes from the feature request board at https://expo.canny.io/feature-requests and also just stuff we want ourselves or that is new. And from doing proactive interviews with users of Expo. We especially try to listen to people who are doing really cool stuff with Expo or building really big apps with it. Jason and I and sometimes other people have also been spending time talking to people who don't use Expo to find out what they would need to make Expo make sense for them.
From there, Ben who is the team's PM and Jesse who is the team's engineering manager lead a process to take all this stuff we want to do, assess how hard or complicated it all is, and then synthesize a coherent vision for the next SDK that we then work towards.
Sometimes random things happen also, like Nikki going on vacation to India and coming back having built EXGL on a lark.
If you want to get stuff onto the Expo roadmap, post or vote on here https://expo.canny.io/feature-requests or if you have a longer rationale for something that doesn't fit there, post in the forums at https://forums.expo.io/
Hi José! Yes we are planning on that. See my reply to Chris in https://hashnode.com/ama/with-expo-team-cjdqxyifm04hwt3wt80z47mf7#cjdum1yct02ism3wt65416ysk
We've been working on infrastructure and refactoring necessary to support "optional modules" -- this would allow you to selectively opt in and out of APIs to include in your standalone app. We'd also let you select which versions of the Expo SDK to include -- usually this would just be the one version that you're using.
This is going to be a boring answer but the truth is there is no one particular part that is / has been the most difficult. One difficult problem that comes to mind is handling versioning our native code elegantly. It's something that most people using Expo just take for granted, but there was a long period of time where the Expo client wasn't capable of doing this. The Expo client needs to support multiple versions of React Native in a single binary. If you built an app 6 months ago and want to use the Expo client to open it today, 6 releases later (we do monthly releases), it will still work. We include I believe 7 versions currently. Each of the APIs that Expo includes also needs to be versioned, and their dependencies.
They vary widely. The average person shows up around 10AM though some before that and some after that. There are usually some people working from home--either from SF or out of town. People are generally pretty nice and friendly and just talk about Expo stuff all the time, with occasional forays into existentialism, cryptocurrency stuff, video games, current events, and other stuff like that.
On Thursdays, we have an all hands at 2PM. Other than that, we don't have too many structured meetings other than 1-1s.
We go out to lunch in downtown Palo Alto almost every day, unless we are in a crunch time, in which case we'll usually order in.
Here's a photo of our meeting room: https://www.instagram.com/p/BcI_DGOFLyZ/ And here's people hanging out at the old place we used to work: https://twitter.com/expo_io/status/842964876184055808
Hi guys! I'm huge fan of Expo!!
First question is:
I would like to ask you, if we need to Detaching to ExpoKit for some npm modules why we need expo? Actually i don't want to touch native iOS or Android layer. But sometimes it is hard to find module for expo compatible.
Of course it is hard to cover all issues but some are really important. For example I'm using firebase features like realtime db etc. But i also want to use Firebase analytic (instead of google analytic), app indexing, admob etc. I believe these kind of features have to be in Expo. What you think about supporting firebase features?
re: not always being able to find an Expo module to do what you want to do. We're trying to solve this issue by squeezing it from both sides. (a) by continuing to support "detach" and make it better so you can write native code or
react-native link native code whenever you need to. and (b) making it possible to do almost anything you want to do with just JS. For example, by continually working on improving our multimedia support so you don't need to install special modules to deal with sound or video.
For Firebase in particular, we're looking at a bunch of different options. Here is a starter snack for using the Firebase Realtime database: https://snack.expo.io/HJ1Wjg95Z
We also are looking at adding react-native-firebase in to Expo directly but there are some reasons that might not work well.
1.) When you detach and use ExpoKit, you retain most of the Expo SDK (like Expo Graphics, Audio, and Camera) that doesn't depend on Expo services. So if you use any of these APIs after detaching, you'd still want to use ExpoKit.
You also can use Native Directory (https://native.directory) to find libraries that are compatible with Expo. Library authors indicate which platforms they support, making it easier for developers to filter by libraries that support Expo.
2.) We would like to support several Firebase features if we can do so in a useful and sustainable way that keeps Expo APIs stable over time. Some features like App Indexing are also more challenging to implement because they are only possible in standalone apps, in contrast with the Expo client. (Since you mentioned it, you may find Expo's support for Admob useful: https://docs.expo.io/versions/latest/sdk/admob.html.)
Yes this is possible with Expo! The native builds run on our servers, so when you run
exp build:ios it builds your JS bundle and asset manifest, uploads them both to CloudFront, then kicks off a build job on MacStadium. When it's done, you can download the binary and upload it to iTunes (it may be possible to upload without a Mac, I am not entirely sure). This is only needed when you're ready to ship to the App Store, and before that the workflow is no different between a Mac and Windows when using Expo. Read more about this in our docs: https://docs.expo.io/versions/latest/distribution/index.html
Using React Native without Expo, you can't really build for iOS without some likely painstaking workarounds involving provisioning your own mac cloud instance.
In terms of 'difficulty' -- it's hard to quantize since that's relative, but I would say that in the grand scheme of things the build system isn't the most difficult part, if only less defined and less documented. Actually writing the binding code is the most important bit, and is about linear in the complexity of API you want to bind. In the cpp/ directory we have some other utilities we've used in the binding.
In terms of 'recommendation' -- that's a hard judgement to make in the abstract, but concretely given a particular use case, yes it could make sense, if that is the main and only way to achieve the result you want. I would say try using the 'CxxModule' system as provided by React Native (you'll have to watch for including the headers and linking with React Native's code properly) -- we didn't do this, so have no examples to point to there. The way we did it (direct JSC C bindings) means you know exactly what's going on under the hood, which could also be what you want.
React Native Gesture Handler (included with Expo) is one of my favorite because it meaningfully advances the way we can compose gestures, and does so in an incremental way that lets developers migrate pieces of their app to use the new gesture system. Advancing the state of the art in a good way and heavily investing in migration paths are two great things about this library.
I also like Redux, though it's not specific to RN nor React. Redux's approach of using reducers as a chokepoint to atomically recompute state lends itself to correctness and consistency. And I find it relates to several introductory concepts covered in "Structure and Interpretation of Computer Programs" (https://mitpress.mit.edu/sicp/full-text/book/book.html), which is a great book for learning foundational computer science.
- react-native-gesture-handler - great gestures have never been so easy.
- react-native-vector-icons - of course
- react-native-animatable - super simple to drop in animations
- react-native-paper - still early for this but I'm excited for it!
- react-native-camera - we re-built this for Expo and people liked it so they pulled the native code out of Expo and into this library
- react-native-tab-view - excellent
- gl-react - it's good
plenty more that I haven't listed here!
We're still working on this but progress is currently stalled because Apple will sometimes reject apps if they have payments code in them but they don't collect payments, so we need to add the ability to include optional modules only sometimes before we launch this.
In the meantime, you'll just have to detach and do it yourself, unfortunately. I would look at Naoufal's payments library for this right now. https://github.com/naoufal/react-native-payments
Hello! I’m fan of Expo! Been following you since you started!
What’s the story behind Snack? I was briefly a contibutor of React Native Playground and I felt that Joshua (original creator, I think) had built something really awesome and I wanted to contribute by redesigning the layout which turned out to be really cool (at least I want to think so xD).
Thanks Johan! :)
Snack is a big group effort from lots of people and drawing inspiration from a lot of stuff that came before!
I made the original Snack prototype. It was inspired partially by RNPlay for sure (one of the best projects in the early days of RN!), but also JSFiddle and Codepen and every other interactive environment that I'd seen before like Smalltalk etc. I also just thought that the packager was too slow and fragile and I wanted to cut it out of the equation. That seemed easier than running a cloud version of the packager.
The prototype I made barely worked but you could see how fast it was to update, and that was exciting, so Jesse took it and made it into a real thing along with Satya.
More recently, TC along with Satya and now Nikki have picked up the mantle, adding a lot more reliability and the ability to include arbitrary npm packages. And Jimmy the intern made the thing where you can download a Snack into an XDE/exp project.
Watch out for more improvements coming along. I also am excited about taking the best parts of Snack and getting them into the command line environment and vice versa. Will take some cleverness and time to do this well though.
The first thing your question makes me think of is this open letter Steve Jobs wrote all the way back in 2010 titled "Thoughts on Flash". Mostly he was just s*tting on Flash for being slow and buggy and not keeping up with the times but there is one paragraph that's pretty interesting in it.
We know from painful experience that letting a third party layer of software come between the platform and the developer ultimately results in sub-standard apps and hinders the enhancement and progress of the platform. If developers grow dependent on third party development libraries and tools, they can only take advantage of platform enhancements if and when the third party chooses to adopt the new features. We cannot be at the mercy of a third party deciding if and when they will make our enhancements available to our developers.
We sort of love proving that way of thinking wrong when we can. For example, I thought it was awesome that we had ARKit support in Expo in the App Store within a week of iOS 11 (and ARKit) being released. I'd like to be able to have that near-instant turnaround with basically all new OS features, and we're thinking of ways to systematically stay on the cutting edge.
The world has become so connected and continuously updated that I think it will probably be possible to mostly achieve this over the medium term.
Also, I'm personally really excited when cool new stuff comes out for phones since that just means we can bridge it into Expo and let people make great stuff with those peripherals or features. We love doing this kind of work.
Are there any plans to support bluetooth and BLE via some Expo apis?
We do plan on supporting this! It's a very popular feature request: https://expo.canny.io/feature-requests/p/bluetooth-api
No timeline for it yet but we're making our way towards it.
Any plans for Expo or some of your apis eventually becoming separate libraries so we can only use the parts we need
Some users have started to do this , eg: react-native-camera is the Camera component extracted from the Expo codebase.
As for only using the parts you need, we plan on making it possible to opt-in to only the APIs that you need in the build step, to help reduce the size of the binary.
(even if at a extra cost per library)?
No plans for charging for that.
Bluetooth is near the top of our list but its complicated for a few reasons so that's why it's not done yet. (a) The Bluetooth stacks on iOS and Android are pretty different so its not easy or obvious how to unify those, and (a2) the native APIs are pretty imperative and stateful and we'll probably need to map that onto something declarative so it can work over an async bridge to work with RN (b) The use cases for Bluetooth vary widely--from BLE stuff to paired, etc., etc., (c) Bluetooth usage will typically involve stuff happening in the background, and we're still putting together background task support (though it should be available soon!)
re: Making APIs available outside of Expo. We might do this! It would definitely be nice in some ways but doing that might hamper our ability to do other things well. It's something we talk about a lot, but in the context of many other considerations and plans for the future architecture of Expo.
What would EXPO be if Facebook reacted to ends the evolution of the RN as it did with Parse?
We have enough people who know React Native's internals pretty well that we could continue the project. This would mostly be really bad for React Native and mobile development if it happened, but we would just keep working on it. We'd probably also look more closely at competing technologies if this happened. I don't think this will happen soon. A bunch of stuff internally at Facebook is built with RN.
What is your opinion about the acceptance of the EXPO by large development companies in RN?
In general, new technologies and services are easier choices for smaller and newer companies and teams. And this is true of Expo too. Companies where they have a dedicated iOS team and a dedicated Android team aren't likely to adopt RN or Expo, except for new tools or side projects.
But as Expo has started to become the standard way to do greenfield RN apps, we've seen more big companies picking it up. There are a few things in development that I'm pretty excited about.
One good thing about being mostly client software is that there aren't too many concerns about scaling, the way there might be with a backend-as-a-service or something like that. This makes it a little easier for companies already at scale to choose to use Expo without worry.
1.) React Native is different from Parse in that RN is a library, while Parse was a service. All Expo apps made with React Native would continue to work if Facebook were to stop contributing to the project, and several other developers (including the Expo team) would likely continue to contribute to React Native.
In addition, Expo uses React Native as one of its libraries, but Expo is much more than React Native. We use React Native since we believe it is well-suited to building applications and we want to help grow the ecosystem and hope it continues to grow healthily. But React Native is just one piece of Expo and while we hope React Native continues to succeed, we'd work on making Expo work if React Native's momentum were to change.
2.) We definitely want to support larger companies that need to build mobile applications. One way I think about great technologies is that they're easy to learn and also have high ceilings that accommodate use cases we can't anticipate. The latter is especially important for professionals who are looking to build world-class software and accomplish their business goals.
👋 Hi team!
1) What can the community do to help you in the great endeavor that is Expo? (besides using it)
2) If there's one feature you could wish for and have it "magically" appear on the RN and/or expo codebase what would that be?
3) Have you tried out Flutter and if so what are your takeaways.
4) Are you working on ReasonML bindings for expo?
//Stay awesome! ❤️
(1) Some ideas: (a) make great examples of stuff using Expo that people like and make them open source so people can learn how to make them. (b) Make libraries that are compatible with expo that people can npm install, like react-native-deck-swiper (c) make videos showing how to build stuff with React Native and Expo or give talks about it at meetups, etc. (d) Submit PRs to add stuff or fix stuff
(2) A way to have a debugger running in the JS VM on the actual device and a way to connect to that from a remote server, so you could write a great debugging tool that you could have in a web browser in your computer.
(3) We are looking at it. Aside from using Dart instead of JS and a home rolled React-like component system written in Dart instead of React, the really important difference between Flutter and RN is that Flutter renders straight to GL rather than trying to leverage native OS level components or a webview or anything. There are some really nice properties to this and it might be a better approach overall, but it requires incredible fidelity to match the user's expectations. Google might be able to pull it off but even if they do, keeping up with the platforms will be tricky. I think there is about a ~30% chance that that approach turns out to be better. We'll see.
(4) Someone might be! Brent cares a lot about Reason!
The all-in-one cloud platform developers & their teams love. Get started free for 60 days.Learn more
6 Reasons to join Hashnode, now!
- Friendly and inclusive
- Ask questions, Read blogs and share news
- Voice your opinion without being judged
- Question everything and quench your curiosity
- Earn appreciations and be the coolest nerd
- Hang out with smart developers from across the world