DEV Community: Anton Trishin

Why Learn Binary Search When You're Paid to Build Buttons?

Anton Trishin — Mon, 20 Jul 2026 15:07:51 +0000

Hi!

There's been an ongoing debate among developers for years: do algorithms really matter in everyday software development, or are they just dry theory for passing coding interviews? I decided to join the discussion.

When I started my career as a frontend developer, I constantly asked myself questions like: "Why do interviewers ask me to traverse graphs if all I do at work is adjust CSS margins?" or "Why should I know Big O notation if my layout still breaks in Safari?" With the rise of artificial intelligence (AI), these questions have become even more common: "Why should I think at all if an AI agent can write this loop for me?"

However, as I improved my algorithmic skills, I began to notice their practical applications in real-world development—especially when the task involved something more complex than vertically centering a div. I learned to design cleaner implementations of business features, identify performance bottlenecks more quickly, and, most importantly, gained confidence in my own decisions.

There's an important nuance here: yes, you can write a good prompt and get optimized code from an AI in seconds. End of story, right?

Not quite.

The responsibility for a feature still lies with the developer, and when a bug appears, you're the one who has to fix it. But how can you fix a bug if you don't understand how the function works? You can keep feeding prompts to an LLM and hope for the best, but sooner or later that turns into an endless cycle of trial and error.

LLMs are excellent at generating code, but they usually don't know the constraints of your particular project. They don't know how many users your system serves simultaneously, what your memory limitations are, or where the actual bottlenecks lie. The better a developer understands the algorithms behind a feature, the more accurately they can instruct the model—and the faster they can distinguish an efficient solution from one that merely looks elegant.

If you clearly understand the algorithm behind a feature, you'll have no trouble extending or improving the solution yourself, or guiding the same LLM in the right direction much more effectively.

Based on my own experience, I've come to the conclusion that algorithms are neither an end in themselves nor just abstract LeetCode exercises. They're a foundation that gives frontend developers three key advantages:

Faster development by relying on well-known, time-tested algorithmic patterns.
Higher code quality and more mature engineering decisions when designing component architecture.
A direct impact on the business through better performance, interface stability, and user experience (UX).

Below are several examples of how classic algorithmic ideas appear in everyday frontend development. For each example, I've included a link to a similar LeetCode problem to make it easier to connect the learning exercise with its practical application.

Two Sum: Fast Data Lookup

Imagine an online store where a customer adds an item to their shopping cart. The system needs to determine whether that item is already in the cart so it can either increase the quantity or create a new entry.

A naive approach would iterate through every item in the cart each time a product is added. While this works for small carts, performance degrades as the number of items grows.

In real-world systems, this logic is typically implemented using a key-value data structure, where productId serves as the key. This makes it possible to quickly check whether an item exists and update its quantity without traversing the entire collection:

if (cart.has(productId)) {
  cart.get(productId).count++;
} else {
  cart.set(productId, { count: 1 });
}

At first glance, this looks like a simple in-memory collection operation. In practice, however, the same idea is often hidden behind databases, indexes, or caching layers, where existence checks and updates are performed through fast key-based lookups. The same principle also applies on the client side—for example, when organizing data in a state management solution.

This is exactly the principle demonstrated in LeetCode #1 (Two Sum). Instead of performing a linear scan of the collection, the solution uses a hash-based data structure to instantly access previously seen elements. In one case, we're looking for two numbers whose sum matches a target value; in the other, we're managing the state of a shopping cart. The context is different, but the underlying algorithmic pattern is the same: replacing a full scan with a key-based lookup.

LRU Cache: Data Caching

Imagine a typical web application. Every time a user opens a page, the application requests configuration data—feature flags, UI settings, available languages and currencies, and other reference information.

While the user navigates through the application, this configuration rarely changes. Without caching, however, the frontend continues sending the same requests over and over again. As a result, the API receives unnecessary load, the number of network requests increases, server-side rendering (SSR) slows down, and Web Vitals suffer.

The solution is to use a cache that evicts the least recently used entries:

const key = "/api/config?locale=ru&currency=RUB";

let config = cache.get(key);

if (config === -1) {
  config = await api.get(key);
  cache.put(key, config);
}

return config;

From the outside, this looks like ordinary caching. Internally, however, cache.get() and cache.put() implement the same logic as the LRU Cache problem in LeetCode #146. Every time an entry is accessed, it is marked as "recently used." When the cache reaches its capacity, the least recently used entry is automatically removed.

Algorithms like this are used every day in real-world systems and have a direct impact on application performance and stability.

Merge Intervals: Working with Time Ranges

Now let's consider a meeting room booking system. The frontend receives a list of occupied time intervals and needs to display them as a timeline in a calendar.

In many cases, the data contains overlapping or adjacent intervals—for example, after synchronizing schedules from multiple sources. To display a clean and continuous schedule instead of a collection of fragmented blocks, the data must first be normalized.

Before processing:

09:00–10:00
09:30–11:00
11:00–12:00
13:00–14:00
13:30–15:00
16:00–17:00

After processing:

09:00–12:00
13:00–15:00
16:00–17:00

This task is usually handled on the backend or at the database level. However, in some situations—such as applying local changes or merging data from multiple sources—it may also be performed on the client.

This is exactly the problem solved by LeetCode #56 (Merge Intervals), which merges overlapping intervals into the smallest possible set of non-overlapping ranges.

This algorithm is commonly used when building calendars, timelines, scheduling interfaces, and any application that works with time intervals.

Promise Time Limit: Controlling API Timeouts

Imagine a web application that fetches data from multiple external services during page load. Under normal conditions, the APIs respond within 100–200 ms. However, due to network issues or heavy load, a request may occasionally hang for tens of seconds.

If you simply wait for the Promise to resolve, users may end up staring at a loading indicator indefinitely, while server-side rendering (SSR) becomes significantly slower. That's why production applications almost always enforce request timeouts:

const data = await timeLimit(
  () => api.get("/api/profile"),
  3000
);

If the API doesn't respond within three seconds, the request is canceled, and the application either displays an error message or falls back to an alternative solution.

LeetCode #2637 (Promise Time Limit) formalizes this scenario by implementing an asynchronous operation with a strict time limit.

Strictly speaking, Promise Time Limit is not a classical algorithm like binary search. It's better described as an engineering pattern for managing asynchronous operations. Nevertheless, problems like this develop an essential skill: limiting execution time, handling failures gracefully, and designing resilient systems.

Top K Frequent: Finding the Most Popular Items

Most online stores have sections such as "Popular Products," "Frequently Bought," or "Recommended for You." In large-scale systems, this functionality is usually implemented at the database or analytics layer using aggregations, indexes, or specialized analytics platforms.

However, if you need to implement this logic yourself, the core problem is frequency counting: given a large stream of events, find the K most frequently occurring items. This is exactly the pattern formalized by LeetCode #347 (Top K Frequent Elements).

Of course, this is far from a complete list. Frontend development offers many other examples where algorithmic ideas appear in practice. For instance, binary search is used internally by list virtualization libraries such as react-virtualized and TanStack Virtual to efficiently determine which items should be rendered as the user scrolls.

Understanding algorithmic principles allows developers not only to use existing tools effectively but also to design solutions tailored to the specific requirements and constraints of their own products.

Conclusion

In my opinion, algorithms aren't something you learn just to argue on the internet or climb the LeetCode rankings. Their real value lies elsewhere—in understanding what solution patterns exist and how they behave in real-world systems.

This has a direct impact on the product. It helps you find scalable solutions more quickly instead of relying on simple but costly workarounds, and gives you a deeper understanding of what's happening under the hood of the tools you use every day—from databases and caching systems to modern frameworks.

The better a developer recognizes these patterns, the more likely they are to build not just code that works, but architecture that remains reliable as traffic, data volume, and overall system complexity continue to grow.

How to Test 40+ UI Components in Under a Minute: Speeding Up Screenshot Tests

Anton Trishin — Mon, 06 Jul 2026 07:07:34 +0000

Hey DEV! My name is Anton, and I am a frontend developer. Our team is responsible for the "Product Snippets" library — those exact real estate cards you see in our search results.

The problem is that we have over 40 types of these cards: snippets for secondary, primary, suburban, and short-term real estate, with each type having multiple sizes for different screen resolutions. All of them live in a single monorepo library built on React 19. Any fix in shared styles, global design tokens, or a basic update to the design system components turned into a game of Minesweeper: tweak a margin in one snippet type, and the layout breaks or padding shifts in another. We would find out about this either during the release testing phase or, even worse, from users after production deployment.

In this article, I will share how we implemented a full-scale Visual Regression Testing workflow based on Storybook, Playwright, and Jest, the challenges we faced while stabilizing screenshots, and how we made the tests run flawlessly.

Why Not Jest Snapshot Tests?

Many developers confuse classic DOM Snapshot testing (checking the HTML structure) with visual testing (comparing actual rendered images). Snapshot tests did not fit our needs for several reasons:

Tons of useless code. Any change to an autogenerated class prefix (for instance, in CSS Modules) completely breaks the text snapshot. As a result, diffs become huge, unreadable, and useless.
Blindness to the actual UI. A test compiler can show that the HTML structure is perfect. However, if an element is hidden behind another due to a z-index, a button shifts because of position: absolute, or flex-wrap breaks, a text-based Snapshot simply will not notice.

We needed a tool that could "photograph" over 40 snippet variants in a real headless browser in a matter of seconds and compare them pixel by pixel. We chose a combination of @storybook/test-runner + playwright + jest-image-snapshot.

How It Works

We built a fairly simple but robust architecture:

Storybook is the single source of truth for the UI. Every snippet exists as a Story: different sizes, states, and property types. In this setup, Storybook acts as a unified catalog of UI scenarios.
Test Runner (Jest + Storybook Test Runner). It iterates through all Stories, renders them in Headless Chrome (via Playwright), and captures screenshots of each state.
Jest Image Snapshot is the comparison brain. It compares the reference baseline image with the current render.Test Runner Configuration. Here is our test-runner-jest.config.js:

const { getJestConfig } = require('@storybook/test-runner');

const defaultOptions = getJestConfig();

module.exports = {
  ...defaultOptions,
  testTimeout: 30000,
  testMatch: ['<rootDir>/src/**/*.stories.[jt]s?(x)', '<rootDir>/src/**/*.story.[jt]s?(x)'],
  testPathIgnorePatterns: [
    'node_modules',
    '.cache',
    'dist',
    'lib',
  ],
  maxWorkers: '50%',
  transform: { ...defaultOptions.transform },
};

Startup Scripts. To make the tool as developer-friendly as possible, we created two npm scripts:

"screenshot:test": "npm run build-storybook && (serve storybook-static -p 6006 & wait-on http://127.0.0.1:6006 && test-storybook)",
"screenshot:update": "npm run build-storybook && (serve storybook-static -p 6006 & wait-on http://127.0.0.1:6006 && test-storybook --updateSnapshot)"

The Three Big Stabilization Issues and How We Fixed Them

When we ran our first tests, the diff folders immediately got clogged with false positives. Images kept flashing due to network latency, dynamic web fonts, and other flaky behavior. Here is how we tackled these pain points:

Network Chaos in Galleries. Our snippets feature real estate image galleries. Initially, Playwright would snap screenshots before heavy images could finish loading over the wire. We decided to ditch real network images entirely during tests. Using page.evaluate, we find all gallery containers and wipe out the src and srcset attributes from img and source tags. This forces components to instantly render lightweight fallback placeholders hardcoded into the app. Test execution speed jumped by almost 2x!
Full-page Screenshots and Extra Padding. Initially, we tried taking screenshots of the standard #storybook-root container. In practice, this caused a lot of headaches: the Storybook wrapper had fixed styles like height: 100vh; padding: 16px;. As a result, while the product card itself looked fine, it was surrounded by massive areas of empty white space.We ditched the idea of photographing the entire page and targeted the inner content instead—the specific snippet with the [data-test="product-snippet"] attribute. We relied on the native elementHandle.screenshot() method. Playwright automatically isolates this DOM element, calculates its pixel boundaries, and crops the shot exactly to its outline, completely ignoring everything else on the page. To give the images some breathing room and prevent the card borders from looking too cramped, we used JS in the very same step to inject a clean 16px white padding around the element.
Browser Micro-noise and Font Anti-aliasing. Even after isolating the snippet, wiping out gallery images, and agreeing to run tests strictly locally on dev machines, our screenshots still managed to occasionally flake. The culprit? Headless browsers are notoriously finicky. If the OS spikes the CPU even slightly during a test run, Chromium might delay subpixel text anti-aliasing by a fraction of a millisecond, or cause a barely perceptible micro-shift in how shadows and rounded corners are rendered. To avoid re-generating golden master snapshots after every random system hiccup, we configured three "golden" sensitivity parameters in jest-image-snapshot. This taught the tool to ignore digital noise invisible to the human eye:

customDiffConfig: { threshold: 0.1 } — This controls the color sensitivity threshold for individual pixels. Setting it to 0.1 means that if a pixel's color deviates from the baseline by less than 10% (often caused by rendering quirks in semi-transparent elements or gradients), Jest won't flag that pixel as changed at all.
blur: 1 — This applies a subtle 1-pixel blur to the images before comparing them. It is the easiest and most effective way to eliminate flaky font anti-aliasing. The faint gray pixels on the edges of letters get slightly softened and blend into the background, preventing false negatives caused by the browser's text engine rendering a character a fraction of a pixel to the right.
failureThreshold: 0.003 and failureThresholdType: 'percent' — This is our main safety net, defining the total error tolerance. A value of 0.003 allows up to 0.3% of the entire snippet's area to change without failing the test.

The Final Code for Our test-runner.ts

Here is the optimized configuration we ultimately settled on:

import { TestRunnerConfig } from '@storybook/test-runner';
import { toMatchImageSnapshot } from 'jest-image-snapshot';

const config: TestRunnerConfig = {
  setup() {
    expect.extend({ toMatchImageSnapshot });
  },
  async postVisit(page, context) {
    await page.waitForSelector('#storybook-root');
    await page.waitForLoadState('networkidle', { timeout: 3000 }).catch(() => {
      console.warn(`Timeout waiting for networkidle in ${context.id}`);
    });

    await page.evaluate(() => document.fonts.ready);

    const snippetSelector = '[data-test="product-snippet"]';

    await page.evaluate((selector) => {
      const galleryContainers = document.querySelectorAll('[class*="gallery"]');
      galleryContainers.forEach((container) => {
        const images = container.querySelectorAll('img, source');
        images.forEach((img) => {
          if (img instanceof HTMLImageElement) {
            img.src = '';
            img.srcset = '';
          } else if (img instanceof HTMLSourceElement) {
            img.srcset = '';
          }
        });
      });

      const element = document.querySelector(selector) as HTMLElement;
      if (element) {
        element.style.padding = '16px';
        element.style.boxSizing = 'border-box';
        element.style.background = '#ffffff';
      }
    }, snippetSelector);

    await page.waitForTimeout(300);

    const elementHandle = await page.$(snippetSelector);

    if (elementHandle) {
      const screenshot = await elementHandle.screenshot({
        animations: 'disabled',
        caret: 'hide',
      });

      expect(screenshot).toMatchImageSnapshot({
        customSnapshotIdentifier: context.id,
        customSnapshotsDir: 'screenshots/reference',
        customDiffDir: 'screenshots/diff',
        customDiffConfig: { threshold: 0.1 },
        blur: 1,
        failureThreshold: 0.003,
        failureThresholdType: 'percent',
        allowSizeMismatch: true
      });
    }
  },
};

export default config;

The Bottom Line

Visual regression testing addressed a major pain point in our component library: catching UI breakages after global style or core component updates. Here is what we gained:

Confidence in Refactoring. Changes to global styles, design tokens, or core components no longer require manual QA sweeps across dozens of variations. We now instantly see how a modification impacts every single snippet type across all viewports. UI bugs are caught during development, long before making it to production. A developer just runs a single command, and the runner tests over 40 snippet variants in 60 to 90 seconds, flagging only real regressions.
Fewer Visual Regressions. Screenshot testing catches the kind of UI papercuts that easily slip through standard code reviews: broken margins, shifting elements, unexpected text wrapping, or hidden regressions caused by upgrading upstream design system packages. Even a tiny 1px misalignment is caught right away.
Fast and Stable Pipeline. We made the tests reliable enough for devs to actually trust the green checkmark. To pull this off, we completely cut out network-dependent images, tweaked diff thresholds to absorb flaky browser rendering noise, and capped the concurrency workers to keep Chromium running smoothly.

Conclusion

Screenshot testing doesn't replace functional or integration tests, but it is the perfect tool for locking down visual consistency. If you are maintaining a large UI library, automated visual testing is hands down one of the most effective ways to shield your application from UI regressions and ship updates with ultimate peace of mind.