One Decade Later: Revisiting Five Front-End Kung Fu Moves

Exactly ten years ago, I gave a talk at the SF JavaScript meetup titled 5 Kung Fu Moves for Front-End Heroes. A full decade later, I found myself wondering: are these techniques still the secret sauce for modern front-end engineering, or have they been rendered obsolete by time?

Let’s tear them down one by one. And for those feeling nostalgic, watch the 30-minute YouTube video of the talk or take a look at the slide deck.

Git Hooks

The opening move, using git hooks, had a straightforward goal: prevent low-quality code from sneaking into the repository in the first place. Since engineers are human, we may mistakenly check in something we should not. By triggering automated scripts during git commit or git push, we ensure that quality standards remain non-negotiable.

Back then, this felt like a high-level maneuver. Today, it’s a very common practice, especially with Husky or any other similar setup, making the workflow fast and seamless.

Code Complexity

Messy, deeply nested code is a primary breeding ground for bugs. We can measure this objectively, or perhaps semi-objectively, using Cyclomatic Complexity, a well-known metric to ensure a single function does not have so many logical branches that it becomes unmaintainable.

Back then, I recommended the use of JSComplexity. Alas, that tool is no longer suitable for modern development. Instead, use the built-in complexity rule as part of ESLint or Oxlint.

Code Coverage

This third move, code coverage, is a concept now familiar to engineers at every level. The objective is to ensure that no critical logic is shipped without being tested, and it often becomes an important part of the continuous integration pipeline.

Ages ago, Istanbul was the gold standard for code instrumentation for coverage. Today, if you’re using Vitest or similar modern runners, coverage is usually just a configuration toggle away, with plugins handling the heavy lifting behind the scenes.

Cross-Browser Testing

Ten years ago, we were constantly pulling our hair out because every browser had its own quirks and weird behaviors. You had to be incredibly meticulous, checking every single environment to ensure the UI didn’t break.

Today, the landscape has shifted. Most browsers are basically Chromium with a different skin. While Firefox and Safari remain essential, those are pretty close at implementing various web standards. As a result, this move is not nearly as critical as it once was, the gaps between browsers have finally narrowed.

Downstream Testing

The final move: downstream testing. Imagine Module A is a dependency for Module B. Every time you modify Module A, you need to stress-test the combination to ensure the consumer (Module B) doesn’t break. Ultimately, this is about maintaining system-wide integrity. However, with the explosion of micro-frontends and monorepos, I am not entirely sure whether this has become unnecessary (taken care of automatically) or, in fact, is more important than ever (since the coupling is often overlooked).

What do you all think? Do any of these five moves feel irrelevant these days?