React Native Changed the world? Or nothing.

RN is a awesome technology, and Facebook's very thinking team has created a new technology that has changed the native development community. But RN itself is doubtful, RN is to solve what problems exist? What problems did RN solve after the birth of a year? Through analyzing the idea of Rn, this paper tries to understand the dynamic scheme through technology.

RN (React Native) is the mobile development framework launched by Facebook, using JavaScript as the primary language for development, logic and style processing done by JavaScript, rendering using Native rendering, Supports Android and iOS two platforms. For native developers, RN can be configured to go live on-line with immediate effect. For web developers, they can use their familiar technical system to do native development.

A year ago, when RN was launched, the amazing mobile development industry, everyone exclaimed that native development could do the same-cross-platform, dynamic publishing, concise JSX syntax, a variety of development tools and debugging tools. I was also a fervent advocate of Rn, and many of the ideas at that time seemed to have led a generation of innovation. Now, after doing more than a year of native dynamic work, found that the problem behind RN is heavy.

1 does RN exist to solve any problems? View 1 solving cross-platform issues

"React Native enables you to build world-class application experiences on Native platforms using a consistent developer ex Perience based on JavaScript and React. The focus of React Native is on developer efficiency across all the platforms-care About-learn once, write anywhere. Facebook uses React Native in multiple production apps and would continue investing in React Native. "

From the website of Rn, we can see that the official is the RN as a set of cross-platform technical solutions, learn once, Write anywhere, that is, RN solves the problem of Android, iOS cross-platform development. But don't forget, the web itself is a cross-platform, HTML, CSS, JavaScript these are universal standards.

View 2 solving Web experience issues

Some people will say that RN is to solve the problem of Web Developer's performance experience on mobile. Indeed, RN optimizes the performance of WebKit DOM rendering by using a large number of native components, reducing the performance overhead associated with JavaScript and native communications through batch update and dedicated thread design, ensuring smooth execution of the main thread. RN's component Loadtime is indeed better than the web, so the experience above, the page load faster, sliding time local white for a shorter period, the user experience better. But it also brings a lot of problems.

Web development is usually based on a complete set of standards, whether in the browser, or in the app's WebView, are in accordance with a set of standard implementation. In other words, web development does not need to care about how the specific browser is implemented, as long as the specification development, can run on a variety of containers above, on this basis, a variety of javascript technology to flourish. Anti-RN, the official provided a set of JavaScript API, but compared with the web, is not mature and complete. It's hard to see the native layer as transparent for web development. Or, there is a great limit to the development of using JavaScript completely without changing native. It is very likely that the performance or functionality of one native component does not meet the existing business requirements, which is awkward and requires us to delve into native components. Once the native component is involved, there are issues such as version and compatibility. As a development, familiarity with the Web native and RN frameworks is required, which brings about the problem of development efficiency. But as the authorities continue to absorb the standard components, the problem will gradually become smaller, but now the problem does exist.

In this perspective, if Web developers have mastered native development skills or support for app development, why not just make the native app? RN's performance and experience and native-based apps still have a gap. This concludes that RN will enhance the Web experience, but with some limitations, it may become a bottleneck behind the development of the business.

View 3 resolving native development and release efficiency issues

Some people will say, native app can not do dynamic release, development efficiency is low, and RN can. In the issue of publishing, AppStore is strictly prohibited hot deployment dynamic code, so each release needs to pass AppStore Audit, and the recent AppStore audit time has been shortened to less than 24h. Android platform above, need to solve is the problem of update rate, the current industry some plug-in dynamic release of the program can be completed dynamic update, such as the Hand Amoy Atlas, reviews of the dynamicapk.

Development efficiency if Android and iOS can be implemented with the same set of JavaScript, you can really boost your development efficiency when you're familiar with the RN environment. However, for native development, there is still a certain starting cost, but also the bottleneck problem mentioned earlier, relying on the completeness of the existing native components.

Question 2 What problem does RN solve now?

According to common sense, the introduction of technical solutions are mostly based on their own problems encountered. But RN is not used in mainstream Facebook products, and the app that uses RN is mostly a niche app.

By contrast, Facebook's instant article is more eye-catching, and the native side will Pageload, the interactive experience as the ultimate goal to improve the content experience. At the same time solve several issues of content publishing, reduce the publishing threshold, increase advertising revenue, provide data analysis.

RN technology itself is not a problem, the problem is that all aspects of a better solution, in real business scenarios but more difficult to use.

Question 3 Where does the embarrassment of Rn originate?

The first to see javascript+native this technology, the idea is the end-travel development community. Many end-travel development is also the technology using the lua+ game engine, Lua writes logic faster and the engine performs better. Different games with multiple sets of scripts, the engine can be continuously reused. This is much like the idea of Rn to solve the problem, but why is the RN upstream not much?

After repeated thinking, the source is found in mobile here. What are the characteristics of mobile? User Time fragmentation, single task. Fragmentation how to understand, according to friends of the League + data analysis report, in addition to the mainstream information, SNS, games, the number of people using the app is a minute, and the number of times will be more than one time. How to understand a single task, users in the use of mobile phones more difficult to do the app switch, Do not start multiple tasks at the same time as a PC. These two core characteristics determine that the user is more difficult to wait, more easily lost. So pageload time is an important indicator, especially for content-based pages. and RN compared with native in pageload time there is a big gap.

On the other side, compared to the Web, RN performance is better than the web, but flexible and far less mature than web technology. But the business of web-technology development generally has some tolerance for the requirements of the experience. There are also projects such as Google's accelerate Web page, which focuses on mobile Web page performance, so that the performance of Rn and the Web can be difficult to pull off a big gap.

So RN is in a flattening out awkward position.

See the problem and find the solution.

"The idea and hypothesis of NB, really to the realization level, must also be implemented to specific users, needs and scenarios of the three elements above."

The front has been talking about the problem, not that do not recognize the technology of RN, just do not want to let everyone follow the boom into the pit, and the key is to put the relevant technology in a comparison, to see which program suitable for their business scenarios.

For example, in the basic function of strong operational requirements, it is very suitable to use RN to do operating modules. Because the characteristics of operations are timeliness, the rate of arrival, and the basic functions need to ensure a stable experience. The past year my team is using native-based + dynamic module This technology, native in advance to do dynamic module support, when the marketing activity point arrives, can use RN this dynamic technology, fast response, dynamic on-line.

For example, like doing instant article this content page, there will be a lot of content, in several typesetting layout display. The core of this type of business is the ability to load and experience content. Businesses like this should identify business-appropriate scenarios and maintain scalability for the future, based on the state of the business and recent developments. If there is no operational requirements scenario, the pure native implementation can fully meet the requirements, design the background interface to take into account the layout and the extensibility of the components, native can guarantee painless subsequent additions and modifications to the layout. The simple architecture also facilitates the continuous optimization of the subsequent targeted bottlenecks.

In short, to remain sensitive to new technologies, in the actual business of technology selection is still to remain vigilant, carefully weighed.

React Native Changed the world? Or nothing.