The Frontend Engineer's Playbook for Saying No Without Saying No

After years in this industry, I've seen too many frontend engineers with extremely strong technical skills act like timid interns when facing unreasonable product manager demands.

They clearly know the requirement will crash the production system, or that the interaction simply won't run on mobile devices, but all they can manage to say is: Hmm... this is a bit difficult... I'll give it a try. 😖

Then you end up saddled with an impossible task, work overtime for three days, and deliver a barely functional, accident-prone half-finished product. After launch, bugs inevitably appear, and the product manager deflects blame: You said you could do it back then, didn't you? 😢

How much longer do you plan to suffer in silence like this? Let's talk about some practical advice today👇

---

Why Can't Most Frontend Engineers Say No?

It's not because you have a weak personality, but because you lack a set of precise counter-arguments using technical language.

When a product manager says "This feature is in all our competitors' products, let's add it too," and your only response is "This can't be done" or "There's not enough time," you just look like a lazy person trying to shirk work. Because "can't be done" and "not enough time" are not technical judgments; they are emotional expressions. A product manager's job is to push requirements to completion. If you give them emotion instead of facts, they will naturally keep pressuring you.

A truly senior frontend engineer never says something can't be done when rejecting a requirement. What they say is: It can be done, but here is the cost. You choose.

Throwing the decision-making power and the risk back to the other party—that is the most elegant defensive posture. 🫡

---

Scenario 1: Stuffing 100,000 Rich-Text Data Entries into an Infinite Scroll List

The product manager says: "Change this list to infinite scroll and load all the data at once for a better user experience."

The junior frontend engineer's response: "Okay, I'll try." — Then they write a useEffect that fetches the entire dataset in one go, and the page freezes completely.

It can be done, but I need you to understand a technical fact: The browser's DOM rendering engine has physical limits. When more than 5,000 DOM nodes are mounted on a page simultaneously, the frame rate on low-end Android phones drops from 60fps to below 15fps, causing users to experience extremely noticeable lag and frame drops. 100,000 rich-text data entries mean at least 300,000 DOM nodes, which will directly cause the page to white-screen and crash.

Solution: I'll implement it using virtual scrolling (Virtual Scroll). Visually, the user sees infinite scrolling, but in reality, the browser only renders the 20 to 30 data items within the visible area at any given moment. The experience is identical, but memory usage drops from several gigabytes to a few dozen megabytes. The only cost is an extra 2 days of development time. Can you accept that?

---

Scenario 2: Requiring All Page Load Times to Be Under 1 Second

Product manager: "Our competitor's pages open really fast. All our pages must also load within 1 second."

This goal technically needs to be broken down. Page load speed is not entirely controlled by the frontend; it's the result of a full chain. From the moment the user presses Enter to seeing the content, the process goes through DNS resolution, TCP handshake, TLS negotiation, server-side API response, CDN origin pull, and frontend resource download and rendering—the frontend can only optimize the last segment.

I can compress the frontend's resource loading and rendering time to under 300ms. But if the core backend API response itself takes 800ms, then this 1-second target needs the backend to share the burden. I suggest we first run a full-chain Lighthouse performance analysis to pinpoint exactly where the bottleneck lies, then set segmented optimization targets, rather than vaguely shouting a 1-second slogan.

---

Scenario 3: Implementing a Highly Complex Drag-and-Drop Sorting Interaction on Mobile

The product manager requests: "Like Feishu's Kanban board, we also want to implement cross-column card drag-and-drop sorting on mobile."

Drag-and-drop on desktop and drag-and-drop on mobile are two completely different beasts in terms of technical implementation. Desktop has precise mouse events like mousedown and mousemove, but mobile touch events (touchmove) severely conflict with the browser's native page scrolling. If not handled well, dragging a card will trigger page scrolling, and scrolling the page will accidentally trigger a drag, resulting in a very disjointed experience.

More critically, cross-column drag-and-drop involves extremely complex state management and animation interpolation calculations. Given our current schedule, achieving Trello-level smoothness would require at least 3 weeks of dedicated development plus extensive real-device adaptation testing. My suggestion is to first implement the move-to-another-column function using a long-press context menu. The interaction cost is low, stability is guaranteed, and the development cycle only needs 3 days. We can implement the full drag-and-drop solution in the next version when we have ample scheduling time.

---

Scenario 4: Requiring Frontend Local Encryption of Sensitive User Data

The product manager says: "For data security, encrypt the user's phone number and ID number on the frontend first, then transmit them to the backend."

This approach has a fundamental security flaw. All frontend code, including your encryption algorithm and keys, is completely transparent to the user. Anyone with technical knowledge can open the browser's DevTools, see your encryption key and logic, and easily reverse the encryption. It's like putting a safe and its key in the same drawer—locking it is as good as not locking it at all.

Real security encryption must be done on the server side. What the frontend can do is use HTTPS to secure the transmission channel, and perform basic format validation and data masking at the form level (like showing asterisks for the middle four digits of a phone number). If the business truly requires end-to-end encryption, the backend should issue a one-time public key. The frontend encrypts the data with the public key for transmission, and the private key never leaves the server. This solution requires backend cooperation; I can set up a three-way meeting to align with the backend team. 🤷‍♂️

---

Experts Never Confront Head-On; They Offer Choices

Looking back at these typical scenarios, you'll notice a common pattern: A senior frontend engineer never directly says something can't be done. They always say it can be done, but the cost is X. I suggest choosing an alternative from options A, B, or C.

What is the underlying logic here? It's that you are using highly professional technical facts to help the product manager perform a risk assessment and cost accounting.

When you tell them that 100,000 DOM nodes will crash the page, you are not shirking work; you are protecting the stability of the production system.

Product managers are not your enemies; they simply don't understand the physical boundaries of the browser. And one of your core responsibilities as a frontend engineer is to translate these invisible technical boundaries into business risks they can understand.

A person who can clearly articulate why something shouldn't be done using technical language is always more valuable than someone who just buries their head in code.

Because the former is helping the company avoid disaster, while the latter is merely executing instructions. 🤔

---

Make the Other Person Feel They Made the Right Decision

Finally, I want to share a mindset I've realized after years in this industry.

After you've broken down the risks using technical language and offered alternative solutions, never say "So we should use Plan B." Instead, say: "The risks of Plan A are these, and the costs of Plan B are those. Which one do you think is more suitable for our current business stage?"

Return the final decision-making power to the product manager. Let the other person feel that they made a more prudent choice after careful consideration.

This is not hypocrisy; it's the most basic wisdom in the workplace. You used your professional ability to defend the technical baseline, and the other party used their decision-making power to maintain their own responsibility boundary. Both sides save face.

Compared to slamming the table and saying "This can't be done," leading to an unhappy stalemate, this approach not only protects your system but also protects your interpersonal relationships and professional reputation.

What do you all think?