The original link: learnreact. Design / 2018/02/14 /…

Why you like it: The writing is vivid and easy to understand

Special thanks: Linton Ye, the original author, for her emotional proofreading

Series of blogs: Explain React terminology in colloquial language and doodles

  • The illustration the React
  • The illustration React Native
  • Components, Props, and State
  • Understand Props and State in depth
  • React Native vs. Cordova, PhoneGap, Ionic, etc.

In a previous article, I said React Native is great because it lets us develop applications using a Native UI. React Native offers a much better user experience than the WebView UI. But what does “native” really mean? What is WebView UI? What native UI is better than WebView UI? How does React Native stack up against other mobile frameworks like PhoneGap, Cordova, and Ionic?

Now let’s dig into these questions. Sit tight! (Old driver’s Phrase)

Learning goals

When you’ve finished reading this article, hopefully you’ll be able to come back and easily answer the following questions:

  • What is a native app?
  • What is WebView UI?
  • What are the advantages and disadvantages of a more primitive framework? What about frames with fewer protobiotics?
  • How does React Native compare to Cordova?

What exactly is a “native” app?

To understand what “ncoherence” really means, look at the following:

I’m a huge fan of The Matrix. How about you? In the movie, what we know as reality is actually a simulated world. There are hints that even Zion, the last city of human freedom, is a simulation. I’ve always been fascinated by the idea of multiple layers of simulated reality, one virtual world running as a simulation in another virtual world, which in turn runs in a third world.

This is much like the software architecture of a computer (or mobile phone).

Software is a collection of instructions on how to operate large numbers of transistors and circuits (both collectively referred to as hardware). Raw instructions running directly on hardware are almost incomprehensible to us humans, especially given the complexity and scale of today’s computers.

To make software understandable and operable, computer scientists divide it into layers, all made up of frameworks, each running on top of the other. Of all frameworks, the closer one is to hardware, the more “native” we say it is.

Therefore, the “protobiotics” of an application is a relative concept. Strictly speaking, it’s impossible to say whether an app itself is native or not. Let’s just say it’s more native than another app. For example, you can develop android apps using C++, Java (or Kotlin), or Cordova. Apps written in C++ are the most native, while apps written in Cordova are the least native. Applications written in Java/Kotlin fall somewhere in between.

What are the benefits of more native apps?

Protobiochemistry has more or less its own advantages. Being closer to metal means more freedom, and more simulation makes you more comfortable. (Help: Metal is the matrix? Hardware?)

In general, programs in more native frameworks get more functionality from the hardware and have more freedom to use the hardware. Because of the lower overhead of simulation and translation between different languages, it is generally more efficient to run. But reality is harsh, and its code is often harder to write and understand.

On the other hand, it is often easier to write code for frameworks with fewer primitives. The coding language is also easier to understand and more concise (requiring less code). Its vocabulary is closer to our natural language. It doesn’t require us to know much about what the hardware is made of and how it works behind the scenes. As an added bonus, programs in frameworks with fewer primitives are often more portable and can run on completely different hardware platforms without modification because their vocabulary and underlying concepts don’t contain anything specific to the original hardware. However, all this convenient code often sacrifices some efficiency and freedom.

Mobile framework camp

Before React Native, mobile frameworks generally fell into two camps.

The first is the native camp, such as Java/Kotlin for Android and Objective-C/Swift for IOS. Applications in this camp are fast and can use rich hardware features. The user interface is customized for the target platform (Android or IOS), so it’s smooth and enjoyable to use. But all of these benefits are limited to one platform. Learning different frameworks to develop applications can double or even increase the cost of learning, far more than millions of other Web developers.

The other camp is Cordova/PhoneGap and Ionic. These frameworks allow Web developers to develop applications using HTML, CSS, and JavaScript skills they already have. These apps can run on both Android and IOS platforms (and more). However, they tend to be less fluid and have limited access to hardware than native apps. Most importantly, the user interface of these apps sucks! Because these frameworks use webViews to render the UI, we call them WebView frameworks.

The WebView framework is built on top of the native framework. We can think of the former as running in a simulation world inside the latter. This is why they have the benefits and limitations mentioned above.

Why can’t we combine the best of both and avoid the worst of both? That’s exactly what React Native does.

React Native represents the third camp of mobile frameworks. Its UI layer is more native than the WebView framework, while the rest is in the simulation layer for ease of use.

React Native is much more Native than the WebView UI

Frameworks like Cordova can use Web technologies to develop mobile UIs. How do they do it? They have a Web browser built into each application and are called WebView! Everything you see in the UI, including buttons, menus, and animations, runs in the browser’s web page. From a simulation perspective, the UI of Cordova is a simulation world running in a Web browser, which in turn is another simulation world running in a native framework.

In contrast, React Native’s UI is one level below the WebView framework, running directly within it.

This architecture gives the React Native UI its advantages. React Native uses Native UI components directly, while the WebView framework emulates the Native UI using HTML/CSS. Which do you prefer, true or false?

As a rule of thumb, it’s not hard to tell if an application was developed using the WebView framework. Pass small tests such as scroll acceleration, keyboard manipulation, navigation, and UI fluency. If these actions don’t work as well as they should, the cumulative effect will be a poor user experience.

React Native uses JavaScript to make development easy

React Native, on the other hand, allows us to write applications in JavaScript and develop UIs using syntax similar to HTML and CSS. This certainly lowers the bar for Web designers and developers.

React Native also provides a way to infiltrate the Native framework when needed to implement any Native functionality we want in our applications. It’s a bit like making a phone call in the Matrix.

So the WebView framework is useless?

No, of course not. For example, if you already have a Web application and want to get it to the app store as soon as possible. You are willing to sacrifice the user experience to shorten time to the user.

On the other hand, if you don’t have a lot of interactive stuff in your application, it’s not so bad to put it in a WebView.

However, if the user experience of the application is important, and if the application has a certain level of interactivity, such as accepting user input, dragging and dropping, and sliding pages, then React Native should be considered. Because using the WebView UI to emulate the native UI is the next best thing.

conclusion

Okay, so we’ve covered what “Native” really means, what WebView UI is, and why React Native UI is better, And how React Native compares to WebView frameworks like Cordova/PhoneGap and Ionic.

What do you think? Which framework will you use to develop your next application?