Architecture, plans and a roadmap - please

[pkieltyka]

Hello,

I'd like to start by saying RN is ground breaking, amazing and I appreciate the efforts of all authors and the community.

My team has been using React Native for the last 8 months, and my team has done some incredible work with it (not yet public) - including many open components and a scene router. I believe in the premise of RN, to have a native runtime instructed by logic coming from a webview via reactjs rendering. However, I am very concerned that the framework (RN) will fail if its not approached properly.

Specifically, I find it strange that RN's UI runtime is just trying to wrap native components of the respective SDKs, instead of rebuilding both sets of components from the ground up, using primitives like NSView on iOS (and whatever view primitive on Android). Writing RN components from the fundamentals is the only way I can see to ensure the UI runtimes will behave the same across platforms - just like the browser as it's philosophy comes.

I don't ever see a world that you can create a consistent interface and behavior by wrapping two different, but seemingly similar, libraries like iOS and Android UI kits. You'll just be playing a game of whack-a-mole trying to smooth the interfaces and behaviors between platforms. In my opinion, this approach is doomed from the onset if this continues.

I can see why the beginnings were this way, starting with iOS - but with Android in the picture and other future platforms showing interest (like Desktop) this will not work and it will just get worse. It's already not practical as I can see the massive breakage through our efforts to get our RN app that has gone through tons of refactorings and iterations during its development, has been a struggle to "port" to Android. There should be no "port"ing. It should be the same runtime, powered by a behind-the-scenes Webview.

Id love for someone to enlighten me though and give me faith in the direction of the project. I welcome any thoughts about how you guys see the future now that you've had a chance to write the runtime on multiple platforms. My suggestion: write components from ground up for both iOS and Android, at least the fundamentals like drawing, layout, animation, and inputs -- keep refactoring and iterating RN aggressively until its right.

[facebook-github-bot]

Hey pkieltyka, thanks for reporting this issue!

React Native, as you've probably heard, is getting really popular and truth is we're getting a bit overwhelmed by the activity surrounding it. There are just too many issues for us to manage properly.

• If you don't know how to do something or not sure whether some behavior is expected or a bug, please ask on StackOverflow with the tag react-native or for more real time interactions, ask on Discord in the #react-native channel.
• If this is a feature request or a bug that you would like to be fixed, please report it on Product Pains. It has a ranking feature that lets us focus on the most important issues the community is experiencing.
• We welcome clear issues and PRs that are ready for in-depth discussion. Please provide screenshots where appropriate and always mention the version of React Native you're using. Thank you for your contributions!

[satya164]

IMO the platform specific components is one of the strengths of React Native. Wrapping platform specific components are the only way to ensure that UI elements look familiar to a specific platform. iOS and Android apps should not exactly look the same. Building both sets of components with the same style across different platforms is only going to make the user experience worse.

For the cases when the APIs are very similar, RN has cross platform components/modules which wraps both of them, for example the <Switch /> component, which wraps both <SwitchIOS /> and <SwitchAndroid />, or say the NetInfo module.

Effort is being put into converging components and modules which have very similar APIs, and help is always welcome :)

our RN app that has gone through tons of refactorings and iterations during its development, has been a struggle to "port" to Android.

I agree that porting apps between platforms shouldn't be hard. I'd like to hear about what were the problems you had with porting and what changed did you have to do (may be blog post can help lots of other people too), also if you've any suggestions on how to make it better. These info could be huge help in optimizing the workflow.

There should be no "port"ing. It should be the same runtime, powered by a behind-the-scenes Webview.

I disagree with that. React Native's mantra is "Learn once, write anywhere", so the main idea is, you shouldn't have to learn entirely new technologies and conventions to write an app for a different platform. The code reuse comes as a bonus. While it would certainly be great to be able to share more code, we also need to accomodate platform conventions and need to write different code for different platforms at some places.

BTW React Native doesn't use a WebView. The UI is powered by Native components and the JavaScript runs on JavaScriptCore. Using a WebView will not make it any different from Phonegap.

All the opinions above are only mine doesn't represent views of the RN team.

[satya164]

BTW there are many fundamental things written in JS from the groundup, like Animated, ListView etc. But the performance isn't very great since these run on the JavaScript thread.

[vjeux]

Thanks for this question, this is something that we had many heated debate on over the years.

The goal is to have all the pieces to be able to implement any control you want using JavaScript that behave the same way between iOS and Android.

Long term, we'll probably end up implementing a core set of components in pure React Native that works on both platform as you mentioned. We actually already started with Navigator and TabBar (internally for now).

The first thing I want to mention is that reimplementing core components seems easy but in practice is very hard. There are so many edge cases and subtle behaviors that are not documented and hard to replicate.

Those core components also make the platform identity. If you try to copy them exactly, then you are playing catchup on every release and will never be the same. If you are not, then the users will notice. It may not be a bad thing, Google is using Material design on both their iOS and Android apps for example, but they will notice. Should we make a React Native design guidelines? Maybe, but that's a larger effort.

The most important thing for the success of the project is that you shouldn't be blocked on the core team to build your app. If we don't have the bandwidth to implement component X that you need, then you wouldn't be able to use React Native and stop using it. There's a looong list of components/api that are available on the native platforms.

So we invested a lot of time and efforts into making bridging native components and API possible and as easy as one can make this hard problem.

We also worked very hard such that the core apis are either subset or can be polyfilled on the web. This way you can reasonably have one codebase and target iOS, Android and Web.

The best way to realize the end vision that you suggest is to make React Native successful. Then we'll have the resources to build it iteratively.

[vjeux]

Also one thing I forgot to say, we are working on unifying our APIs on iOS and Android as much as possible. What you see for Android is really us trying to make it work (which should always be step 1!), now we need to make it good.

The general vision is that things that are the same on both platforms should have the same API.

[pkieltyka]

@vjeux thank you for the quick reply and offering the story of RN's thinking.

It all makes sense that these are the beginnings, I agree that implementing the whole set of components is a huge under-taking - first on iOS and then again ion Android.

I wonder if there is a balance of rebuilding certain core components in their respective native lands (ObjC/Swift and Java) built for the RN runtime, starting with anything layout related. For example, flexbox should behave exactly the same on any platform. But I still think you'd still wrap native components like the Maps or Camera components.

As for keeping up with the respective SDKs for UI components -- personally, I don't think that should be a primary goal since technically any component can be wrapped and utilized - as well, its not the most important thing to what attracts developers to RN in my opinion.

Perhaps RN will be a semi-cross-platform UI, with the same programming paradigm, and that is still great. The gap was my expectations that the same components would run across platform, but perhaps thats not necessary today or ever. If it is.. then I think trying to create too many abstractions between native UI SDKs until they behave the same will be equally challenging as writing the base from scratch in their native platforms.

Another approach could be.. replicate iOS layout/components on android.. use iOS as the base, then you just have to build that side.. or pick / choose if there are parts of iOS that fit in the RN-way.

[vjeux]

I really want React Native to support all of the above. Then the developer is going to be able to pick and chose which one it wants based on the situation :)

[jaysoo]

@pkieltyka This would be useful for contributors as well. Something like react-future repo is useful to see future goals of reactjs.

Personally, I don't think all platforms need feature parity because apps in Android, iOS, and beyond will probably need different UI/UX to make them feel "native" to their respective users. Meaning that certain components may not make sense in all platforms.

@vjeux Common APIs having same behaviour is great. Does this mean that layout differences between Android and iOS should be filed as bugs? e.g. opacity: 0 and padding having different behaviours on iOS and Android. I think platform differences are okay, as long as developers are aware of them (through docs, or separating APIs). Surprises are bad. :)

[vjeux]

@jaysoo: yeah those are bugs. Opacity: 0 not having the same touch behavior I think has been fixed. We've got a plan for overflow: visible not working on android. I'm not sure i'm aware of any bug concerning padding though.

[jaysoo]

@vjeux This is the one I ran into #3485

[brentvatne]

@jaysoo - we should definitely try to unify as much as possible, remember react native android has only been out for 109 days so there is tons of work to be done :)

[brentvatne]

Product roadmap takes time just like feature development and bug fixes, so let's track the need for this through ProductPains: https://productpains.com/post/react-native/product-roadmap/ - if there is enough pain around this then I'm sure time can be made. But let's make sure we prioritize it like any other task that takes time and effort.