This article was first published on ByteDance Web Infra
The profile
In July, Bytedance Web Infra conducted a share titled “Stepping into Modern Web Development (Bytedance’s Modern Web Development Practices),” in which we sorted out the typical components of the “traditional front-end stack” and showed the bottlenecks in each of them. Driven by these problems, the industry is undergoing a paradigm shift from “traditional Web development paradigm” to “modern Web development paradigm”. The open source project modern.js was announced at the end of this share.
Bytedance Web Infra officially launched the Modern.js open source project at the Rare Earth Developer Conference on Oct. 27-28. In the first part of “Modern.js — Modern Web Engineering System”, we first introduce the industry and internal byte front-end development, and what far-reaching changes are taking place in Web development. From the perspective of these changes, we show the Modern Web development based on modern.js.
These changes include:
More “front-end developers” become “app developers/product developers”.
First, we discuss what are the fundamental factors driving this shift, the significance of “Frontend focus “, point out the long-term trend of lowering the threshold of server-side development and the shortcomings of existing infrastructure, and demonstrate “integrated, serverless full-stack development” and “client-centered Web development” with Modern.
From “front end separation” to “front end integration”.
This paper analyzes the two front-end projects generated by “front and back end separation”, why one of them is “false separation” and the other is “incomplete”, and uses modern.js to demonstrate where “front and back end integration” brings about changes.
Meta Framework replaces traditional “front three musketeers”.
Four generations of “front three musketeers” are analyzed, and each generation is “absorbed” by the members of the next generation. Combined with real cases within bytes, the role of Meta Framework is explained.
Form a mature GUI software research and development system based on “front-end technology”.
First, the definition of “front-end technology” is clarified, and then, combining with the function and design of Modern. Js, how to realize “sufficient abstraction” to solve the contradiction between DX and UX is discussed.
Intelligent, platform, low code.
The second part systematically introduces six elements of Modern.js, including:
Pervasive: The Modern Web Development paradigm.
Nine main features of this paradigm are reviewed.
Core: Modern Web Applications (MWA).
MWA is understood from the perspectives of Universal App, integration, application architecture and Runtime API.
The application architecture section introduces the design and background of the Model in modern.js.
Built in: Front-end engineering best practices.
Listing a few typical best practices, including new tool trends for the post-webpack Era, Unbundled development for Modern.js, and “CSS Three Muskers” for modern.js, Best practices in Modern. Js microfront-end projects compared to microfront-end projects using Garfish directly, modular engineering solutions and Monorepo engineering solutions.
Includes: The whole process of Web development.
The micro-generator function of Modern. Js in “coding” and micro-front-end debugging in “debugging” are demonstrated.
Provide: engineering standard system.
Encouraged: Customized engineering solutions.
It concludes with an introduction to what other initiatives are under way to help modern Web developers in addition to published open source projects. It also introduces Modern. Js’ current high quality community projects.
Share: a memoir
Hi, I’m Zhenwei Song from Bytedance Web Infra. In Bytedance, our department is responsible for building and developing the “Middle platform of Web technology” and the “front-end R&D system”.
In a July share titled bytedance’s Modern Web Development Practices, we took a look at the typical components of the “traditional front-end stack” and showed the bottlenecks in each of them.
Driven by these problems, the industry is undergoing a paradigm shift from “traditional Web development paradigm” to “modern Web development paradigm”.
The Modern. Js open source project is also teased at the end of this post.
Bytedance officially launched modern.js during a keynote yesterday morning. In today’s special session, I’d like to introduce Modern Web development based on modern.js and its practical effects, combining changes and practices within Byte.
The agenda
Today’s share can be divided into three parts.
As mentioned in yesterday’s keynote, there are far-reaching changes taking place in the industry, front-end development and Web development within bytes. Let’s first take a look at what Modern Web development based on Modern.js looks like and differs from these changes.
Then, let’s take a look at the elements and benefits of modern.js as a whole.
Finally, let’s take a look at what’s going on in addition to the open source projects that have been released that are useful to modern Web developers.
Let’s start with part one, “Modern Web Development.”
Modern Web development based on modern.js
1.1 More “Front-end Developers” become “App Developers/Product Developers”
These five areas of change illustrate what “modern Web development” looks like.
There is a link between these five changes. First of all, the most fundamental driving force, not from the technical side, not the front-end developer wishful thinking on the development of technology of subjective preference, but on the Internet and IT industry, market demand, the trend of this side of the user product, need more “front-end developer” as “application developer” or “product development”, encourage and reversed transmission technology, Technology forms and infrastructure are constantly being produced that are more conducive to this need.
A “paradigm shift” occurs when the traditional technology paradigm hits a bottleneck and is no longer able to further adapt to the needs, and a new generation of technology paradigms is redesigned to address the needs from the beginning.
This kind of change promotes the front end technology field to appear “from the separation to the integration”, the new generation “front end three musketeers” change.
The new generation of technical standards and infrastructure brought about by this change began to form a mature GUI software development system based entirely on “front-end technology”, and further developed in the direction of platform-based, low-code.
1.1.1 Meaning of “Frontend Focused
We’ve been talking “front end”, the concept of “front-end” seems to have been only care about the technical details of the developer, but in recent years, turned into business field, investment institutions are also very care about, global markets reflect a more and more of a new generation of cloud platforms and development tools products, most of them involved in the front-end development demand and pattern, There are also many products like Vercel that are explicitly “front-end focused.”
As this slide shows, cloud computing and r&d products started from the bottom of the machine, from virtualization, to container choreography, to a variety of platform and service-oriented R&D tool forms based on container technology. This stage is dominated by back-end technology, and the whole trend is more and more upward. Getting closer to where the market and business value ultimately lies — the user-facing product — inevitably leads to a level of abstraction led by front-end technology, where application development and product development are more focused on user needs and less concerned with server-side complexity and technical details.
Therefore, market demand tends to promote the development of application development to the direction of “focus on the front end”, focus on the front end is to focus on the user, and focus on the user is the fundamental interests of most enterprises and products.
1.1.2 Largest group of developers
Since entering the mobile Internet era, on the other hand, the application of continuously increase development requirements, now not only not reduced, but also in strengthening, such as slide IDC predictions, to meet the demand of such a huge application development, traditional development mode and talent reserve is not enough, need to make as many developers can independently and complete the development of these applications, And the developer of front-end technology stack is the largest developer group and technical community.
So on the user/product/market side, there is a constant trend and pressure for more “front end developers” to become “app developers” or “product developers,” encouraging and pushing the technology landscape to produce technology forms and infrastructure that are more conducive to this need.
1.1.3 The threshold of server-side development is constantly lowered
In this kind of objective trend driven by the application of the web-based technology development, the server side of ratio and threshold has been declining, construction of China, with domestic companies to provide a lot of not with specific client bundle, focusing on the data requirements and the underlying business logic apis, let more focus on product development in the upper of the client business logic. BaaS and back-end cloud Serverless based on cloud functions also further reduce the threshold of the server side, so that front-end developers can be more independent, end-to-end product development.
However, when it comes to lowering barriers and improving efficiency, one of the weaknesses of these infrastructures is that they all rely on apis that are maintained outside of the application project, in a separate way from front-end development.
Another drawback is that they do not address server-side requirements outside of the API, such as routing, SSR, and so on.
There is a typical example inside byte. In the SSR project implemented by the front-end developer, the API of external domain name is always requested by HTTP to obtain data, resulting in frequent SSR timeout and slow HTML response, which seriously affects user experience. Front-end developers can be trained so that they have enough server-side development thinking and knowledge to know that they need to switch to Intranet request mode in THE SSR link, and also consider the caching mechanism, but the more fundamental solution is to shield such server-side problems and implementation details, and automatically deal with these problems.
1.1.4 Integrated, serverless full stack development
Therefore, the trend of constantly lowering the threshold of the server side will naturally develop into the stage of “integration, serverless do full stack development”, allowing front-end developers to directly develop “near pure front-end projects” rather than “Node.js framework projects”, feeling like there is no server.
On the slide is a demo of the first modern. js application project. On the left is the complete directory structure of the modern. js application project. Modern.js automatically generates REST apis based on the path and parameters of BFF functions, and automatically requests REST apis during CSR.
Next we enabled SSR, “differentiated distribution” and “automatic Polyfill” in modernConfig for package.json, and you can see that these functions don’t need to add code logic, just static switch configuration.
After construction, you can see on the left side of the slide that both HTML and JS in the product are available in ES6 and ES5 versions. When users visit the application, the Web Server of Modern. This is called “differentiated distribution.”
The top figure on the right is the result of a modern browser and does not return any Polyfill code. The bottom figure is the result of a browser with a lower version and the Web Server will automatically provide the polyfill code required by this UA.
As you can see, modern.js not only supports all-in-one development of BFF, but also meets server-side requirements outside of BFF, automatically leveraging the native Web Server for performance optimization and product-level compatibility as much as possible, while still maintaining a serverless development experience.
Previously we enabled SSR, and the HTML snippet highlighted in the image on the left already contains the data requested through BFF, automatically selecting the most efficient request based on how the application is running.
This automatic optimization does not prevent developers from mastering the technical details, as the figure on the right shows that BFF functions also generate standard REST apis that can be called manually.
1.1.5 Client-centered Web development
The further development of this integrated, serverless full-stack development will naturally lead to a client-centered Web development approach.
For example, in traditional Web development, in order to achieve common permission recognition and redirection, in addition to the logic of the front page, it is necessary to add the service logic to realize the jump in the route on the server side. For example, when visiting the home page, the user decides whether to redirect to the login page based on the value of the cookie.
In client-centric Web development, the same requirements can be integrated into the client code. For example, in the Modern. Js project with SSR enabled, the Redirect component can be added to achieve exactly the same permissions recognition and redirection effects. The cookie determines whether to return a 302 status code when you visit the page. The whole implementation process is client-side thinking.
Client-centered does not mean that the client cannot control the server side and write the server side business logic directly.
If you are used to node.js framework development mode, you can add custom logic to the Web server of the framework in the hook file of the server directory, such as free to add middleware, you can realize permission recognition and redirection in this part with your familiar traditional Web development mode.
1.2 From “Front end Separation” to “Front End Integration”
The technology stack for Web projects is also shifting, with the development of “front end separation” and a return to “front end integration” in new ways
1.2.1 Separation of Front and Rear Ends
In the past, Web development was like the Ruby on Rails project in the picture. The pink front-end code in the picture “resided” in the green back-end Web framework project. The front-end and back-end would interfere with each other and drag each other down.
Since then, Web development has generally shifted to a “front and back end separation” model, where front-end and back-end projects tend to be of a particular type.
Back-end projects don’t tend to include Web functionality, and front-end projects can be categorized into two types.
MERN is a project type that goes back to its pre-separation state, where the entire project is based on the Node.js framework with the front end embedded in it. This result actually reflects that the implementation of “front and back end separation” is more a separation of labor than a separation of technical architecture, which is still not free from server-side framework-centric Web development.
As can be seen from the structure of MERN project, it is not only false separation, but also not integration. The front-end part represented by React and the back-end part represented by Node.js framework are completely separate in the project, without real integration.
Most projects that use the Node.js framework fall into this category.
Another type of front end project in the “front end separation” pattern, which we call “old generation JAMstack”, has no false separation issues and is pure front end project. SPA and MPA can be implemented, and SSG (static web site generation) can be implemented based on compilation tools. Running on static hosting encourages the invocation of apis in CSR to meet dynamic application requirements.
The biggest problem of the “old generation JAMstack” is that although it is separated into an independent project, it is not enough to undertake complete application development. It can only produce static files and rely on external Web servers to run, so SSR cannot be realized. The API in the three components also needs to be outside the project. Use cloud functions, standalone back-end projects, etc., instead of iterating along with the project.
Most projects built with CRA or directly with WebPack fall into this category.
1.2.2 Front – end Integration
In the context of the need for more “front-end developers” to become “application developers”, the new generation of JAMstack project solves the above problems with a “client-centered” “front-end and back-end integration” approach
Although the three components of the new generation JAMstack remain unchanged, the corresponding content has changed a lot. JS part is more functional and component-based, jS-centered, and HTML can be generated automatically without appearing in the project. The BFF API becomes project self-contained. Compared with the simple static hosting before, based on the front-end Serverless platform can achieve SSR, SPR and other dynamic capabilities, even static pages, can also get a lot of benefits, such as the “differentiated distribution” shown earlier.
Here is a demo of the new JAMstack project using modern.js. Just focus on the JS code during development, whether it’s SPA or MPA, the HTML is automatically generated. Both SSR rendering codes and API logic are output to different directories under DIST according to specifications after construction. The construction product specification is Serverless friendly and supports splitting Web, SSR and BFF into different servers.
As mentioned earlier, modern.js tends to be JS-centric and automatically generates HTML. But that doesn’t stop developers from taking control of HTML themselves. The image shows the default template for modern.js rendering HTML.
The call to an integrated BFF, as demonstrated in the previous example, shows that the file path of the BFF function is a convention, which can implement any design of THE REST API.
The construction product will generate independent runnable servers for BFF, Web and SSR, which is more friendly to the front-end Serverless platform. The Serverless platform can independently choose to run BFF, Web and SSR in different ways in an independent process without interfering with each other. For example, in the SSR link, memory leak of APP code leads to SSR timeout. The Web Server is not affected and can be automatically degraded to CSR mode to return static HTML to the user as a bottom pocket. The USER’s HTML request will never timeout or fail.
For SSR, it can also integrate the development of the front and back ends. The code in the useLoader function highlighted in the figure applies to both SSR and CSR. If the Loader has been preloaded in SSR, the CSR will automatically skip, otherwise it will be executed.
SPR is equivalent to SSR with caching and can be developed in Modern. Js as long as the pre-rendered component is used.
SSG is actually SSR running at compile time. In modern.js, whenever you configure an SSG route, this compilation logic is automatically enabled to generate static HTML for the route. CSR, SSR and SSG all use the same code.
1.3 The new generation of “Front Three Musketeers” and Meta Framework
In addition to the shift to “front-end integration” at the level of technology stack, the traditional “front-end three musketeers” are also being transformed into a new engineering infrastructure called meta-framework at the level of engineering.
1.3.1 Traditional “Front Three Musketeers”
Let’s take a look at the traditional “front three musketeers”, generation 1 and 2, shown here, as they are known. The third generation of “front three musketeers” consists of view frame, Node.js command line and Node.js framework.
The Node.js command line represents engineering, among which the most typical are packaging tools such as Webpack, and compilation tools such as Babel and PostCSS.
The View framework and node.js framework are well understood as the front-end and back-end parts of the MERN project discussed earlier.
1.3.2 The fourth generation of “Front Three Musketeers”
With the development of modern Web development paradigm, the outline of the fourth generation of “front-end three musketeers” has become more and more obvious, consisting of meta-framework, front-end PaaS and low code. The low code direction was introduced in the low code session at rare-Earth last night, and modern.js is the meta framework direction.
It can be clearly seen from this figure that in each generation of the front three musketeers, there is a direction to completely include the front three musketeers of the previous generation in themselves, and become the bottom layer that does not need too much care, so that they can replace them and become the new foundation of the front development.
The view framework in the third generation plays such a role, encapsulating the HTML, CSS and JS of the second generation in its own, while the meta-framework in the fourth generation integrates and abstracts the view framework, Node.js framework and node.js command line, becoming the starting point of front-end development and engineering construction. Meta-frameworks play the role that Webpack and React used to play.
This JS framework S graph can also reflect this transition. In the period on the left, React, Vue, Svelte and other view frameworks were at the forefront and starting point of development, and new view framework projects emerged one after another. Now we’re in the right-hand phase, where the front converges to develop a higher meta-framework based on React.
As a Modern Web engineering system, modern.js is composed of a meta-framework, providing three engineering types and encouraging developers to build their own business engineering solutions based on the engineering types.
Take the “Volcano engine sub-application engineering scheme” inside byte as an example, the initial directory structure has no change, only the default loading of its own framework plug-in in configuration, plug-in through the hook provided by the server to modify the rendered HTML, a shell on the original HTML, This is the unified top bar and left navigation bar of the Volcano engine in the lower right screenshot.
This creates an engineering solution that meets the needs or preferences of vertical scenarios while remaining compatible with the three engineering types, automatically gaining the capabilities and benefits of Modern.js.
1.4 Mature GUI software development system based on “front-end technology”
Under the background of “front-end developers” becoming “application developers”, the development of technology stack and engineering infrastructure began to form a mature GUI software development system based on “front-end technology”.
1.4.1 What is Front-end Technology?
Just to be clear, when we talk about front-end technology, we’re not talking about UI technology, we’re talking about a stack of Web native languages, Web Runtime, and the Web ecosystem. We’re not talking about front-end technology only in browsers, we’re talking about front-end technology where there’s Web Runtime, where there’s Web language.
1.4.2 DX and UX are equally important
Traditional front-end development is not a mature software development system, lack of sufficient abstraction and infrastructure, resulting in a constant conflict between DX and UX. In the past, product development tended to focus more on UX, both because the product was product-led and therefore focused more on UX and less on the developer experience, and because there was a lack of abstraction and infrastructure, one had to be sacrificed between DX and UX.
With the support of a new generation of more mature r&d systems, it is now possible to maximize both DX and UX, and to shift from a “UX priority” to a “DX first” approach.
Sufficient abstraction is required to maximize both DX and UX. For example, in the case of Modern.js, there were only three files in the project, which had comprehensive capabilities, including automatic Polyfill, differentiated distribution, SSR, etc. It had product-level UX, and kept DX simple and out of the box.
1.4.3 Sufficient abstraction
To achieve sufficient abstraction, you need to evolve your project from a “library tools” based project to a “framework” based project, and the distinction between the two is well illustrated in the diagram. The blue background and white border are code written by the project developers themselves. On the left is a traditional front-end project, where developers write the entire application by hand, using libraries and tools as building blocks to fill in the gaps in the project. On the right is the modern.js project. The entire application is the framework itself, with the developer’s hand-written code, which is filled into the reserved space of the framework according to the requirements of the framework.
To achieve full abstraction, you also need to maximize abstraction in as many areas as possible. As you can see in the figure, modern.js not only abstracts at run time and compile time, as a regular framework does, but also introduces maximum abstraction in the IDE where code is written and where artifacts are deployed.
To achieve full abstraction, we also need to solve the problem of front-end templates. Modern.js converges and standardises various development scenarios and project types into three fixed engineering types. The “application” engineering solution, or MWA, supports all projects that need to be deployed and run. The modular engineering solution supports all projects that need to implement code reuse.
1.5 Intelligent, platform-based, low code
Modern Web development, represented by modern.js, is also continuing to develop towards intelligent, platform-based and low-code development.
On the smart side, the currently available features are projects created using Modern. Js initializer, which will be configured out of the box in VSCode to enable the full ESLint rule set of thousands of rules, plus Prettier built into ESLint as best practice, Expect to automatically fix as many problems as possible, not just prompt problems. It also seeks to make the IDE responsible for generating the actual source code as much as possible, so that developers’ hand-written code becomes the language that talks to the IDE.
In terms of platformization, one of the goals of Modern.js is to form an “engineering standard” around which various front-end PaaS platforms can implement advanced capabilities, such as product-level Web Server, differentiated distribution, SSR pocket bottom, ESR, micro front end, etc., as listed in pink. Both require engineering standards at the code level.
In addition to deploying operational platforms, with engineering standards in place, r&d can also introduce more low-code improvements.
At present, our internal use of r & D platform, can be directly on the graphical interface to complete the creation, development and deployment of the project. On the right side of the figure, you can see the status of the current project on the graphical interface: number of entries, project configuration, etc. Add the entry of the application in the blue box, and change from “single entry” to “multiple entry” with one key. On the right, you can also see changes under the SRC directory structure in the Web IDE.
Low code has two directions, one is just said with the combination of research and development tools, the other is the development of low code from some work out of the construction, yesterday’s low code topic has been introduced.
conclusion
So far, we’ve shown many demos and effects of modern.js from the perspective of these changes.
Six elements of Modern.js
Let’s take a systematic look at what modern.js is and what modern.js offers.
2.1 Popularity: Modern Web Development paradigm
These six elements can be used to illustrate modern.js.
First, this project hopes to promote the popularization of modern Web development paradigm, develop a complete modern Web engineering system, and break through the bottleneck of application development efficiency.
In the previous discussion of “Modern Web development,” nine major features of this paradigm were demonstrated.
Serverless paradigm, platformization and low coding are not reflected in the current version of Modern.js, which will be provided with some platforms in the future.
2.2 Core: Modern Web Applications (MWA)
Moving on to the second element. At the heart of the three engineering types of Modern.js is “Modern Web Applications”, MWA, or simply “applications”.
2.2.1 From Universal JS to Universal App
As mentioned earlier, the “Application” engineering solution supports all projects that need to be deployed and run, converging them to one framework, one convention, one template, one architecture, one API.
Conversely, we can also understand MWA from the perspective of Universal App, integration, application architecture, and Runtime API.
Universal JS refers to the same JS code that can be run on both the browser side and the server side. Universal App is a further development of it, the same App code can be run in different links, can also be run in different modes.
The first is the common MPA and SPA requirements, which are essentially “server side routing” and “client side routing” requirements.
In modern.js they can be combined at will.
All of our previous examples are single-entry apps. You can turn a single-entry App into a multi-entry MPA by placing entry identifs such as app.tsx component and Pages directory into subdirectories of SRC. Server-side routes are automatically generated based on entry names, such as the URLS of admin-app and landing-Page entries shown in the figure.
Admin-app and landing-Page are also spAs respectively, one using component-based client routing and one using file system-based client routing, depending on the entry identifier.
And then there’s MWA, “Moving and moving.”
As demonstrated earlier, a static CSR project can directly enable SSR, SPR, SSG functions.
Modern.js also supports CSR and SSR/SSG mixing. For example, the red highlighted area on the right is rendered to HTML on the server side, and the date and time in the blue area is dynamically displayed on the page during the CSR phase. That is, overall SSR + local CSR.
Overall CSR + local SSR capability will be added later.
In terms of BFF support, modern.js also provides a type-friendly way to automate runtime validation of interface parameters and return values via Type Schema. For example, when a request is made in the lower right corner and the parameter text type is number, an error will be automatically displayed in response.
Modern.js also supports the development and running of different types of applications.
Modern.js natively supports the microfront end, and the underlying solution is the Garfish microfront end solution that was previously open source by Web Infra. An MWA can become a micro-front-end host application at any time. After configuring the loading address for the list of stators, Modern.js will automatically preload the child application data into the Web Server and inject it into the runtime. With the help of the Runtime API, you can use child applications just like the normal React component.
MWA can also be run and deployed as standalone Web and micro front terminal applications, respectively.
MWA will be able to run as a desktop application with Electron support enabled, and the project will add a new Electron directory for writing code related to the main process. In addition to capabilities such as out-of-the-box Electron build, it also provides common requirements and best practices for runtime API support for Electron to further improve development efficiency.
2.2.2 Front and Rear End Integration
The second way to look at MWA is “front and back integration”
Each file in the API/directory is a BFF route. When the server-side logic is heavier, you can add elements of the Node.js framework. Currently, 4 different frameworks are supported, and you can develop your own Modern.
As mentioned earlier, being client-centric does not mean that you cannot control the server-side and write the server-side business logic directly.
For example, the volcano engine sub-application demonstrated earlier, in addition to implementing the framework plugin, we can also create server directories and hook files in the project, adding logic to modify the HTML rendering results.
MWA is similar to the JAMstack project when there is only a SRC directory, or an API directory.
With the addition of hook files such as Server, MWA can directly write server-side business logic like traditional Node.js apps, using Node.js framework plug-ins, middleware, and so on.
If you drop the SRC directory, MWA is a pure REST API project.
We call the ability to move freely between these three modes the Trinity.
2.2.3 Application Architecture
Next, let’s look at it from an “application architecture” perspective:
The application architecture in traditional Web development is equivalent to the server-side application architecture. The front-end architecture is either missing, or the project developers need to explore and build by themselves. The lack of API support and consistent abstraction makes it difficult to reuse business logic across projects.
As shown above, MWA provides an out-of-the-box, client-centric application architecture that makes it easy to implement the Model and Controller layers that are missing from React development with a standardized Runtime API. Models, as building blocks that encapsulate UI-independent business logic, can be reused and assembled as UI components.
Previously, in an online interview with Core developers of React hosted by Web Infra, Dan Redux, the author of Redux, mentioned that the most important thing in state management is to understand the type of state and choose the corresponding solution according to what kind of state you need to deal with.
Common state management schemes have appropriate state types and scenarios, and often need to be mixed, rather than a hammer to hammer all nails, with either all states in the global application state or all states in the local state.
Many developers do not use Redux, because Redux itself is only a low-level API and needs to manually create and maintain stores. Business logic has been reduced and actions have been scattered in different places, increasing maintenance costs. The Redux community has always had solutions, such as the Ducks Modular design mode that clusters business logic together, and the mainstream library RTK, officially supported by Redux, was developed to solve this problem.
Modern.js’s Model builds on Redux to further enhance abstraction, preserving Redux’s benefits in immutable data, data flow, and more, and is compatible with the entire Redux ecosystem, benefiting developers both using and not using Redux. Support for multiple state types, as well as different Model writing methods.
2.2.4 Runtime API library
Finally, take a look at the MWA Runtime API standard library.
The basic API equivalent of the “application” level can be used not only in MWA, but also in Modern. Js module engineering solutions to develop reusable business components that support independent debugging and testing.
The top blue square is the API commonly used in business development, such as useLoader, useModel, etc. The green part in the middle is the API used to customize the Web Server and BFF functions mentioned above. The plug-in API at the bottom is the foundation of the whole framework. All packages in the framework are realized by plug-in API, and the plug-in API can also be used to extend the framework and customize engineering schemes. The pink section includes many important tool apis, such as useLocalModel.
The Runtime API is a standard library of apis in the “application” domain. It can be used not only in MWA, but also in the Modern. Js “module” project. You can also use these apis to develop reusable business components that support independent debugging and testing. On the right is the directory structure of the module project. The useLoader API is used in the left TableList component, and only the corresponding story file is required for debugging. The module project scheme supports us to test components using the Runtime API in Storybook visual tests and unit tests.
2.3 Built-in: Front-end engineering best practices
For the third element, briefly enumerating a few front-end engineering best practices built into Modern.js
2.3.1 Post – Webpack Era
Traditional front-end engineering construction is based on Webpack configuration encapsulation, Webpack configuration complex and slow compilation problems, we should have a deep experience, but from last year, the industry emerged a lot of new tools, do not involve Webpack at all, such as Snowpack, Vite, WMR, etc. Some call it JS tertiary.
Since the tertiary era, esBuild, SWC, such compilation and packaging tools are developed in non-JS system programming languages, which significantly improves the compilation speed. The reduced compile time also means that no packaging, on-demand compilation of ESM scenarios can be implemented.
Tools like Snowpack and Vite are developer-first, unpackaged debug models built on top of esBuild. The pattern not packaged in modern.js has been used in real-world scenarios such as building common libraries, developing and debugging business projects, and so on.
There are also built-in unpackaged development debug modes like Snowpack and Vite in modern.js. When enabled on the left side of the image, it works just like the development server starts in seconds on the right side of the image.
How can you do it so fast? Mainly because business code is compiled on demand only when requested using ESbuild, third parties rely on automatically loading precompiled artifacts from Goofy PDN.
2.3.2 CSS best practices
In terms of CSS development, Modern. Js by default recommends the use of “CSS Three Musketeers” in the map. If necessary, you can also enable preprocessors such as LESS/SASS and CSS Modules.
2.3.3 Default zero configuration and minimal boilerplate
Instead of shovelling functionality into projects as boilerplate, the best practice under the modern Web development paradigm is to default to zero configuration and keep boilerplate as minimal as possible. As we’ve seen before, it’s easy to create a modern.js project manually by applying the root component and package.json.
In contrast to a project that uses Garfish directly to develop a microfront-end main application, you can see that a project that uses Garfish directly requires manual running of the Garfish framework, handling common modules, routing, and other logic. In addition to the runtime, you need to customize a bunch of configurations at the compile stage. There is a cost to direct use.
As mentioned in the previous example, to use the micro-front end in Modern.js, you only need to enable the micro-front end function on top of the Web application and provide a list of sub-applications. Each sub-application is a component after loading, and the routes can be organized flexibly by themselves.
2.3.4 Build product specifications
The modular engineering solution of Modern.js compiles in parallel a variety of build artifacts that conform to mainstream community specifications.
Compilation of modules is also unpackaged, making it easier to introduce faster tools such as ESbuild, SWC, etc.
2.3.5 Monorepo engineering scheme
If the application and library are developed in different projects, debugging through NPM Link can also be troublesome. The mainstream solution in the industry manages multiple sub-projects through Monorepo. Modern. At the same time, this part of best practice is convergedto monorepo project. PNPM is used for package management by default. On the left is its directory structure, apps correspond to MWA applications, features/ Packages correspond to reusable modules.
The internal modules on the right are libraries that are not published to NPM and are only reused under the current repository. It itself does not need to build, with the repository under the application directly use its source code. Monorepo we also provide the new command, you can choose to create an application or module.
2.3.6 more
In addition to some of the best practices mentioned above, modern.js provides best practices for unit Testing, integration Testing, Visual Testing, etc., ESlint full rule sets, etc. I will not introduce them here. Consult the modern.js documentation for further information.
2.4 Includes: Whole process of Web development
Modern.js not only provides support for the above run-time, build, debug, etc., it covers the entire Web development process itself.
During the coding phase, you can migrate from SPA to MPA by enabling a feature or adding a portal through the microgenerator. Similar to the “low code enhancement” mentioned earlier, you can also select the feature to enable by executing the new command in the project directory as shown in the image. This command will automatically refactor our code.
With the micro-generator automatically enabled on demand, you can safely provide some functionality as a plug-in and control the volume of your modern.js initialization project.
In the micro front terminal application development, usually the main application has been deployed online, at this time the development of sub-application needs to be combined with the main application online debugging, one of the solutions is through the global proxy sub-application JS to the local, more trouble.
In modern.js, you only need to enable DEBUG mode for the main application as shown in the bottom right corner, then open the link on the main application line, set the information of the child application to be developed in the header, and the server will automatically replace the data of the child application list injected into the HTML. This allows the online main application to load the local child application.
In the process of operation, the traditional Web development mode usually does not provide the way to run the project in the production environment. The MWA project has its own product-level Server, so it can run itself product-level, such as the automatic Polyfill service shown in the figure. As mentioned earlier, with the Serverless platform, some optimizations can be done automatically and the effects of a production environment can be simulated locally.
2.5 Provided: Engineering standard system
Modern.js is not just a Modern Web application development framework, but provides a complete Modern Web engineering system.
As described earlier, we converged the scenarios involved in front-end development into three categories: applications, modules, and MonorePo.
It not only solves the problem of exploding business templates. The integrated project type, such as MWA, is not a simple superposition of multiple scenes, resulting in a large and complete project. It can be lightweight through abstraction, and it is easier to deliver some functions that were difficult to achieve before.
2.6 Encouraged: Customized engineering scheme
Modern.js encourages businesses to tailor vertical engineering solutions to their own scenarios.
Like the volcano engine example mentioned earlier, encapsulate plug-ins, micro-generators, and customize your own business engineering solutions.
Further explanations and examples of the six elements of Modern.js can be found on the modern.js website.
Modern. Js community and Modern Web development system
Finally, let’s take a look at what’s going on in addition to the open source projects that have already been released that are useful to modern Web developers.
The Modern. Js open source project is still in its early stages. The official website launched yesterday and the latest 1.0 release are both in open beta. More comments, testing and practice are needed.
Modern.js started as a Modern Web engineering architecture project within Bytes, and most of the code has now been fully developed on Github, with workflows still under construction.
Bimonthly planning, weekly planning, defect management, etc., will also be fully transferred to Github for public promotion.
The current release does not yet include some of the key features of Roadmap, with plans to add them at a weekly pace.
Other parts of the Modern Web Development system were introduced on the first day of the nuggets Conference. These parts are also important features of Modern.js and will be open to the public in the future.
Thank you.
Liverpoolfc.tv: modernjs. Dev /
Making: github.com/modern-js-d…