Let’s talk about front-end frameworks.
“If I am a front end Leader” is a series of articles of mine, which tells me some of my feelings about being in the position and trying to find the position. The front Leader only has a few connections, but it is suitable for both young and old. Don’t be fooled by the title.
The article Outlines
- What is a framework?
- The history of the front-end ‘framework’
- Front-end framework initiation stage
- Savage growth period
- Front-end framework integration period
- What are the existing frameworks?
- Talk about the construction of front-end team framework system
- Stage 1: Front-end engineering/infrastructure
- The second stage: application development scheme integration
- The third stage: component architecture
- Stage 4: Upstream and downstream
- In the future: AI?
- Extended information
What is a framework?
This isn’t the first time I’ve talked about ‘frames’. Is React a framework? Is Vue a framework? Strictly not, they are just a view solution, and the only one that counts as a framework is Angular.
If the back-end framework is built around a ‘data store’, the foundation of the front-end framework is the visual library, after all, the nature of the front-end is the view. This is why the front-end ecosystem is typically built around an image library. So the foundation of the front-end framework is the view library.
If you work with a backend framework (Rails, Django, Laravel…) There aren’t many mature front-end frameworks out there.
What is a framework?
Let’s look at an example. Open UmiJS, which describes itself as:
Pluggable enterprise React application framework
The key word is enterprise-level. What is enterprise level, I can’t say clearly. All I know is React doesn’t claim to be enterprise-class, nor does Koa or Express, while Eggjs and Umijs both claim to be enterprise-class frameworks; Angular is also often associated with the concept of an enterprise; There is Java at the language level.
I think enterprise-level means it’s for the enterprise, it’s to increase the productivity of the enterprise. Summary has the following characteristics:
- It is the integration of efficient + mature solutions
- Focus on the entire production link, not just one link
- There are stronger constraints and limitations
- More demanding requirements. Performance, scalability (to meet different needs), robustness, stability, availability, security
- standardized
- After production environment verification, there are more use cases guarantee
In the final analysis, it is a matter of cost, and the essential purpose of the framework is to reduce all kinds of costs. To allow fewer people to do more, to ensure quality, to reduce maintenance costs, and to ensure continuous optimization and evolution.
Give me a definition.
The establishment of front-end framework system is inseparable from front-end engineering maturity and ‘best practice’ precipitation. You can think of a framework as an integrated solution that provides a ‘best’ combination of configurations for the front end. All developers need to do is populate their business code within the constraints of the framework.
Benefits:
- Improved efficiency. Let developers focus on business development
- Learning costs are reduced. Frameworks encapsulate much of the underlying complexity
- Stronger constraints. All actions must be carried out in accordance with the framework, avoid doing bad things, stupid things. Stronger constraints also mean more integration, more things can be done within the framework, but less flexibility.
- Product quality. Many things are handled automatically within the framework, such as performance tuning and security handling
- Maintainability. All projects are developed in accordance with consistent and standardized specifications, making it easy to upgrade and iterate. This is important for the maintainability of team projects.
The bad:
- Flexibility. You can’t be all things to all people. Best practices are kind of arbitrary
- Hysteresis. Specific plans may lag.
- A lot. May be excessive for some items.
The history of the front-end ‘framework’
Front-end framework initiation stage
Before React and Vue were popular, there were many ‘front-end frameworks’ like Angular, Ember, Backbone…
Most of them were inspired by backend frameworks, which were at the height of their popularity, like Rails. So you see a lot of backend frameworks in them.
But a lot of the back-end development models are a little hard on the front end. The more essential reason is that the front-end engineering is not mature, the foundation is relatively weak, it is difficult to support the development of superstructure.
Savage growth period
With the popularization of NodeJS and the increasing power of JavaScript language, front-end engineering is gradually deepened. React and other image libraries have been smashed and reconstructed, and a hundred flowers are flourishing.
A variety of libraries have blossomed around the three view libraries, and the front end has expanded beyond the browser. People are happy to build wheels and use the latest technology.
Frameworks/best practices are too fast to be widely accepted or easily obsolete, and each person and team are more interested in creating their own portfolio solutions, often within the team.
Front-end framework integration period
Almost every team goes through this process over and over again: stabilizing the tech stack, engineering, building the base/component library, and settling on their best practices.
In fact, it is very difficult for the team to systematize and organically bond these scattered practices without certain engineering capabilities and resources. Long-term effective maintenance and update is even more difficult, and most of them give up halfway.
Now the front end is plateauing. So the unified front end ‘framework’ has once again come into view. As Umi author Yun Qian said: Now is the industrial era, the framework is like a magic ball, all kinds of technology stacks sucked together, processing and spit out to users, in order to support the business.
The figure above comes from PPT of ant front-end Development Best Practices
A framework is the integration of various technology stack solutions and infrastructure, exposing standard and consistent interfaces, allowing developers to focus on business development.
What are the existing frameworks?
A front-end development framework should cover all aspects of the front-end development link. Provides useful guidance for constraining and simplifying business development.
Take a look at the existing ‘front-end frameworks’. The popular’ frameworks’ in the community right now are Angular, Next. Js, Nuxt, Umi. Let’s cross-reference some of their features and find that they basically include these things:
It’s the same size as a dress. Community open source frameworks are generic type frameworks, and predictably they won’t be able to satisfy all teams. We often need to tailor the framework to our business situation.
To address these requirements, different frameworks have different strategies:
- More open. The framework provides only core functionality, with add-on mechanisms that can do almost anything. Plug-ins can interfere with the entire lifecycle of the framework, and unmet requirements can be customized
- More decisions. What I provide to you is the best. I will try to satisfy you as much as possible. You should not care too much about other things, and there is no need to care about them.
We also have our own selection strategy:
- Yourself. Dachang team, for example, has resources and rich practical experience. They have the ability to systematize their ‘best practices’. They choose to create their own framework. They are also willing to share their experiences and use the community to improve their work. Individuals, for the purpose of learning and fiddling, can also do one.
- Based on the open source framework extension. You can use an open source framework as a foundation to extend your development to suit your team.
- Fully using open source frameworks. Open source frameworks can meet many common requirements and are suitable for simple application scenarios. We chose a framework for two main reasons: 1) we wanted to improve productivity; ② We need a standard. Some things can be compromised for the sake of standards. More importantly, these frameworks are constantly evolving and evolving so that our team’s technology can follow them for free. Consider the default best practice development of open source frameworks as standard.
I’ve always believed that professionals do professional things. Be good at outsourcing and free yourself up to do important things. Dachang has dedicated teams building tools and infrastructure, open source frameworks on the community are maintained by a large group of people, and development iterations are often active. So what the community already has, you can just use it, don’t build your own wheels, because you don’t have the energy.
Talk about the construction of front-end team framework system
Where is front-end development time being spent?
The figure above comes from PPT of ant front-end Development Best Practices
For the front end team, the open source front end framework is just a foundation, just a small part of the front end development, it’s like a boat. You have a flight across the Atlantic, a lot of work to do, tight coordination, reliable logistics, goals and direction, firm leadership… There is still a long way to go.
Now let’s talk about the ‘broad’ framework architecture, which integrates its own business, involves a full link of front-end development, and focuses on moving from front-end applications to front-end team development systems.
The platform of nine stories rises from the tired soil. The construction of the front-end team framework system is a gradual process, starting from the infrastructure, followed by the application development stack combination, then to the component system, followed by the upper level of business development solutions… Based on the upper and lower layers, a complete framework system is constructed together.
I think the front end team can follow this hierarchical structure and accomplish these construction tasks in stages.
Stage 1: Front-end engineering/infrastructure
The most basic stage, focus on the front-end infrastructure construction. This stage is mature, and there are many out-of-the-box solutions in the community, such as Umi, Next-js, VUe-CLI, create-React-app, and so on. The main contents are:
The second stage: application development scheme integration
While the infrastructure is being refined, the team’s application development stack portfolio should be stabilized as part of the framework. These combinations are also important because they affect component building and business development at the upper level. The main contents are:
The third stage: component architecture
Componentization is now the dominant development model on the front end, and there is still a lot of work to be done and a lot of room for improvement.
The whole component architecture is also a hierarchical structure:
- Basic components. The lower the level, the higher the degree of reuse and generality. Ant-design, Element-UI, iView, and Material-UI are some of the basic component libraries, and a team with the ability to develop a component library that fits their own Design style.
- Business components. A component that is encapsulated on top of the underlying component and coupled to its own business. They are generally abstracted from repetitive business scenarios.
- Block. Beyond that, it’s hard to organize with modular components. Then someone (Ali front-end) came up with the concept of ‘block’. You can think of ‘block’ as: code snippet, code sample, code template… So this is not a new concept, right? Yet!!! Blocks need to be aligned with ‘block markets’ to demonstrate their usefulness. The Block market is a code-snippet sharing platform that maintains a large number of blocks in an attempt to cover most common usage scenarios. For developers, it’s a matter of finding a block that matches your scene as best as possible, copying it in, and tweaking it a bit. This is a perfect exercise in the ‘Ctrl+C, Ctrl+V’ programming philosophy.
- Page. Similar to blocks, pages and routes are generated quickly. Reduced-form routing makes automatic page creation easier.
- Layout. For example, the overall layout of the background.
- The project. Overall structure of the project. Scaffolding can be used to quickly generate project templates.
Fly ice
Operations like blocks and page generation require some tools. Such as:
- The generator. Generate different levels of components
- Project (Project template). Commonly known as scaffolding, supports different project types: applications, component libraries, libraries, plug-ins
- Page/Route
- block
- component
- The data model
- Visualization tools. Visual project choreography tools such as Flying ice.
Stage 4: Upstream and downstream
The front end is just a part of the RESEARCH and development process, just the front end from hi, upstream and downstream without resource support, it is difficult to go far.
For the front end, usually upstream refers to the UI and downstream refers to the back end.
For the UI. The component architecture mentioned above is actually based on a stable, consistent, unified UI design language. Otherwise it’s all empty talk. So we require the UI design team to have good design practices, to be able to bind to the front-end component architecture, and to iterate.
For the back end. It can facilitate the establishment of more standard interface paradigms, encapsulating common services (for business component reuse), deeper business intermediates, BFF…
Upstream and downstream get through, the liberation of front-end productivity also has a very big role in promoting.
In the future: AI?
Does AI automatically generate front-end code? How can 79.34% of the Code in The Double 11 module be intelligently generated? , slipped
Extended information
- Best practices in ant Front-end Development good article
- How is the 79.34% code of double 11 module intelligently generated?