Frontend Developers Are the Last Shock Absorber in Broken Product Cycles

My personal website recently went live. Everyone is welcome to visit and exchange ideas!!!

Recently, a DingTalk employee's 75,000-word resignation post sparked heated discussion. What truly stung many people is probably not just the management issues of a single team, but the familiar scent everyone recognizes in the same workplace climate:

Projects are urgent, directions change frequently; There are many reports, but little confirmation; Everyone is working hard, but it's difficult to articulate what that effort ultimately accumulates into.

For frontend developers, this feeling is especially pronounced.

In the past, we said frontend was "the person who builds the pages." Later, it became "the person who polishes the experience." Even later, we needed to understand engineering, performance, cross-platform development, data, and growth. In the AI era, frontend developers must also use tools to boost efficiency, build intelligent applications, and understand the boundaries of large model capabilities.

Competency requirements keep rising, but in many cases, the space organizations give to frontend hasn't expanded at the same pace.

1. What's truly worth discussing here isn't just overtime

When outsiders see such events, their first reaction is often "Is it too competitive?" or "Is there too much overtime?"

But what truly exhausts people is usually not just being busy.

A person can push hard for a while for a valuable product, can stay up for days for a real user need, and can accept phased pressure. What drains people the most is not knowing what you are busy for.

Changing direction today, overturning a version tomorrow; Just finished aligning in the morning, only to be covered by new goals in the afternoon; When product data is poor, execution is the first suspect; When team morale is low, pressure is increased to push forward.

In this environment, frontend easily becomes the "pressure-bearing layer" at the very end.

Unclear requirements? Frontend catches the slack. Design not fully thought out? Frontend fills in the gaps. Unstable interfaces? Frontend ensures compatibility. Deadline unchanged? Frontend rushes to deliver.

In the end, the page goes live, but the person is nearly hollowed out.

So, the resonance triggered by this DingTalk incident isn't just because an article was long, but because many people saw themselves in it: not lacking effort, but effort consumed by constantly moving targets.

2. In the AI era, frontend anxiety is amplified

In the past two years, the frontend industry has changed very rapidly.

On one hand, AI tools have indeed improved development efficiency. Writing components, filling in styles, generating tests, troubleshooting issues—many things that used to take half a day can now be done in tens of minutes.

But on the other hand, companies' expectations for efficiency have also risen simultaneously.

Previously, a requirement might be scheduled for three days. Now, they might ask: "With AI, why does it still take three days?" Previously, a page required design, development, and joint debugging. Now, they might ask: "Can you quickly scaffold something to look at first?" Previously, frontend was mainly responsible for implementation. Now, they might also be expected to participate in product judgment, data analysis, interaction optimization, and even directly create prototypes.

On the surface, frontend tools have become stronger; the actual feeling is that the pace is faster and the buffer is smaller.

This is also the dilemma for many frontend developers: AI didn't make us instantly relaxed; instead, it made "fast" the new default.

If team management is mature, AI becomes a tool to amplify creativity; If team management is crude, AI becomes a reason to further squeeze people.

This is the key point.

Technology itself isn't wrong; the problem lies in how organizations use technology. A healthy team uses AI to reduce repetitive work, allowing people to do tasks requiring more judgment; an anxious team uses AI as an accelerator, making everyone run faster without asking if the direction is right.

3. Frontend developers can't just ask "Should I leave?" They must also ask "Can I grow here?"

Facing this macro environment, many people ask: Should I stay, or should I go?

There's no standard answer to this question.

Some teams are busy, but have clear goals, smooth collaboration, and leaders willing to take responsibility and provide growth space. In such a place, even if it's tough, it's worth staying to see.

Some teams seem to have a big platform and hot projects, but internally are chronically chaotic, with goals zigzagging back and forth, management only pushing for progress, and problems passed downwards. In such a place, no matter how big the halo, it will slowly turn into pure drain.

For frontend developers, judging whether a position is worth staying in can be evaluated by three questions.

First, does what you do accumulate?

If every day you're changing styles, rushing campaigns, handling ad-hoc requests, and discarding them after completion—no component accumulation, no engineering improvements, no business understanding, no reusable methods—then after a busy year, your resume might only have one line: "Responsible for developing multiple business pages."

This is very dangerous.

Second, do you have the opportunity to participate in judgment?

Frontend is not a purely executional role. A good frontend developer should be able to participate in experience trade-offs, performance solutions, technical architecture, and product feasibility discussions. If you can only wait for requirements, accept tasks, and be scheduled, with no space to express professional judgment, your growth will be squeezed very narrow.

Third, does your team respect people?

Respect doesn't mean no overtime or no pressure. Respect means someone explains when goals change, someone takes responsibility when plans are overturned, someone conducts a review when a project fails, rather than simply attributing it to "execution wasn't fast enough" or "the owner wasn't dedicated enough."

If an environment makes you feel long-term that you are just a resource, not a person, then you must seriously consider leaving.

4. Don't rush to quit without a plan, but always be ready to leave

Seeing such events, many people feel an impulse: Should I escape quickly?

But realistically speaking, the macro environment isn't easy. Frontend positions aren't as easy to find as a few years ago; competition for junior and mid-level roles is fierce, companies are hiring more cautiously, and requirements for candidates are more comprehensive.

So, it's not advisable to immediately quit without a plan due to momentary emotions.

But it's also not advisable to stubbornly endure in an environment that continuously drains you.

A more prudent approach is: while doing your current job steadily, start preparing an exit strategy for yourself.

For example:

• Organize past projects, upgrading "what I did" to "what problems I solved."
• Fill gaps in engineering skills, such as build processes, performance, monitoring, component systems, and frontend quality assurance.
• Learn to use AI for efficiency, but don't stop at "letting it help me write code."
• Proactively understand business metrics, knowing the conversion, retention, efficiency, and cost behind the pages.
• Create one or two projects that showcase your abilities; they don't have to be large, but must be complete, detailed, and thoughtful.

Today's frontend developers can't survive on framework proficiency alone.

React, Vue, Next, Vite—these are certainly important. But more important is: Can you clearly break down ambiguous problems? Can you make complex experiences smooth? Can you maintain delivery quality amidst change? Can you use technology to help the business avoid detours?

These abilities are what you can truly take with you.

5. The path forward for frontend isn't more competition, but better judgment

Many people interpret "the bad macro environment" as needing to be more hardworking, more competitive, and working later hours.

But I think the direction frontend truly needs to go is not turning ourselves into faster code machines, but becoming engineers with better judgment.

Knowing how to judge which requirements are worth doing and which should be cut; Knowing how to judge if an interaction is over-designed; Knowing when to write a common component and when not to abstract prematurely; Knowing where AI-generated code is usable and where the pitfalls are; Knowing whether the team's current problem is a technical issue, a process issue, or a goal issue.

Frontend won't disappear in the future, but frontend developers with low judgment will find it increasingly difficult.

Because code itself will become cheaper and cheaper. What's truly valuable is understanding problems, organizing solutions, landing the experience, and being able to maintain it long-term.

This is also where we most need to adjust in facing AI: Don't compete with tools on who writes faster; learn to stand above the tools and make judgments.

6. Whether to go or stay, it ultimately comes back to people

In this DingTalk incident, a partner committee member from Alibaba mentioned "mutual respect, treating people as people, with affection and loyalty." The reason this phrase attracted so much attention is that it hit on the most basic, yet most easily overlooked, thing in the workplace.

Companies certainly need results, teams certainly need to compete, products certainly need to seize market windows.

But none of this should come at the cost of continuously draining people.

For frontend individuals, we also need to be honest with ourselves:

If a place still offers growth, space, and trustworthy people, then don't give up easily due to temporary fatigue. If a place only has drain, internal friction, and constant self-justification, then leaving isn't escape, but cutting losses. If you can't leave for now, don't completely surrender yourself to the environment; quietly accumulate your abilities and take back your right to choose.

The frontend industry is still changing, and will continue to change rapidly.

But no matter how tools change, how frameworks change, how organizations change, one thing won't change: the people who can truly go far aren't just those who can write code, but those who can stay clear-headed in chaos, maintain judgment under pressure, and continuously grow amidst change.

So, when we ask "Should I go or stay?" today, the answer might not be to leave immediately, or to continue enduring.

A more accurate answer is:

When you stay, don't stop growing; Before you leave, first take back your right to choose; Wherever you are, don't let yourself become a button that only responds to requests.

Frontend is not the last station on the assembly line. What we build is the bridge between the product and the user.

The bridge must be sturdy, and the person must stand firm too.