Our great sponsors
-
-
SurveyJS
Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.
-
-
-
-
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
NativeBase
Mobile-first, accessible components for React Native & Web to build consistent UI across Android, iOS and Web.
-
-
-
-
appium
Cross-platform automation framework for all kinds of your apps built on top of W3C WebDriver protocol
CSS-based UI libs don't make sense on mobile; your new options include NativeBase, React Native Elements and others). Some web-based UI libs do have RN siblings though - such as React Native Material and React Native Paper (for Material-UI), and tailwind-rn (for Tailwind). This just means new decisions to make, some learning, and new paradigms for how to use the new libs.
React Native uses the Yoga engine under the hood, which allows you to use CSS properties to layout your React Native UI in a way that translates really well. Layout in Yoga is limited to Flexbox and absolute/relative positioning, however; there is no CSS grid and no display attribute. This keeps things simpler and more performant, but if developers are accustomed to using other layout techniques on the web, they’ll need to adjust to this new limitation.
End-to-end testing is completely different on React Native, however. None of the Selenium-based E2E testing tools will work; neither will newer tools like Cypress or Playwright. You may have expected this - these are all DOM-based, and there’s no DOM in React Native. So instead developers will have to learn Detox or Appium.
As a user, you already know that moving around a smartphone app is completely different than on a web app. react-navigation is the most common navigation lib for mobile (runner-up: react-native-navigation). Both are fairly different from react-router, Next.js's router, and so on. Not only do developers have to learn new APIs for this, they’ll have to think differently to plan out complex navigation properly. It’s all very achievable, but I wouldn’t advise assuming that the effort is trivial.
CSS-based UI libs don't make sense on mobile; your new options include NativeBase, React Native Elements and others). Some web-based UI libs do have RN siblings though - such as React Native Material and React Native Paper (for Material-UI), and tailwind-rn (for Tailwind). This just means new decisions to make, some learning, and new paradigms for how to use the new libs.
CSS-based UI libs don't make sense on mobile; your new options include NativeBase, React Native Elements and others). Some web-based UI libs do have RN siblings though - such as React Native Material and React Native Paper (for Material-UI), and tailwind-rn (for Tailwind). This just means new decisions to make, some learning, and new paradigms for how to use the new libs.
State management, orchestrating HTTP requests, synchronizing client and server state: all these things will apply to React Native. The differences will only arise when the device layer comes into play (for example, if you have to store data on the client, window.localStorage doesn’t exist, but AsyncStorage does.)
CSS-based UI libs don't make sense on mobile; your new options include NativeBase, React Native Elements and others). Some web-based UI libs do have RN siblings though - such as React Native Material and React Native Paper (for Material-UI), and tailwind-rn (for Tailwind). This just means new decisions to make, some learning, and new paradigms for how to use the new libs.
At Echobind for example, we typically setup Expo Application Services (EAS) and GitHub Actions for our React Native client projects and internal projects. Builds get triggered by a PR merge to main; GitHub Actions runs JS-related automation (linting, typechecking, unit tests, etc), then hands off control to EAS to do the actual builds and releases.
Some development tools for the web are similar (Chrome debugger, mostly) to those for React Native, but other aspects are very different (working with the metro bundler, using Flipper, AsyncStorage debugging, more). Some techniques developers will use are the same (breakpoints and console logging), but others are different (knowing when to restart the packager vs reinstall the app on device).
Some development tools for the web are similar (Chrome debugger, mostly) to those for React Native, but other aspects are very different (working with the metro bundler, using Flipper, AsyncStorage debugging, more). Some techniques developers will use are the same (breakpoints and console logging), but others are different (knowing when to restart the packager vs reinstall the app on device).
End-to-end testing is completely different on React Native, however. None of the Selenium-based E2E testing tools will work; neither will newer tools like Cypress or Playwright. You may have expected this - these are all DOM-based, and there’s no DOM in React Native. So instead developers will have to learn Detox or Appium.