I think integration tests, e2e tests or smoke tests still provide value. Even for things that you don’t control directly, but at some point you have control over it. You could simply stop using the flaky external dependency and replace it by something different.
Very true. I think the authors area settles more in the webdev area, where you can make releases multiple times per day.
> Optimize for what best serves your purpose. If you have high team fluctuation, optimize for readability. If you develop a spacecraft, optimize for safety. If you ship audio gear, optimize for latency.
I agree. Over-engineering is something many projects suffer from. Principles like YAGNI and KISS help, but it is hard to enforce them by tooling. So it remains a discipline of the engineers.
I assume that the author means, when it is easy to change something in the code (i.e. without fear because you have a very good test automation), then it is easy to apply changes like performance optimizations.
Things like loop unrolling is probably something I wouldnt do by hand on the source code, I would probably write a script that transforms the code automatically, so the original source code stays readable.
> Users being susceptible to dark patterns doesn't mean that dark patterns are something an engineer should see as acceptable.
I think it is not even an engineers job to define the UX/UI. I would rather consult an expert on that matter.
But from my personal experience I can relate to that. When I see applications that seem to be too performant I often get the feeling that they might be phishing pages because they don’t do any actual work under the hood. So my first instinct is to avoid those kind of pages, even though it might be legit.
> That's how you end up with software that's slow due to a million abstractions.
How is an abstraction related to benchmarking? Those are too completely distinct topics.
> Easily bench-marked bottlenecks can give you quick wins
They can... but most of the time it is not a quick win. But the question is not about if it is quick win or not. The only thing that matters is if your are optimizing on the bottleneck or on something that has no measurable impact. Without benchmarking you are blind.
> but that doesn't mean you should stop there or not have any foresight to optimize things ahead of time where it makes sense
Yes, it does. When the bottleneck is gone, and the performance becomes good enough there is no further need to optimize. I am happily quoting Donald Knuth here "Premature optimization is the root of all evil."
> Your cost benefit calculation also needs to take into account that optimizations decisions
This is true. But it doesn’t only apply to optimizations. This applies to any kind of change you want to make to the code. So this has also been to considered when you want to build a new feature. The answer to that is: Optimize for change. Which is basically the fundamental idea working in an agile way, but most people don’t do this correctly. Optimize for change means you need a lot of test automation and clean code, so you can make any kind of code or architecture change quickly with low cost and low risk and without fear. I am practicing this since over a decade now and it works pretty good.
Yes, I have registered on HN exactly for the purpose of sharing and responding to one of the articles. For full disclosure the blog author is a former coworker and I read his blog frequently. To some articles I want to respond and I think HN discussions are the best platform for this.
I mostly agree with the author that optimizing a code base for change should be the number 1 priority, but I think it is different topic than for example application performance. And it is not an either-or ... you can actually do both, the question - as always - is if you should do it all.
- Optimizing for change is basically the key principle of agility. Too ofter it is confused by many people with being fast in delivery by default, just because you apply agile patterns. This is not true. You can be faster than e.g. with waterfall, but most of the time you will be slower. But that is not the point. The point is you can adapt the plan very quickly. So instead of following strictly a 6 months plan, you can change plans on a daily basis and go in completely different direction, if business demands that.
- Application performance is actually not a "tech" thing. So I dont understand why so many developers pre-optimize for application performance without being asked to do so. Application performance is part of UX (User experience). There are studies out there, that sometimes it is even benefitial to be slow and show a loading indicator because it could increase trust from users, because they think "Hey look... the application is calculating something to fullfil my needs", instead of showing the answer instantly. In any case, Application perfomance should be driven by business and user needs, not by engineers who have a personal obligation to do this. And furthermore application performance should never be optimized blindly. Always benchmark the application and work on the bottleneck only.
I agree with the author that precise terminology matters, calling something “unit testing” when it isn’t can definitely blur discussions.
That said, I think the underlying issue isn’t Testing Library itself, but the broader reality that testability in React is inherently limited by its design. As J. B. Rainsberger put it: "If it’s hard to test your code, it’s a sign of a design problem." In my experience, this is one of the most reliable heuristics for evaluating a framework or library.
When I look at a new technology, testability is the very first thing I evaluate, by far the most important property. I don’t care much about performance, bundle size, or reactivity models if the code is hard to test. If it is, I’ll reject it immediately. Hard-to-test systems tend to accumulate complexity quickly, and over time that translates directly into slower iteration, more regressions, and less confidence in changes.
For context, I’ve been working as a software engineer for 15+ years, mostly on medium to large frontend codebases, and using React since around 2014. A large portion of my day-to-day work is writing and maintaining unit tests. Many of the projects I’ve worked on have test suites in the five-figure range that run in under 10 seconds (using fairly simple tooling like Mocha). With that setup, we’ve been able to sustain very high deployment frequencies (10–100 deploys per day), even to the point of auto-merging dependency updates on weekends with automatic deployment, without introducing regressions over long periods of time.
That’s why I’m fairly skeptical when people claim unit testing is overkill or doesn’t add value. In well-designed systems, it’s the opposite: strong unit testability is what enables speed and safety at scale. Integration tests still have their place, but mostly to cover happy paths and verify wiring, not to compensate for missing unit-level confidence.
Coming back to React: compared to other modern frontend frameworks, it’s arguably still in the best position for unit testing, but that’s a very low bar. Vue and Svelte typically require compilation steps and framework-specific tooling, and others like Solid often rely on a real DOM as well. The deprecated react-test-renderer at least allowed some level of isolation, but its developer experience was poor enough that it never became a great solution.
What bothers me more is the official push toward testing in a real DOM environment. Many React components are not even meant to run in a browser DOM in production, think of server components, React Native, react-three-fiber, or Ink. If the framework’s value proposition is to abstract away the runtime environment, then requiring developers to reintroduce that environment in tests feels like a step backwards.
More broadly, this seems to reflect a shift in priorities. Modern frameworks often optimize for advanced capabilities, things like page transitions, complex rendering patterns, or aggressive performance techniques, that are interesting from a technical perspective but not necessarily required in the majority of real-world applications.
In many production systems I’ve worked on, UI behavior is surprisingly simple: mostly static layouts with some interaction and, at most, basic hover effects. Even things like CSS animations are rarely used in practice (I’m still waiting for a real opportunity to use them in a professional context), let alone more advanced concepts like page transitions. As developers, we tend to be excited about these capabilities (I definitely am) but they often don’t materially impact the actual product.
From that perspective, optimizing frameworks around these concerns while testability remains difficult feels like a questionable trade-off. In day-to-day work, the real challenge is maintaining correctness and evolvability over time, and testability is a key enabler for that. It should arguably be a primary design goal, not an afterthought.
This becomes even more important in the current context where AI-assisted development is becoming more common. AI tools are very good at producing code quickly, but they are also very good at introducing subtle regressions. In that environment, a strong automated test suite (ideally following the test pyramid) becomes essential. The goal is to reach a level of confidence where applying AI-generated changes does not introduce fear, because the tests provide fast and reliable feedback. That only works if tests are fast, isolated, and easy to write, which again brings us back to testability as a core design concern.
Ideally, I’d expect the framework to guarantee correct behavior at the environment boundary. From an application perspective, tests should focus on verifying behavior against the framework’s public API, not re-specifying the runtime details the framework is supposed to hide.
I don’t think Testing Library is the main problem here. It feels more like a symptom of a deeper issue: testing React components is hard because of how React is designed. Testing Library doesn’t really fix that, it just works around it by pushing tests toward a more integration-style approach. The real problem is testability itself. If React made it easier to write small, isolated tests, tools like Testing Library wouldn’t need to fill that gap. In that sense, the root cause isn’t the testing tools, but the framework, and that’s where improvements would have the biggest impact.
I’m not sure if I share the authors opinion. When I was hand-writing code I also followed the boy-scout rule and did smaller refactorings along the line.
I’m curious as well. Github is one of the rare products out there that get actual valuable user feedback. So why not just ask the users for specific feedback instead of tracking all of them.
15 years ago I was a big fan of this chaining methods pattern. These days I don’t like it anymore. Especially when it comes to unit-testing and implementing fake objects it becomes quite cumbersome to setup the exact same interface.
Yeah, given there insane pricing I think the expectations can be higher. Although I know it is impossible to provide 100% secure system, but if something like that happens, then the communication should at least be better. Don’t wait until you have talked to the lawyers... inform your customers first, ideally without this cooperate BS speak, most vercel customers are probably developers, so they understand that incidents like this can happen, just be transparent about it