Recently, I have been discussing the current state and future direction of "front-end technology" and "front-end engineers" with peers through various means. There is a certain consensus among us.
Here are some of my thoughts:
Confusion
To varying degrees, some people have or are currently confused about whether "front-end has a future."
Those who have such confusion might be:
People who are learning web front-end technology, which is purely HTML, CSS, and JS, and are using these to create web pages. During the practice, they suddenly wonder: "With the popularity of WeChat Mini Programs and the competition from native client applications, does front-end have a future?"
Those who graduated and joined the seemingly low-barrier, high-salary front-end engineer ranks, entering a business department of a business-oriented company. The product manager's demands are endless, already filling up the next year. What they are doing is not very mentally challenging, and doing it repeatedly only makes them more proficient. One feature is going live tomorrow, another requirement is due for testing next Friday, and they are constantly busy.
People who always think during work: "If I have time, I must really study technology and improve myself!" But when they do get off work early or have a day off, they think: "I've been too busy lately, so I'd rather watch anime, movies, browse TikTok or Bilibili's funny videos, and play games to relieve stress and relax!"
After a year or two, the team is still the same team, and they are still the same person. Compared to themselves two years ago, it seems that they have only become faster at meeting demands because their techniques and routines are quite proficient. At this point, they can't help but wonder: "Does front-end have a future?"
Similar to the above, some people also joined a business department right after graduation and are busy with business demands every day. The difference is that they are fond of tinkering and have their own technical ideals. Even if they are busy and tired during the workday, they are willing to invest additional time and energy to work on the technical products they want to create, even if they are experimental.
To verify their ideas and test their technical products, integrating them into business is the best way, as they can promote each other. They will advance the team's technology and tool updates while working on business, improving development efficiency. In this way, not only does the business iteration become faster, but they also have more time to tinker, which is a win-win situation!
After a year, the component library, UI framework, and command-line tools they made in their spare time have brought a lot of benefits to the team and the company, but due to environmental and personal limitations, they can basically stop there. However, they still want to continue tinkering, do more things, and further improve development efficiency, but they are helpless: "Does front-end have a future?"
In summary, these people's confusion can be boiled down to two aspects: whether front-end technology has a future, and whether the front-end profession has a future.
Clarification
Looking back, the emergence of HTML was just to share knowledge worldwide, not just to keep it in hand and share it with those around; CSS was also to make text layout better, so that it could be read as easily as newspapers and books; and the birth of JS changed all this, making the web undergo a transformation.
If the era of "static web" with only HTML and CSS is called "web 1.0," then the "dynamic web" era ushered in by JS is "web 2.0." Before this, it can be said that the web front-end had no interaction, and there was no profession called "front-end engineer."
To be precise, the curtain of the "web 2.0" era was also lifted by another hand - Java. To make the web truly dynamic and interactive, both the client and server sides must be grasped at the same time, otherwise, how can data flow?
This has brought business opportunities, expanded sales and dissemination channels, and traditional enterprises have moved transactions from offline to online, turning the physical into the virtual, and giving birth to a batch of enterprises serving these enterprises, as well as enterprises serving these enterprises. Therefore, the business carried out with web pages as the carrier has become more and more, covering all walks of life, and the presentation and interaction of the page have become more and more complex.
The complexity of business logic has also brought great challenges to backend development. At first, they could still write some JS code themselves, and let designers or so-called "page reconstruction engineers" write HTML and CSS. But in this situation, they are already too busy to take care of the front-end! The profession of "front-end engineer" was born.
Gradually, "page reconstruction engineers" exited the historical stage, either transforming into "front-end engineers" or having already changed careers. In web application development, front-end engineers and backend engineers have become a standard combination.
With the advent of smartphones and the arrival of the mobile internet era, there emerged professions such as iOS engineers and Android engineers, who develop client applications for different smartphones. They can be collectively referred to as "client engineers."
Their emergence had no impact on backend engineers, as their work was not in competition. However, it had a significant impact on front-end engineers.
In order to occupy a little space in the user's phone, many enterprises with Internet genes must have their own client applications and recruit a large number of client engineers. Originally, the functions facing users were all changed to client applications instead of web pages, and the work of front-end engineers was basically left to do only the back-end management system. The front-end engineers were marginalized in the company and gradually laid off.
It was during this period that front-end engineers began to contact Node.js, wanting to expand their boundaries towards backend development and increase their survival space. It can be said that this was the lowest and most confused period since the profession of "front-end engineer" was born.
Then, the enterprise's head cooled down a bit and found that every time a new function was to be made, it had to be developed feature * platform times, and the cost was too high! They thought about whether there could be a way to develop only once and run it on different clients, and the experience should not be too bad? This has led to the emergence of hybrid development, React Native and other development modes, tools, and frameworks.
Because most of the new ways are based on front-end technology, front-end engineers have ushered in a chance to turn the tide and eventually make a comeback. Client engineers were marginalized in the company and gradually laid off, and the remaining few were merged into the "big front-end team."
After this back and forth, the profession of "front-end engineer" has been reborn like a phoenix. The exploration of expanding boundaries to the backend during that "confused period" was not in vain, allowing them to adjust their attitude and correct their thinking - do not try to use JS to replace Java. From the perspective of enterprises and the industry, why should you replace Java?
Since then, front-end engineers have been walking on the "pan-client" road. Even if they use Node.js to do something on the backend, it is also for the purpose of making the front-end better, not trying to share a piece of the backend development field.
In the past twenty years or so of the development of China's Internet, the roles involved in the product research and development process have gradually formed into professions such as product managers, designers, front-end engineers, backend engineers, test engineers, and operation and maintenance engineers.
In an enterprise that is on track, there are generally business departments and platform departments, and each type of department will have its own product managers, front-end engineers, and backend engineers. The others depend on the company. The business department directly supports the business needs of the company's survival, and the platform department provides infrastructure and technical support for the work of the business department.
For a long time, business logic has been almost entirely on the backend, and the front-end is basically just some interaction logic, which makes the backend development more complete in terms of infrastructure and ideological system. In recent years, the business logic of the front-end has become heavier and heavier. Moreover, because the professional threshold of the front-end engineer profession is low, many people have not received professional training, and their ability to design software, model, etc. is poor. The robustness, maintainability, and extensibility of the code are extremely poor, causing many engineering and architectural problems.
In the past ten years or so, the emergence of Grunt, Gulp, Webpack, Backbone, Angular, React, Vue, etc., has been to solve the engineering and architectural problems of front-end development. The front-end has been "making up for lost time" in these years, in order to be able to withstand the endless business needs and to catch up with the maturity of the backend's infrastructure and ideological system.
The Dilemma and Way Out for Business Front-end
Front-end engineers in business departments are in a difficult-to-escape dilemma:
Most people want to improve their technical level, but they don't have time and energy to study technology "openly" during working hours. This is "politically incorrect" in the organization. They must prioritize business, and if they want to study, they can only do it in their non-working time. However, in non-working time, due to human nature or other reasons, they will not study technology, or not deeply enough.
In ordinary work, the most they can do to improve efficiency is to create component libraries and scaffolding. The architectural design of some applications and systems has been done by people in the platform department, and they can directly use their things. Business departments generally will not let the front-end engineers under them do overall architectural work, because it does not conform to the "values," that is, the "return on investment" issue.
Most people have a misconception in their thinking - front-end engineers do not need to understand business. They think that their work should be to manually convert product requirement documents and design drawings into pages, and then coordinate data interfaces with backend engineers to ensure that they have no bugs.
You see, even you think that you are playing a "tool-like role" in the whole process of function iteration, converting product requirement documents and design drawings into pages. So don't blame others for treating you as a tool. If the value of front-end engineers is like this, they are destined to be used as tools and resources.
The behavior of front-end engineers is called "facing page development"; those who only know and revolve around frameworks and libraries all day are called "facing framework programming."
"Facing page development" and "facing framework programming" front-end engineers will gradually lose competitiveness, and their work will eventually be replaced by other professions or non-human methods.
In order to keep their jobs, front-end engineers in business departments should not continue like this. There are two general directions for change:
- If you are very passionate about technology and want to greatly improve and break through your technical level bottleneck, then you should go to the platform department, where you can get good exercise and improvement;
- If you prefer the industry in which you are engaged in business, then you should supplement business field knowledge. You don't need to pay too much attention to your technical level, just keep in mind what technologies and solutions are available in the industry, and when you encounter a business scenario that can solve the problem, just use it.
That is to say, the former will establish and continuously improve their own software development ideology, cultivate their programming philosophy, and explore more possibilities; the latter will become an expert in a certain business field, with strong ability to use tools and solutions, but weak technical ability.
Overall, whether you choose the technical direction or the business direction, it will become similar to the thinking and working methods of backend engineers, only the problem domain to be solved is different.
With a span of ten years, developers in business departments may no longer be divided by "end," and directly become "domain engineers" or "product and research engineers"!
What Can Be Done in the Next Ten Years
In general, it is to extract the remaining value of front-end technology. The most urgent at present should be these two directions:
- A very mature and stable infrastructure, allowing business development to focus on business;
- A powerful and easy-to-use low-code development platform, empowering operations and products.
At the same time, you can explore fields such as AI and IoT, and prepare for the next "ten years."
Summary
It should be clear that in human society, the existence of technology is to meet people's needs and make life better; in enterprises, the existence of technology is to serve business and help enterprises make money.
The essence of front-end development, that is, "pan-client" development, is to "solve the problems in the field of human-computer interaction." The focus of practitioners should be "how to better solve the problems of human-computer interaction," not the specific means used. The problems to be solved will not change, but the means to solve the problems are constantly being updated, which is also why "facing page development" and "facing framework programming" front-end engineers will eventually be eliminated.
When entering the industry, you should think clearly whether you want to develop in the technical direction or the business direction, which will have a great impact on your career path. If you choose the business direction, then the business field of your work cannot change greatly, such as the previous company is engaged in online education, and the next one is in e-commerce; if you choose the technical direction, you should also consider the field you want to study in depth, if you want to do infrastructure, then do infrastructure, if you want to do intelligence, then do intelligence.
How long can front-end engineers continue on the "pan-client" road? I think it will be the day when there is no need for human-computer interaction.
How long can front-end technology be used? It might be the day when there is no need for web pages?
Top comments (0)