Blendui: Let the webapp experience and interaction get the qualitative promotion

Story background

Baidu Light application has been launched more than half a year, in the market has a certain influence. But at the same time we found that developers use light applications, the most fancy is Baidu's channel distribution capacity, and in the experience and native app has a big difference, the problem after the application of complex become particularly obvious.

A few years ago, when doing mobile Web site, we will pursue some without refreshing jump, change page effect, but later found that doing so in the market top mobile phones can not run smoothly, let alone those relatively cheap and low-end of the smart machine. So over the past year, people have tended to not use complex effects in mobile web sites, but only in the most critical parts, with minimal cost.

Now you've rarely seen a page-change effect with JavaScript in Android, like most of Baidu's product lines give up the local scrolling effect of JavaScript, instead of a native scrolling implementation, or just a few interactive elements of the page. At the same time, many companies have focused their efforts on the development of native native applications, slowing the input on the web side.

And for us, of course, hope that the experience of light application and interaction can be comparable to native, then what can we do to achieve this goal? What is the most effective thing to do?

Research

We first saw the consortium (a report), which came from the task group outputs that shortened the gap with the local application (closing the gap with native). The report points to the advantages and disadvantages of webapp relative to native app.

We went on to look for a lot of data, the best and the most abundant data is developer Economics's research data detailing two key sets of data:

Why don't developers use HTML5 technology to develop applications?

How many native apps can be implemented with Web technology?

After a survey of 6000+ developers, they found that46% of developers think that performance is the factor that affects their choice , which is among the highest in all factors, followed by the lack of APIs , accounting for 37%, and again the integration of native elements , accounting for 29%. This is quite consistent with our subjective feelings as a mobile developer, performance is a huge bottleneck in the webapp, the flow of the app must not be liked by users; Secondly, some functions cannot be implemented by the web, such as voice, positioning, and so on, again, even if these functions can be implemented with native native code, Nor can they be integrated into the webapp.

The second question is the extension of the first question: How much difference does WebApp's ability and native app have to do with the problem of throwing away performance? They surveyed 30,339 apps in Google Play. if only using HTML5 technology, can achieve 37% of the app, if the use of phonegap, can achieve 49%, if the use of appcelerator, can achieve 63%. This result is very optimistic, as long as we can use some technology, the equipment to open some of the basic functions to the web, can greatly improve the scope of webapp applications.

At the same time, we investigated Baidu internal 16 WebApp, want to know as the domestic first-line manufacturers of engineers, they think the bottleneck of WebApp. The conclusion is surprisingly simple and consistent, with 87.5% of engineers thinking that in their own business scenarios, transitions and animations are the most important issues .

In fact, mobile Web site through the development of these years (I was involved in the 2010 Baidu internal Mobile front-end basic library research and development work), engineers and product managers have clearly realized what the Web cannot do, such as 3D turn-screens, dynamic card-type operations, and they flexibly adjust the product design, Avoid these interactions.

But there is one thing that can not be avoided, that is, the animation of the page transitions . The web is built on links, click the link from one page to jump to another page, if through the open way of refreshing, the user will face a blank page waiting, if through no refreshing way, with JavaScript to move into the DOM node, in the demo state can do very well, but once the product, At the risk of a high performance: The page is too large, may not be fluent or even browser crash, a single webview DOM nodes too much, but also to save the state of multiple scenes, will occupy too much memory, in the use of the process will become more and more cards, not to mention those low-end models and low-end browsers ...

So, the primary goal we face is how to webapp the transition to be as fluent as native .

Realize the idea

Before talking about the realization of ideas, we should first give you a light application of the business scene in order to understand.

Business Scenarios for light applications

Light applications have two major portals: Mobile search and Baidu search app, access to light application developers they are most important is the entrance, especially the Baidu search app portal. Because in the ordinary browser, through the mobile search to reach the light application, this is not the essential difference with the ordinary webapp; in Baidu Search app, due to the light application of the operating environment is Baidu Box, we can for light application developers exposed some native API interface, this is the Clouda API, Including the provision of equipment capabilities of the device API, to provide Baidu cloud service capabilities of the Mbass API.

Technology selection

Because of the natural and native combination of light application scenarios, it is natural to think of using native technology to make transitions. Compared with web technology, this road is more realistic: there are many transition-related JavaScript library, Baidu has a number of internal implementation, but the final product after the success, depends entirely on the specific business developers. Whether developers can effectively reduce the number and level of DOM, it is critical to find a cost-effective solution. The use of web technology to solve this problem is obviously not feasible, as is the level of light application developers.

And with native technology to do the transition, we also experienced a number of twists and turns. Initially, we focused on something similar to Appcelerator, but instead of Appcelerator as aggressively compiling JavaScript into native code, we wanted to expose a basic set of native APIs, For the front-end engineers to call to achieve a smooth app effect. But the problem with this is that the customization of the developer becomes particularly bad, relies heavily on the native API, and feels bad to develop, after all, he's not working with DOM, it's a Java like thing. The plan was soon negated by us.

Based on the previous research, I quickly found that there was not much performance concern about ordinary web elements. No matter how complex the pages are, there are few concerns about the performance inside the page, but worry about all the transitions from across pages. Therefore, I have proposed a concept: **every element can be a webview**.