First, you can learn more about these Web apps.

First, you can learn more about these Web apps.

In recent years, with the emergence of frontend and backend separation and single-page applications, web pages have become increasingly applied. The development of the mobile Internet has contributed to this trend. For scenarios with no interaction or performance sensitivity, Web apps have significant advantages in development costs and cross-platform compatibility.

However, many times, from product managers to design and even development, do not have sufficient knowledge and vigilance about the features of the Web platform, as a result, the final product is neither an App nor a Web product. This not only compromises the user experience, but also makes the development team easy to use.

This article aims to explore the differences between Web apps and Native apps Based on Web features, and help readers identify possible problems as early as possible in the project.

　　Web App is NOT App

Web apps should also follow the Basic Law

A Web App or Single Page Application is named with an App. It sounds like an engineer or stakeholder (product manager or customer ), it is inevitable that a monk will touch me, and the App will do what I do? The illusion. What's more, I threw the design draft of the native App P to the team in the address bar of the browser, so that I could make a Web App. If this is your situation, congratulations, you are already on the road

As the saying goes, since the Web App runs on a browser, even if it can provide a similar experience to the App to a large extent, there are several points that are fundamentally different from what the App must consider:

　　1. Application entry and access path

The App has almost absolute control over the user's access path: where the user enters the application (icon, notification bar, and sharing link) is limited and predictable. The sum of the Operation entries provided on each page is the complete set of sub-paths accessible to users.

The Web has almost zero control over the user's access path: the URLs on any page are visible to users. Users can add bookmarks and share them with friends and friends-any pages may be directly accessed, it must be considered at the design and architecture level.

Authentication and access are not in conflict: in this article, access is strictly called by users, and authentication or redirection is the processing of requests.

　　2. Refresh, backward, and forward

These three operations are the standard configuration of all Web browser toolbar, and the App only needs to consider the return operation in most cases.

Refresh is the most troublesome: it clears the page memory, re-initiates a request, and re-executes the script. This means that the memory data on the Web page is unreliable. If page A depends on the data stored on page B in the memory, only undefined will be obtained during the next refresh.

　　3. Context isolation

A user may perform a series of cross-page operations on an application or site. These user behaviors are called context, and the data generated by operations (such as user selection or form input) is called context data.

Because the App has absolute control over the path and does not consider refreshing, to some extent, the cost of opening a new view by the App is the same as that of opening a modal window on the webpage, the downstream page can assume that the memory data generated by the upstream page exists, and the data is completely accessed through code, which has no restrictions on the data structure. Therefore, the context data on the App side is complex and dependent.

In contrast, because each page can be directly accessed, refreshed, or even copied to another device for access, data stored in memory and LocalStorage become not dependent, the only context information that can be reliably transmitted is limited to the data that can be identified by the URL. without the help of the server, the context data on the Web end is simple or not dependent.

The modern mobile browser provides an application mode that can shield the browser toolbar and make the page more like a native App. However, there are few real application cases at this stage, and there are at least two problems:

Playback cannot be completely blocked: The Return key of the Android platform is equivalent to the playback key of the browser.

The memory that the mobile end can eat at any time may cause the memory to recycle the page that is currently not active. The next time you open the page, reload the page, which is equivalent to a refresh.

　　Why is URL important?

The above three points are actually centered around the core-URL. To some extent, the whole Web world is identified and driven by URLs, and each URL should be located to the corresponding resources.

But the reality is: You may be working on a consumer-oriented project (hereinafter referred to as 2C), but the demand side does not mention the URL and refresh; it is also possible that you are only working on a background management system. No one cares about this, and there may even be some requirements that are contrary to the URL positioning features.

This is the most terrible thing. It is also the original intention of writing this article: few (or even senior front-end engineers) will fully think about this kind of problem before it really gets into trouble, it is difficult to find the accumulation point only when it falls into the trap.