Hey I work on Expo - this is one of the big pain points we're trying to improve. Since Expo is responsible for the native code in these apps we can do the work of keeping all the libraries up to date. You're just responsible for updating the JS code, which normally has minimal breaking changes. Many people have been able to update versions by only changing their dependencies in package.json.

It's not just that. I also need plugins for basic functionality that RN does not provide it out of the box, like playing audio, accessing the file system, reading sqlite databases, etc.

"Linking" these plugins is black box magic, if anything the fails I have absolutely no clue what is going on.

I have a feeling that some of the hairy errors I've been getting have something to do with the plugins not being up to date with the other libraries.

But like I said, I just have no idea what's going on.

If I'm going to learn how Android and iOS code needs to be structured then I prefer to just write native code. At least I will have more control.

Yes a lot of times the issue is that libraries only support certain version of React Native, so for certain sets of libraries there are no versions of React Native compatible with all of them.

Expo has audio (https://docs.expo.io/versions/latest/sdk/audio.html), file system (https://docs.expo.io/versions/latest/sdk/asset.html), and other APIs built in (https://docs.expo.io/versions/latest/sdk/index.html). We don't have sqlite right now but are actively working on it!

The idea is that we provide a lot of nice things out of the box and then if you still need to write native code you can detach (https://docs.expo.io/versions/latest/guides/exponentkit.html) and only write the native code you need while keeping all our other APIs. You can still use `react-native link` after detaching if you want.

Is there a chance that some day your work (expo) will be merged with react native ? Conceptually, I think you are doing what people would expect the rn team to be doing. Namely providing access to the native apis through javascript, except that expo seems to provide much more features. For me, what's holding me back from using expo is the additional complexity of yet another dependency and having to use more tooling (e.g. expo client).

I think right now it makes sense for us to be separate from React Native. Adding all of these libraries adds QA overhead and if Facebook doesn't use them internally it'd be hard for them to keep them up to date. In addition there are some other features we support that definitely don't make sense in core. For example we embed multiple versions of the React Native runtime in our app so that people can choose when they upgrade and we don't break old projects when we push a new version.

I have thousands of images that I need to load dynamically at runtime. I shouldn't be expected to import them all by name.

That's not my idea of a filesystem API.

I've been an early adopter of react native for a long time.. and this was exactly my experience... it's very demoralizing and why i switched to exponent and try as hard as possible to do all I can with just JS (without detaching project form expo).

So far it's been amazing!

I felt that way using React itself (for the web) - it was like writing code upon so many layers I didn't have control to fix eventual hairy bugs anymore. So I didn't even try Native.

Were you using many other libraries? We try to keep React itself pretty simple and recommend you start with that.

I am probably blaming React for more than it's responsible for, but I feel that, in a real world project, it's rather difficult to not fall into that zone where you have webpack, several loaders and complex configurations for different environments, babel with plugins/presets, gulp, redux or something equivalent, strange directory structures because all libraries purposely try to avoid being associated with bad old big frameworks thus giving too much freedom for the programmer to be "creative" when organizing his code, node for SSR (and then taking care for everything to also work on the server), css modules, react wrappers crashing because wrapped libs were originally written with dom manipulation in mind etc. You know the list can go on, the last time I remember my package.json had around 50 direct dependencies, and it is possible to justify every one of them. All that to write magic JS code that imports assets, transforms them, output obscure css classes and a client.js file that eventually print some crazy warnings on line 53777 column 838383937.

I know I am just complaining like a grouchy old man and not really helping understand and solve the problem, but that's what I can do right now. I would say that maybe we are building too modular software and the complexity of glueing everything together is becoming a problem? I feel like the existance of several "react + this + that" boilerplates indicates something.

I can also be wrong and everything is OK and I am problematizing.

I purposely avoid all this mess. The only thing in my "build stack" was TypeScript and a small custom script I wrote myself to assemble things together.

Before I joined that project they were using yoeman and angular and a bunch of other useless crap. I got rid of all of it.

Have you tried Create React App? We made it so that you don’t need to deal with any of that.

https://github.com/facebookincubator/create-react-app

That's helpful, thanks.

I don't remember struggling that much with React itself in terms of untraceable compilation problems.

But then again, I already have a lot of experience with normal web development, so I already know what's under the cover, more or less.

Whereas with mobile, I have none, and I felt that RN was supposed to let me do mobile dev despite not knowing what goes on under the covers.