If the Web did not support dynamization

Pay attention to the "front-end and backward" WeChat official account, you will get a series of "intentionally original" high-quality technical articles, topics including but not limited to front-end, Node.js and server technology

Wedge
Web is born with extremely flexible and dynamic basic capabilities, such as:

• Dynamically insert script tags to execute arbitrary script logic

• Dynamically insert style tags to introduce any CSS style rules

• Embed the entire site via iframe tags

• The above tags can directly load network resources

• The Web pages that carry these content are deployed on a remote server, which can be dynamically updated at any time and can take effect immediately

The exploration and practice for a long time seems to be just constantly exploring the engineering value of dynamic capabilities, looking for more suitable application scenarios for it, such as the early frameset, today's micro front end/micro application

On the contrary, the mobile terminal has many flexibility limitations:

• Native does not support dynamic execution of logic code

• Most of the key resources that make up a mobile application must be included in the installation package (except for dynamic libraries)

• The application is installed on the user's device, the installation package update needs to be reviewed by the app store, and the user reinstalls it to take effect

The development of mobile services continues to put forward higher requirements for dynamic capabilities, but suffers from the lack of basic dynamic capabilities, so we have been exploring more flexible technical solutions, such as early hot repair/hot update, to today’s small programs

In fact, the engineering problems that the two have to solve in terms of dynamic technical capabilities are the same, such as dynamically loading dependent libraries, view components, and even the entire application. So you might as well make a brainstorm and assume that the Web does not support dynamics, and use Native’s business demands to deduce the development trajectory of Web dynamics technology.

The beginning: native WebAssembly

0061 736d 0100 0000 0187 8080 8000 0160
027f 7f01 7f03 8280 8080 0001 0004 8480
8080 0001 7000 0005 8380 8080 0001 0001
0681 8080 8000 0007 9080 8080 0002 066d
656d 6f72 7902 0003 6763 6400 000a ab80
8080 0001 a580 8080 0001 017f 0240 2000
450d 0003 4020 0120 0022 026f 2100 2002
2101 2000 0d00 0b20 020f 0b20 010b

In the past, Web applications could only be packaged into this wasm binary format and released to major browser application stores. During this period, not only have to wait for several days of review, but also wait for the user to actively install the update after it is passed, and wait until the new version is really "effective" (covering most users), it may be several months later

Version changes are slow, and neither strategically important features nor 100,000 hot fixes can reach users in time. Even if there is a fire online, the fastest fire fighting plan will take days or even weeks to work.

In order to be able to fix the problem faster and reduce the risk, the exploration of the hot fix program starts here

Langhua: Introducing the scripting language JavaScript
hot fix for the hot fix means loading and running the logic code (outside the installation package), so someone directly started with the WebAssembly module loading mechanism and developed some hook schemes that can dynamically replace a certain Modules/files

Some people have gone further in this direction, weighing timeliness, performance, compatibility and stability, and solved the problems of module dependency, version management, and differential updates through compiling instrumentation, engineering supporting facilities, runtime frameworks, etc. , Plug-in each functional module of the application

Others have taken a different approach, introducing a lightweight scripting language runtime (such as a JavaScript engine), and building a bridge between the browser's native WebAssembly and the JavaScript world, allowing the native system platform capabilities to be invoked through JavaScript, thereby expanding the dynamics Basic ability

There was a wave of dynamics, followed by a wave of dynamic updates

海啸：基于 JavaScript 的动态更新
After taking the first step towards dynamization, it is only one step away from the great prospect of full dynamization:

Any application that can be written in JavaScript, will eventually be written in JavaScript. —— Jeff Atwood

（摘自The Principle of Least Power）

Fully dynamic means:

• Move all dynamic parts of the application to JavaScript

• * Organize huge JavaScript code into functional modules and manage the dependencies between functional modules

In this way, rapid iteration with functional modules as a unit is achieved, which is equivalent to applying hot repair technology to the need for iterations other than problem repair. It does not need to be released, eliminates the review cycle, and does not need to wait for users to actively install new features. Dynamic release and rapid coverage to the

dam of active users : The formation
of the container concept. With the continuous improvement of the degree of dynamics, the proportion of JavaScript in the application is getting higher and higher, and finally only the parts that cannot be dynamic (or need not be dynamic) are left Still implemented by WebAssembly, including:

• System platform capability bridging

• Basic UI controls, interactive capabilities

• View layer framework (history stack management, life cycle support, etc.)

• Specific business area capabilities (such as multimedia content production, IM SDK, etc.)

• Communication mechanism (broadcast, state sharing, etc.)

These parts form the container (native shell), which is equivalent to a dynamic runtime running in the browser. Within the capacity delineated by the container, the business can make full use of the dynamic advantages to achieve rapid repair, rapid release, rapid access, Fast iteration

But along with the container concept, in addition to enabling the business to run faster, there is also the dependency between the dynamic business and the container:

• How to release the strong coupling between the two, such as routing, mixed view container and other scenarios?

• How to identify the dependency between the two?

• How to ensure that dependencies are controllable, such as prohibiting the release of dynamic services that rely on new capabilities into old containers?

After the dependencies are managed through engineering supporting facilities, the next primary problem is to find a way to ensure the reliability of the underlying containers on which the dynamic business depends

Boundary: HTML, JavaScript, and CSS constitute
the usual method of isolating changes in container standards by adding a layer of abstraction and placing the changed part below the abstract layer:

• BOM API: abstraction of system platform, view layer framework capabilities and communication mechanism

• Native Module API: Abstraction of capabilities in specific business areas

• DOM API: Abstraction of basic view rendering capabilities

• JS API: Abstraction of JavaScript runtime

• CSS: Abstraction of style and layout capabilities

• HTML: Abstraction of basic UI controls and interactive capabilities

These abstracted standards establish a solid container boundary. Within the boundary, dynamic business can be used arbitrarily. Below the boundary, the container can also continuously improve, enrich the container capabilities, and broaden the boundary. At the same time, APIs with standard definitions can be maintained in a structured form, which is of great benefit to the development experience

Yunhai: The browser supports loading network resources.
On the other hand, in the process of standardization, some dynamic business practices have also been deposited into the container, such as:

• Dynamic script: script supports loading network resources

• Dynamic style: style supports loading network resources

• Dynamic routing: The browser supports loading directly through URL or embedding in web applications through iframe

Although the JS file can be pulled from the CDN since the hot fix, and the runtime dynamic interpretation and execution, the container standard not only provides convenient support for this method, but also expands the basic dynamics from logic to view, style, and static. Resources etc.

At this point, the most critical basic capabilities for dynamization have been completed. The functional modules moved to JavaScript can even be further deployed to the cloud, enabling flexible switching between offline integration and online hosting.

Isshiki: Synchronous and asynchronous modes can be switched freely. The
complete dynamic basic ability unlocks many new gameplay methods, such as:

• Modularity (loader)

• Code split

• ***

• Hydration

• lazy component

• Suspense

The business module (bundle) is further divided into functional modules (chunk), and non-core modules are asynchronously exported to achieve dynamic on-demand loading, such as third-party JS SDK, jQuery plug-in, and heavy components such as sharing/comment/city selection

For partially static scenes of content presentation, you can also complete (most of) page rendering work on the server through *** to speed up the presentation of the first screen content

On the other hand, runtime features such as Hydration, lazy components, and Suspense enable the online dynamic part to be fully integrated with the offline non-dynamic part to achieve more fine-grained business dynamics, making online hosting truly a deployment option

At the same time, the degree of componentization of dynamic business itself is constantly deepening, and the core work of front-end development has shifted from page and module development to component and orchestration logic development.

Flowing Cloud: After the data-driven front-end application
component system matures, a long-standing concept finally emerges-data-driven

From the front-end and back-end hierarchical data protocol, it gradually evolved into data-driven. The data here includes 3 parts:

• Back-end business domain data

• Front-end status data

• Front-end derived data (based on back-end business domain data)

Fill in these data into the business component to render the complete functional module (whether on the client or server), and then place it in the appropriate pit in the view container to complete a component-level "release" "process

This model involves 5 important links:

• Production of business data (including back-end business domain data and front-end derived data)

• Production and maintenance of business components (including front-end status data)

• Rendering of components (business data + business components = functional modules)

• Pit production

• Delivery of functional modules

Among them, business components and pit locations are the key to further dynamics, which can be divided into 4 stages:

• One carrot and one hole: static business components + static holes

• • Throw a carrot everywhere: static business components + dynamic pits

• Throwing multiple carrots in turn: dynamic business components + static pits

• Throwing multiple carrots everywhere: dynamic business components + dynamic pits

To achieve the ultimate goal of component-level dynamics of throwing multiple carrots everywhere, it is necessary to be able to dynamically publish business components and dynamically publish pits.

Blending: Dynamic business components + dynamic pits
From the perspective of devices and clouds, business components can also be regarded as part of the data (cloud). In contrast, pits and devices are more closely related, and the only means of dynamic It is to move the things on the end side to the cloud, so the key problem to be solved is how to realize the dynamics of the pit location

There are 2 ideas:

• Get rid of the concept of pits: extend the concept of pits from the component level to the page level, a page container (a URL) is a pit

• Componentization of pits: Provide standard pit components, just like iframe

The page is a natural dynamic pit, which can open a new page container to load any URL

For other layout containers other than pages, such as dialog boxes, message bars, banner positions, waist seals, etc., the pit positions can be standardized into container components, which are dynamically released together with business components, and the rental relationship of pit positions can be maintained in Server, as one of the data-driven data

At this point, the boundaries of front-end and back-end hierarchies have been redefined several times, and finally ushered in the golden age of JSP/PHP fusion data and templates...