Frontend Production Methods in the Past 10 Years and the Next 10 Years
By Li Shuai (Zhuofeng), TaoXi Technology Department, Alibaba New Retail
Before writing this article, I thought carefully for a long time about how to explain why the frontend needs to adopt greater intelligence. Finally, I decided to answer this question by drawing on what I have seen and heard over the past ten years as a frontend worker. I hope it will be useful to you.
Origin
First, I want to talk about my connection with the frontend. Just like me, many people may have entered the frontend industry before understanding exactly what it was.
Getting Started
I had my first experience with the frontend industry in 2010. At that time, the most popular network software programs were Adobe Dreamweaver, Adobe Flash, and Adobe Fireworks.
Adobe Dreamweaver allowed you to use a visual editor to develop webpages by dragging and dropping components and entering information. It was difficult to use the software because it involved so many concepts, but it was the most powerful software for developing webpages at that time.
Adobe Flash was used to make flash animations with ActionScript. I remember that I downloaded a lot of cool flash website source code written by experts in the field, but it was difficult for me to read code at that time.
Adobe Fireworks was used to make posters and animated Graphics Interchange Format (GIF) images. Posters were usually large and long and consumed a lot of memory when cut. Although Adobe Fireworks could make posters quickly, I seldom used it, choosing Photoshop CS4 most of the time.
Even though the three software programs were popular, I became a frontend engineer (jokingly called “UI sketch cutting worker” at that time) because I wished to be a web designer due to the following reasons:
- Software engineering with Java, C ++, and C was boring. To write a program, I had to compile and deploy it and wait for 2 or 3 minutes. When I first learned about webpage development from a foreign teacher, I discovered that webpages were amazing. After I typed a few lines of code in a text editor, changed the extension, and double-clicked a page, the webpage appeared. This beautiful visual experience drew me to webpage development.
- In college, I was able to use a VPN to access many foreign education websites. I found that foreign education websites were beautiful and elegant, with sufficient empty space. On Chinese education websites, especially the official education websites, webpages had poor UI designs and were basically a pile of text, frames, and flashing GIFs (such as the word “New”). Qzone, which allowed users to customize their backgrounds, was popular at that time. However, it was not very elegant. Therefore, I wanted to design webpages that were high-end, elegant, and attractive.
- In college, many of my schoolmates laughed at me for learning webpage design myself, but I stuck to it. After I completed my classes and homework, I usually spent my time learning from Photoshop video tutorials and design materials on my own and through elective courses and labs. I taught myself Photoshop and the RGB color model and applied them to campus poster design and photo beautification. I developed my ability to retouch photos at that time.
- Later, I participated in an on-campus lab project for making a take-out website with a group of people. On this project, I was responsible for webpage development. My partners didn’t think I could develop webpages because I was a beginner. During the project, I taught myself about the World Wide Web Consortium (W3C) technologies online. Even though the jQuery framework was available, I manually made a cascading regional menu selector with HTML4, CSS, and JavaScript and designed the UIs myself. This gave me a lot of confidence. Then, I worked on a string of projects and entered the webpage development industry. This experience bound me forever with the frontend industry.
Full Engagement
I first heard the word “frontend” from a Taobao interviewer. Although I didn’t know what the frontend was, I accepted a job offer to become a Taobao frontend development engineer without hesitation because the interviewer told me that I could work together with engineers and become an engineer in the future if I wanted to. Since then, I have been engaged in the frontend industry.
A Review of the Ten Golden Years of Frontend Development (Low Field Requirements)
When you leave school and start to work, time passes more than twice as fast, and you will be busy with work all the time. At first, I did not understand this, but I gradually came to understand that it was due to the rapid speed of Internet development. From 2G 6G, we are the promoters of Internet development. Therefore, it is normal that time seems to pass quickly for us. People in this community will all understand what I am saying. If you have reviewed frontend development over the past ten years, you will understand this as well.
Next, I will discuss frontend development over the past ten years. Those that are interested in this can read the following sections carefully. For those that are not interested in this topic, I will provide a simple summary. In the beginning, the frontend only needed to develop one webpage at a time. Later, five, ten, or more webpages needed to be developed simultaneously. Faced with increasing challenges, frontend work transitioned from pure webpage development to module-based development, frontend and backend separation, and visualized system building. Functional areas changed from webpage development to backend development and full-stack development, and the field was divided into PC development, mobile development, game or interaction development, Node.js development, and architecture engineering development. The engineering content involved grew from a few lines of jQuery code to a series of highly systematic and complex tasks, such as building, packaging, integration, testing, and phased release. However, the Internet frontend industry is still labor-intensive.
Phase 1: Primitive Development
In 2010, Internet Explorer 6 was popular, and jQuery was dominant in the frontend industry. Even though YUI was also good, most frontend developers used jQuery. A powerful tool called Firebug brought immense benefits to the frontend. In my opinion, frontend development at this time was primitive. Even though visualized webpage editors, such as Dreamweaver, were available, a large amount of useless code was generated, data interworking was complex, and maintenance costs were high. Under the network conditions of the time, a lot of people used Dreamweaver, but I did not.
Phase 2: Modular Development and Framework Upgrades
In 2011, I came to Alibaba as an intern. I found that Tmall (known as Taobao Mall at the time) webpages were high-end and elegant and I was excited to work with the designers (known as UEDs at the time). The frontend team was not large, about 15 to 20 people, including outsourced personnel. YUI was popular in the company and Kissy started to take off. During the six-month internship, I always worked overtime and spent most of my weekends at the company to study the well-organized code written by my excellent predecessors. At the same time, the company had a powerful product called TMS, which allowed developers to use modules and templates to develop a webpage in several minutes. We used this product to build the activity pages for the Double 11 Global Shopping Festival. Modular webpage construction to allow mass production was a mainstream idea in the industry at that time and has continued up until today. If Alibaba had a product history museum, TMS would occupy a prominent place in it.
From 2011 to 2014, the modular approach was dominant. At the time, modular protocols were formulated to design a resource loader for assets. Popular modular protocols included AMD, CMD, and KMD, which were represented by RequireJS, Seajs, and Kissy, respectively. On Taobao and Tmall, Kissy was popular. YUI gradually disappeared, so KMD became the dominant modular protocol. In Alipay and external communities, Seajs was popular, so CMD was the dominant modular protocol, and Yubo, a frontend expert, had a high reputation in frontend circles. Outside China, AMD was popular. However, it was gradually weakened by CommonJS.
The frontend used modular ideas and various frameworks, such as YUI, jQuery, and Kissy to support webpage development. Frontend assets were no longer released with server-side code. However, doc pages were still stored in server-side web containers, and frontend and backend production required joint commissioning and attention to the release sequence. Even though TMS had strong advantages in marketing campaigns, such as 618 and Double 11, it could not ensure fast production in complex primary business processes, such as channels, searches, and transactions, because most of the data was static. Fortunately, marketing campaigns at that time were not intensive and there were only a few activities each year. Therefore, the pressure on frontend production was not significant. However, framework upgrades, such as the yearly Kissy upgrades, were a pain point for frontend personnel in all business lines.
Phase 3: Browser Support and Improved User Experience
With the development of browser kernel technology, Internet Explorer gradually could not keep up with Firefox, Safari, and Chrome. Those who are interested in browser kernel development can find additional information online, such as the article entitled “Comprehensive Understanding of Browser (Kernel) Development”. Chrome paid special attention to the performance of the JavaScript engine and thought that the performance could be improved ten times over. Therefore, it developed a high-performance JavaScript engine named V8 and obtained a BSD open-source license. Chrome gradually became the dominant browser in the industry. The debugging tool chain provided for the frontend was optimized and allowed developers to perform code debugging, performance detection, resource detection, network detection, and DOM structure detection through the console. For frontend personnel, Chrome was a versatile browser. With Chrome, an integrated development environment (IDE) was not required.
Due to Chrome, frontend R&D efficiency was improved. In addition, as HTML5 and CSS3 emerged and were supported by mainstream browsers, webpage performance and user experiences improved. In addition, new webpage technologies appeared, such as effects, animations, and games.
Phase 4: Frontend and Backend Separation and Engineering Optimization
This idea was first proposed by a Senior Expert on the Alibaba Frontend Team. It aimed to solve the restrictions on frontend and backend R&D efficiency due to the over-coupling between the frontend and backend in web containers. Coupling between the frontend and backend was changed to data coupling, with data-oriented programming and full web control by the frontend. This greatly improved the frontend and backend R&D efficiency.
This idea was put forward just as the Node.js Node Package Manager (NPM) ecosystem was established. Using Node.js, Alibaba attempted to separate the frontend and backend. Over the objections of the backend team, the frontend removed PHP, deprecated Java web containers, and took the initiative in web containers. In the Node.js ecosystem, the frontend started to use open-source web application frameworks, such as express, koa, egg, and begg, and engineering scaffolding suites based on Node.js, such as webpack. In addition, a new job description called Node.js Development Engineer was created. Basically, all middlewares in the Java community of Alibaba had corresponding copies in the Node.js community.
After the frontend and backend were separated with the frontend taking control of web containers, the frontend was able to perform unified production engineering design from the client and server, maximizing the frontend page loading performance. The expansion of the frontend functional area also gave the frontend additional work. However, small frontend departments could not take responsibility for web servers because of the high O&M costs involved. With the development of Docker container technologies and cloud infrastructure O&M capabilities from IaaS to PaaS and then to SaaS, server O&M costs fell dramatically. Therefore, the frontend web server O&M costs also fell a great deal.
In the current FaaS phase, serverless has been adopted and O&M is almost transparent and imperceptible to upper layers.
Frontend and backend separation did not improve the frontend R&D efficiency, but it allowed for the optimization of the frontend engineering system. In this phase, the frontend personnel were no longer called page developers because the frontend engineering system, including IDE, R&D, building, packaging, integration, testing, phased release, and production service was almost the same as Java.
Phase 5: Terminal Fragmentation and Technology Development
In 2013, mobile terminals started to develop and Alibaba proposed the All in Mobile initiative. Due to the slow development of browsers on mobile terminals, the web experience on mobile terminals could not keep up with the user experiences provided by apps. Technical products accumulated over many years in the PC era could not cope with the weak network environments of mobile terminals. Following the technical strategy of Mobile First, many infrastructures needed to be redesigned for mobile terminals.
For example, Kissy released its mini version Kimi for mobile terminals. However, as Kissy’s reputation among business frontend personnel decreased dramatically and React Native (RN) and Vue emerged in the community, the Kissy ecosystem gradually disappeared.
Another example was the TMS mentioned above. This product gradually disappeared because it did not adapt to mobile terminals. Instead, new products were used to support webpage building on mobile terminals.
With the development of 3G and 4G and the popularity of iPhones and Android mobile phones, PC-based businesses gradually transitioned to mobile terminals. The attention of frontend personnel moved from PCs to mobile terminals, and the web experience on mobile terminals tried to keep up with the user experience provided by apps. Due to weak support for the HTML5 protocol on mobile terminals, incomplete frontend production mappings, and the diverse specifications of Android screens, frontend personnel found that webpage development for mobile terminals was more difficult than for PCs.
Phase 6: Data-Driven Approaches and Framework Competition
After model–view–viewmodel (MVVM) frameworks, such as Angular, React, Vue, and RN emerged, followed later by Weex and Flutter, the frontend not only adopted data-driven approaches but also used RN to improve the user experience on mobile terminals.
In this phase, the frontend established a terminal underlying architecture team and started to think about the loading performance and user experience of frontend pages on mobile terminals. In terms of mobile terminal R&D, the frontend repeatedly shifted between the web and Weex containers, which increased the technical solution selection workload. In addition, technical solutions in web and Weex containers cannot be reused.
To ensure multi-container multiplexing, Weex used the Vue framework in the ecosystem to streamline WebView and Weex and hoped to use a unified set of code. However, the two types of terminal containers had different capabilities and imposed mutual restrictions on each other. As a result, the unified set of code had many considerations. In this phase, the frontend team was tortured by terminal technologies.
With the development of web capabilities on mobile terminals and increasing client capabilities, such as hybrid, cache, and prefetch, webpages were able to provide a user experience equivalent to apps. After four to five years of development, the web became dominant on mobile terminals. The mobile terminal framework was also determined.
In 2016, the idea of mini programs took off, and the lightweight app open solution became popular in China. A large number of Internet vendors, such as WeChat, Alipay, and Baidu, and mobile phone hardware vendors, such as Xiaomi and Huawei took a share in the emerging mini program market. A new domain-specific language (DSL) for mini programs was born, and the frontend needed to cope with both web development and mini program DSLs from different vendors. This doubled the difficulty of our work. Fortunately, mini program frameworks, such as WePY, mpvue, and Taro emerged and made the lives of frontend personnel easier. For more information about mini program frameworks, see the article entitled, “Comparison of Third-Party Mini Program Frameworks (WePY, mpvue, and Taro)”.
In addition to mobile terminals, which technical solutions should be used for PC customer-end, mid-end, and backend businesses? Is an MVVM framework needed? Which of the React (including Preact), Vue, and Angular frameworks should be used?
After years of disagreement, it was finally determined that the React framework would be used for mid-end and backend businesses, and the same homogeneous solution was used for PC customer-end and mobile terminal businesses. After the framework was determined, frontend personnel started to focus on building component-based materials, such as AntD, Fusion, and ICE mid-end and backend materials. This period saw the segmentation of the frontend field.
Phase 7: Field Segmentation and Visualized Building
After the end of framework competition, the frontend business fields were segmented, which intensified the upper-layer and in-depth construction in different fields. In addition to the Node.js field mentioned above, several other verticals emerged:
Small Frontend
A small frontend is suitable for web and lightweight app business scenarios at the consumer end. In these scenarios, visual system building oriented to operations, sellers, or KOL pages had matured after years of experience in marketing campaigns. Marketing campaigns were supported by such systems.
Mid-End and Backend
Mid-end and backend solutions are suited to enterprises’ ERP, CRM, OA, and other business scenarios. For example, in such scenarios, the supply chain system can use AntD, Fusion, and ICE mid-end and backend materials to provide visualized mid-end and backend building solutions. This allows us to provide unified mid-end and backend production solutions for business frontend, development, or product roles. This mid-end and backend construction aims to improve business production efficiency.
Data Visualization
Data visualization is suitable for enterprises’ data business intelligence (BI) analysis and visual presentation scenarios, such as real-time dashboards that display Alibaba’s Double 11 data and sellers’ enterprise-level data. In such scenarios, visual data chart materials, such as echart, highcharts, and AntV can be used to build visual data systems and provide unified visual data chart generation solutions to the business frontend, development, and product roles. A visual data system can be used to improve business production efficiency.
Interactive Content
With the popularity of new technologies, such as augmented reality (AR), virtual reality (VR), 3D, online games, short videos, and livestreaming (WebRTC) on webpages, a wide range of interactive shopping guide formats have emerged. Therefore, many businesses are seeking to invest in the construction of rich interactive experiences for the future.
There are other vertical fields but I will not describe them here.
The past ten years have witnessed rapid development in the Internet and terminal fields as well as rapid frontend development. Over these ten years, frontend programmers encountered unprecedented difficulties because they had to cope with a flood of new technical products and repeated upgrades. Fortunately, the frontend construction depth in different fields became increasingly mature. These complex approaches to frontend construction aimed to solve business issues and improve production efficiency.
The Outlook of Frontend Development Over the Next Ten Years (High Field Requirements)
Why does the frontend need to focus on production efficiency in addition to solving business issues?
This is because Alibaba has doubled its business volume every year. For example, overseas businesses, businesses in tier-3 and tier-4 cities, and innovative businesses double in size every year. If the frontend production efficiency cannot keep up with business growth, Alibaba will lose its competitive advantages. For example, 2019 saw fierce competition for business in tier-3 and tier-4 cities. If the frontend cannot support business growth and has low production efficiency, it is difficult for a company to retain a share of the market.
As business volumes rapidly increase, each frontend developer must think about how to quickly support business development and promote business breakthroughs and growth. In 2017, the mobile phone shipment volume started to decrease and the dividend derived from the natural increase in mobile users peaked.
Frontend Encounters Bottlenecks
Even though we have sophisticated engineering capabilities, our production efficiency is still low.
For example, to develop a webpage with comprehensive features, a moderately skilled frontend developer might require one week, but a highly skilled developer might only need two days. Even if an enterprise hires only highly skilled personnel, a single frontend developer can only develop about four pages a week. If only ten pages need to be developed, one or two senior frontend developers can complete the project in a week. However, what if we need to develop 100 or 1,000 webpages? How many frontend developers should you hire? With the scarcity of high-end talent and enterprises’ control of HR costs, frontend businesses are placed under double the pressure.
To solve this problem, the industry has started to transition from hard code to low code for efficiency improvement. For example, at Alibaba, a large number of low code platforms oriented toward mid-end, backend, customer-end, and data visualization have emerged. Even though these platforms are very complex, like Photoshop, they gradually matured.
Can frontend personnel rest easy with these platforms? The answer is no because the business iteration speed is fast. Even with these platforms, frontend personnel still cannot solve urgent business problems and the frontend efficiency is still a bottleneck in the industry.
For example, the business volume and complexity of each line that our team serves are high. Each line needs to accommodate tens of millions of access requests, so the business complexity is high. In addition to routine product iteration, at least one or two marketing campaigns are held every month. Even using the low code products introduced above, the business department still frequently complains about shortages in HR personnel. Traditional methods, such as scheduling and requirement cutting, can no longer meet business department requirements.
How Can the Frontend Make Breakthroughs?
To better understand this issue, let’s look at it from another perspective. As we all know, the market has two faces and an elimination mechanism. All industries must change over time. When an advanced technology emerges, outdated technologies are eliminated. In this process, the only independent variable is time.
When Internet e-commerce emerged, how many people imagined that it would cause their jobs to disappear? Many companies remained focused on PC products as mobile terminals developed. Those that don’t notice the crisis in time will be defeated by competitors.
When the iOS and Android app ecosystem emerged, client developers continuously entered the market. Under the effect of objective conditions, such as app market saturation, the limited number of apps that can be installed on terminals, and the rapid development of mobile webpages and lightweight apps for mobile terminals, client developers found it is difficult to keep their jobs.
With the emergence of AI and blockchain, a large number of algorithm developers and tech startups entered the market. Due to market competition, the market became saturated with algorithm developers and many of the startups were eliminated.
To determine the future development of an industry, we need to know what talents are needed in the industry and where the industry is the most lawless and chaotic. If the rules of an industry are surprisingly clear and talent supply is stable, this industry has achieved a balanced state. To break this balance, another industry must disrupt the first.
In the frontend industry, frontend talent is highly sought after by Internet companies, especially large Internet companies. This is because frontend is a labor-intensive industry and the development rules in this industry are chaotic. On the one hand, there is a diversity of terminal products and the frontend industry is facing market attacks from emerging industries, such as smart wearable devices, IoT smart home appliances, smart medical care, and smart buildings. On the other hand, due to the impact of the business development pattern, scale, and distance (from China to areas outside of China), the previous technical rules that governed terminals cannot adapt to emerging terminal fields. The rules, technologies, frameworks, and areas of experience of industry participants are changing.
From this point of view, the functional areas of the frontend field will become wider and wider with increasing demand for talent and higher requirements for talent. This is not only a good sign but also a reminder of the pressure on the frontend industry. If the frontend cannot properly handle this market pressure, it will be eliminated when emerging technologies offer improved productivity. This is the rule of the market. Due to developments elsewhere, an industry may be eliminated without even knowing it.
Look at the production methods of the frontend, we can see the frontend industry is still a labor-intensive industry. Even with excellent talent, the industry will be eliminated if it does not change its production methods. It seems that the frontend has reached maturity in the current phase. However, it is facing many crises.
We need to reflect on our situation and take a wide view to make breakthroughs and revolutionize our industry. This is better than being revolutionized from the outside. In the next phase, the frontend will encounter a common but critical challenge: how to double production efficiency.
Historical experience tells us that an industry’s production supply capability is strictly related to the industry’s processes and techniques. For example, in the traditional manufacturing industry, clothing and textiles were produced manually. Then, when the supply reached a bottleneck, mechanization emerged to assist production. Next, when mechanization reached a certain level, automation emerged to produce products without manual attendance.
Currently, frontend production is still in the manual stage. Even with low code products to reduce the frontend’s production pressure, the shortage of talent still cannot be solved. The only way to ensure that supply can meet demand is automated production.
How can we achieve automatic production in the frontend field?
First, we should not rely heavily on manual work and hand over most of the work to computers.
Then, we need to know how to use computers to solve our production problems. This is the most difficult issue.
Our research shows that there are two methods available. One is the hard code method, which includes the traditional component-based ecosystem. The other is the low code method, where production assistance is offered to assist frontend roles. This method can improve efficiency in specific fields. However, when these fields expand or shift, the low code method may result in higher workloads than the hard code method. Currently, we use the low code method. However, our production efficiency is still low. We expect that the next phase will be “no code”. To achieve no code (AI), machine learning is required. Why?
The development of the Internet has generated massive volumes of data, and the human brain can no longer clearly comprehend the characteristics of an industry. It is impossible for all industries to wait for a genius like Einstein to find solutions. We have to transfer things that our brains cannot do to computers. With the development of cloud computing and AI, it has become easier to use AI to solve our problems. The advent of AI into our field is inevitable and we have to admit that AI is smarter than we are. AI solutions are designed for massive volumes of data and complex problems.
New Ways of Thinking
How can the frontend take advantage of AI capabilities?
This is a difficult question for either frontend or algorithm personnel. However, it is easy for people that have experience in both the frontend and algorithm fields. To clarify this problem, I will first explain how these two fields differ in their approaches to problem-solving. This will make it easier for you to understand.
For example, assume your product manager wants you to make a small game similar to the following figure. The gap between the pipes has a fixed height and the screen moves to the left at a uniform speed. The bird can only move up or down and will fall under the force of gravity. How can you make the bird avoid the obstacles to win the game?
Frontend personnel would typically approach the problem like this: First, they need a canvas with the bird and pipe objects. The bird object contains attributes, such as X, Y, width, height, and alive. X and Y indicate the horizontal and vertical displacement of the bird, respectively. Width and height indicate the bird’s width and height. Alive indicates whether the bird is alive or dead. The pipe objects contain at least five attributes: X, Y, width, height, and speed. X and Y indicate the horizontal and vertical coordinates of the pipe. Width and height indicate the pipe’s width and height. Speed indicates the speed at which the pipe moves leftwards. Then, they will establish a radar warning mechanism based on the speed of the approaching pipes to detect whether there are obstacles in the front of the bird in polling mode. If there are obstacles, the bird can move upwards or downwards to avoid them. Finally, this method will be used over and over again until the bird reaches the end point.
In contrast, algorithm personnel would approach the problem like this: First, they would find a model, such as a network model, and use a genetic algorithm to solve this problem. They could use 50 generations of birds to continuously try to avoid collisions, record the genes of failed birds of each generation, and pass them to the next generation to form a genetic memory. When no bird fails, a successful gene has been trained and birds in the generation can avoid the obstacles.
The code provided by frontend personnel tells the bird how to identify obstacles. However, the code provided by algorithm personnel does not include logic that allows the bird to identify obstacles. Instead, certain features and feedback are abstracted and passed to the network model. It is the model, not the bird, that identifies obstacles. The key difference between the two approaches represents the difference in thinking between programmers and AI algorithm engineers. Programmers try to use code to define everything. However, AI algorithm engineers try to use data training models that can quickly judge between right and wrong. The former is a subjective perspective for solving problems on your own. The written code just tells the computer how to solve the problem. The latter is an objective perspective that allows machines to solve problems. The written code is used to transfer problems to the computer and give the computer the input and final answer. AI algorithm engineers do not care about the process and rules that computers use to solve a problem, only the results.
Review of Requirements
Now that we appreciate these two different ways of thinking, we can view the frontend production efficiency problem from a new perspective.
In the frontend, the keyword is “end”. Front indicates that the frontend is the end closest to users. Any human-machine interaction content transferred through sight, sound, touch, or smell and presented on user terminals (including terminals with specially shaped display screens and terminals without screens and only sensors) can be considered within the work scope of the frontend. How can we use AI to quickly produce human-machine interaction content for so many types of terminals?
To be specific, how can we use AI to efficiently develop webpages?
One idea is to focus on types of content that can be presented on webpages (language on the space axis), such as text, images, videos (which can be regarded as frame-based image animation with audio), and audio. Then, we can see which content is constantly changed on webpages (disordered states on the time axis) and which content is changed through interaction (ordered states on the time axis). Finally, our production policy is: We preferentially import a set of training data from along the time axis to a model and enable it to identify changed content along the time axis. Next, we use a computer vision (CV) or natural language processing (NLP) model to identify entities based on the changed content. Entity identification may involve a series of models, such as a product image identification model. Then, we can use another CV or NLP model to identify unchanged content along the time axis. Unchanged content is typically the page layout and container framework. Finally, we can use a series of entity identification models for mapping between the page structure and code (high-dimensional space vectors with the same cosine values). Theoretically, if there is a large amount of trained sample data, a model can gradually learn the regularities of ordered states, that is, event responses along the time axis.
This approach is a purely algorithm-based way of thinking without any influence from frontend thinking. However, we cannot know the result, or the difficulty of implementation because we have not tried out this approach.
We may use this approach in the future, but it is not currently feasible for frontend development. We may be able to reach an algorithm-based approach by gradually transforming and iterating our way of thinking. Machine learning is not a universal solution. It is greatly constrained by models, and models are often only as good as the computing power behind them. If we regard machine learning as a statistical calculator with complex, concurrent, and intensive computing power (matrix computing in high-dimensional space), the model is the kernel of the calculator. The calculator may be able to calculate hidden laws that govern what we see, but this is deep computing, which requires massive volumes of samples. The samples are the soul of the calculator kernel. It is impossible to produce such massive volumes of samples in a short period of time. Samples are data. Therefore, it is possible to develop deep learning only if there is existing data. Manually created samples have poor quality (they are not objective) or a small scale. You can also first set up the calculator and accumulate samples over time. However, this method takes a long time.
For business practices, we should have at least two solutions, one long-term solution, such as the preceding solution, and one short-term solution. To make a short-term plan, use the rule system and machine learning to obtain a solution. Regardless of which solution is adopted, the sample problem needs to be solved and you need to consider the investment and feasibility. Such investment involves the creation of knowledge and skill reserves. To solve problems, the frontend needs to master machine learning as soon as possible. For more information about how to get started with deep learning, you can use online courses or read the article entitled, “Machine Learning”, written by Zhou Zhihua. You can start with the CV field. It is difficult for individuals to deploy an NLP project in standalone mode. Generally, a cloud, such as Google’s TPU platform, is required.
In the long term, frontend and AI will continue to coexist. With the introduction of AI, the frontend will see many productivity changes. Such changes may be gradual or drastic, but productivity will be gradually transferred to computers. The frontend needs to drive this transformation. The frontend cannot retreat from or bypass this task. This is a problem we must thoroughly solve.
Intelligent Frontend Over the Next Ten Years
Finally, I’d like to look forward to the next ten years of intelligent frontend. Based on the current pace of Internet development, maybe frontend can become intelligent over the next five years.
In the next two to three years, the number of intelligent frontend workers will double, AI will be applied to some products in frontend fields, and various frontend machine learning frameworks for terminals will emerge. User products will be designed to improve the intelligent experience, and communities will start to develop various engineering frameworks, training frameworks, and AI platforms for intelligent frontend.
In the next three to five years, the number of intelligent frontend workers will continue to increase and the traditional frontend will be eliminated. Intelligence will be able to solve business or production efficiency problems in specific frontend fields. The intelligent terminal experience will mature, offering an enhanced immersive experience to users. Online, offline, and screenless terminals will gradually provide the same experience, and communities will start to provide some open-source frontend intelligent products.
In the next five to ten years, the intelligent frontend labor market will be saturated and terminal intelligent experience designers will be highly sought after, such as designers of immersive human-machine games. The no code problem will be solved but also generate other consumption requirements, which may introduce new problems.
Summary
Even though the frontend industry faces many crises, its future is bright. We should make preparations in advance to take advantage of this. Currently, intelligent frontend is a new path.
Team Products
imgcook — One-click intelligent code generation from design drafts
