DEV Community: Nikolay Makhonin

A rare case of recursive looping without loops or stack overflow

Nikolay Makhonin — Mon, 29 Dec 2025 04:14:57 +0000

Hanging is one of the trickiest bugs to debug. Knowing the possible causes helps you spot them faster.

Minimal case to reproduce the hang

Set N = 64, and this function will never finish. The number of calls will be 2^(N+1), while the maximum stack depth stays at just N.

let calls = 0
const N = 18
function func(state, visited) {
  calls++
  if (calls > 10_000_000) {
    throw new Error('calls: ' + calls)
  }
  if (visited.includes(state)) return

  const newVisited = [...visited, state]

  func((state + 1) % N, newVisited)
  func((state + 1) % N, newVisited)
}

func(0, [])
console.log('calls:', calls)

Why does this work without stack overflow?

func(0, [])
├── func(1, [0])
│   ├── func(2, [0,1])
│   │   └── ... depth grows to N,
│   │           all combinations of newVisited are iterated
│   └── func(2, [0,1]) — returns, depth DECREASES
└── func(1, [0])       — second call, stack already freed

Meanwhile, the Garbage Collector keeps removing previously created newVisited arrays.

The stack "breathes" — it reaches the maximum depth of N, then collapses back, then grows again. This is essentially traversing a huge tree that has small depth but enormous width.

This is not infinite recursion. But with N = 64, the number of calls will be 2^65 (approximately 10^19) — that would take thousands of years to complete, and the stack will never overflow.

Tailwind vs BEM - Part 2 (Architecture)

Nikolay Makhonin — Thu, 23 Nov 2023 04:49:33 +0000

The first article here

Engineering is not about tasting. You can't just list pros and cons, taste them, and choose what you like best. One of the main tasks of good architecture is to avoid pitfalls, and if you do step on them, to do so knowingly, with a clear understanding that it's going to hurt but it's the best choice among the alternatives. When choosing a tool that affects architecture, I want to clearly understand what pitfalls await me in the future, am I ready to deal with these pitfalls, is the client ready for it? The issue of pitfalls is much more acute than even the question of development speed and convenience. Initially, a project may develop quickly, but as it grows, it may turn out that small changes take unacceptably long, and work becomes more and more exhausting. People tend to count the volume of work only in terms of time spent, not considering how much mental effort is exerted during this time.

When thinking about good architecture, experience in creating and maintaining long-term projects is very important. Only such experience allows you to step on all the pitfalls and understand the mistakes built into the project's foundation. In this article, I'll share my pitfalls. If anyone has anything to add, please write in the comments. Let's analyze them all.

I refer to pitfalls as unexpected complexities in solving seemingly simple tasks, which significantly increase the time or mental resources required to complete them.

It's important to note that when writing this article, I relied solely on my extensive experience with Svelte. A couple of years ago, I tried to integrate BEM with React, and it didn’t work out, which surprised me a lot. There were no options to do this in such a way that style isolation worked, and you could change styles from the parent component without breaking all other components, and styles were in CSS, and classes in HTML could be indicated simply as text, exactly in the same way as in CSS. In Svelte, all this is easy, there you practically write normal HTML + CSS, then dilute it with logic, and Svelte does all the magic for flexible style isolation. Perhaps it’s impossible to use BEM in React in a human way, and Tailwind saves the situation with styles, but I don't have much experience in this.

1. Initial Data

1.1. Common development tools for all architectures:
1.1.1) PostCSS
1.1.2) Modern UI framework: React / Vue / Svelte / ...

1.2. Architectures:
1.2.1) Vanilla CSS + BEM
1.2.2) Tailwind (orthodox) with styles in HTML and without active use of @apply

1.3. Possible tasks:
1.3.1) design all pages from scratch
1.3.2) create several components with different internal logic, but with very similar style
1.3.3) create several components with the same logic, but with minor style changes
1.3.4) create several pages with minor changes in the styles of some elements
1.3.5) create theme designs with as many possibilities as possible for changing the styles of elements
1.3.6) pinpoint fixes/changes in layout
1.3.7) change the style of elements of a certain category

1.4. Possible changes in elements:
1.4.1) change all small margins, colors, fonts
1.4.2) hide a couple of elements
1.4.3) style some elements differently
1.4.4) change a gradient or picture

1.5. Influencing factors:
1.5.1) the entire project with strict guidelines
1.5.2) the entire project without strict guidelines
1.5.3) Pixel Perfect requirement
1.5.4) 1-2 developers on the project
1.5.5) several people or a large team on the project
1.5.6) simple one-page site or landing page
1.5.7) large site
1.5.8) fixed project with no future changes
1.5.9) unpredictability of development, i.e., you can't say in advance what changes and in which elements may occur. There can only be general predictions, like the absence of theme designs.

2. Analysis

We will look for optimal ways to solve tasks for all architectures, taking into account additional influencing factors.

2.1 Design all pages from scratch

If the entire project has strict guidelines, it's easier to work with Tailwind. If there are no strict guidelines, you can make them strict and approximate the design.
When designing from a Figma layout without strict guidelines, it’s easier to copy pure CSS than to match Tailwind classes by eye and memory.
Pixel Perfect is easier to do with vanilla CSS, as DevTools allows you to easily adjust sizes and margins and then copy the CSS into the code.
If several people are working on the project, using Tailwind means they don’t need to understand the common CSS classes of other developers. In this case, it's more difficult to change common classes, which will happen from time to time during development.

2.2 Create several components with different internal logic, but with very similar style

For Tailwind, you need to create components without common styles. This is easy to create but hard to change if there are many components.
With vanilla CSS, you can make common styles and reuse them in different components. These styles are easy to change at once for all components.

2.3 Create several components with the same logic, but with minor changes in style

In Tailwind, changes in styles need to be integrated into logic, changing classes in HTML depending on parameters. A component's parameter is like a modifier in BEM. I'm afraid to imagine what a component will turn into if it has many different modifiers, the changes introduced by which are scattered throughout the HTML.
Vanilla CSS handles this well. You can change the style of a component through parameters, but by replacing only one BEM class modifier for the container in the code. And set the style of the modifier separately in one place. In addition, vanilla CSS allows you to change the styles of nested components without changing the code of these components.
Many styles can be changed through CSS variables. Tailwind's capabilities here are limited. To precisely indicate which styles of which elements can be changed through variables, you will have to use vanilla CSS.

2.4 Create several pages with minor changes in the styles of some elements

In Tailwind, you will have to write classes with unique names for each changeable element and use vanilla CSS for their modification from the outside.
If you use BEM, then all element names are already written, so to create a new page with a slightly different style, you don't need to change the nested components. Just write CSS of changeable styles in one place in the root component of the page.

2.5 Create theme designs with as many possibilities as possible for changing the styles of elements

Tailwind gives limited possibilities in creating theme designs. If you change something, then everything on the page changes at once: all colors, all margins. It’s also problematic to implement CSS variables without vanilla CSS. You can only create utility classes with CSS variables globally, not for a specific component.
Vanilla CSS has huge possibilities both in using CSS variables and in pinpoint changes of any properties of elements. If BEM is used, it’s very easy to change the style of a separate element or elements of a certain kind located in a certain place. But to change all colors on the site or all margins, you have to pre-write all CSS variables and distribute them throughout the code. In Tailwind, all these variables are already written.

2.6 Pinpoint fixes/changes in layout

Tailwind elements are hard to find. You can’t just find out by the class attribute where the corresponding code is in the project. It’s even worse if there are several such places and you need to change them all. It’s also hard to understand what role a certain element plays in the code: is it a container, a wrapper, an independent block, etc. Refactoring is extremely difficult because of this. Miller's Law says that a person can simultaneously keep 5-7 entities in attention. To recognize the role of a certain element, a developer has to fill up his entire "attention wallet", as he needs to analyze all the classes of the element to understand its role. It’s even harder when there are several elements with one role in the code and you need to find them all.
BEM elements are very easy to find, of course, if BEM classes are written in CSS in the same form as in HTML. You just need to copy the class name and find it in the project. It’s very easy to find all places where this class is used. To change the style of several elements of the same kind, you just need to edit only one style, if, of course, some structure is maintained in the layout. And BEM forces the developer to think about the structure of the layout. It’s very easy to understand the role of an element by the name of the class. Refactoring such code is not difficult. Miller's "wallet" can accommodate several elements at once. It’s also easy to find all elements with a certain role in the file by search.

2.7 Change the style of elements of a certain category

It’s very hard to change the style of elements of a certain category in Tailwind layout, as Tailwind doesn’t imply thoughtful layout structuring. No structure - search for everything manually. If there are many elements, you will have to search for each manually.
BEM forces you to think about the structure of the layout. Therefore, it’s easy to search for elements of a certain category with a simple search by class names.

3. Preliminary Conclusions

3.1) Design all pages from scratch

No strict guidelines + Pixel Perfect => strictly vanilla CSS
There are strict guidelines => Tailwind is more convenient

3.2) Create several components with different internal logic, but with very similar style

There's not much difference

3.3) Create several components with the same logic, but with minor changes in style

Tailwind has strong limitations here and forces the style of a component to mix with other logic
Vanilla CSS is very flexible in this respect

3.4) Create several pages with minor changes in the styles of some elements

Tailwind can’t be used, only vanilla CSS

3.5) Create theme designs with as many possibilities as possible for changing the styles of elements

Tailwind can be used for theme designs, but with significant limitations
Vanilla CSS has almost no limitations on theme designs

3.6) Pinpoint fixes/changes in layout

Tailwind is difficult to read and edit.
Using BEM and naming all elements makes it very easy to find them, and if you don’t write Tailwind classes in HTML, navigating the code is even easier.

3.7) Change the style of elements of a certain category

It’s very difficult to do this in Tailwind layout, especially if there are many elements in different parts of the site.
BEM allows you to easily find all elements with a simple search by class names.

4. My Conclusions

In terms of development flexibility, Tailwind is significantly inferior to vanilla CSS + BEM. Some believe that BEM and Tailwind do not contradict each other. Yes, they can technically be mixed together, but they are different architectures. Mixing them together, we get both the pluses and the minuses of both architectures. Mixing different approaches can lead to the code turning into a mess. Such a mixed architecture must be well thought out. But I haven't seen a SINGLE article on Tailwind architecture, not to mention Tailwind + BEM architecture. Meanwhile, there are plenty of articles on vanilla CSS architecture.
So far, I don't understand how to solve tasks 4, 5, 6, 7 on Tailwind. These Tailwind minuses are critical for me, but the minuses of BEM are not.

Write if you have something to say. I'm especially interested in how you solve the tasks I described here using Tailwind. Maybe, I still don't know some Tailwind development secrets.

Tailwind vs BEM - Part 1 (Performance Comparison)

Nikolay Makhonin — Wed, 15 Nov 2023 05:59:26 +0000

The second article here

In these two articles, I will be comparing TailwindCSS with pure CSS + BEM. The goal is to understand which is the better solution for good application architecture. This is not a matter of preference, as this choice will significantly impact the later stages of development and must be very well justified. I'll start with comparing performance. Tailwind allows for a substantial reduction in the final CSS size, thereby speeding up page display time. However, this only works if Tailwind classes are written directly in HTML code, not as @apply in CSS. Tailwind reduces CSS size but increases HTML size. Let's calculate the difference, taking into account HTML. We'll compare pure Tailwind with pure CSS + BEM.

Calculations

For each Tailwind class - one property. For each HTML element - one and a half BEM classes (if considering modifiers).

lt - average length of a Tailwind class
lc - average length of a BEM class
lp - average length of a CSS property
Pu - number of unique properties
P - average number of properties per element
C - average number of BEM classes per element
E - number of elements
Eu - number of unique elements

CSS structure for Tailwind:
.lt * Pu {
  lp * Pu;
}

CSS structure for BEM:
.lc * Eu * C { 
  lp * Eu * P;
}

HTML structure for Tailwind:
<div class="lt * E * P">

HTML structure for BEM:
<div class="lc * E * C">

Calculating total size:
Tailwind: lt * Pu + lp * Pu + lt * E * P
BEM: lc * Eu * C + lp * Eu * P + lc * E * C

Function for browser experiments:

function calc({lt, lc, lp, Pu, P, C, E, Eu}) {
  const Tailwind = lt * Pu + lp * Pu + lt * E * P
  const BEM = lc * Eu * C + lp * Eu * P + lc * E * C
  return {
    Tailwind,
    BEM,
    diff: Tailwind / BEM
  }
}

For the analysis, I took the main page of GitHub after login. Here are some tools for analysis:

// Counting elements on the site:
console.log(Array.from(document.querySelectorAll('[class]')).length)

// Counting unique (by class) elements on the site:
console.log(Array.from(document.querySelectorAll('[class]'))
  .reduce((a, o) => {
    a.add(Array.from(o.classList.values()).sort().join(' '))
    return a
  }, new Set()).size)

Page: https://github.com/
3164 elements
502 unique elements
12101 all CSS properties
3956 unique CSS properties
404088 total length of all CSS properties
163733 total length of unique CSS properties
33 average length of all CSS properties
41 average length of unique CSS properties
24 properties per element

calc({
  lt:  10, // average length of a Tailwind class
  lc:  35, // average length of a BEM class
  lp:  35, // average length of a CSS property
  Pu:  3956, // number of unique properties
  P:  24, // average number of properties per element
  C:  1.5, // average number of BEM classes per element
  E:  3164, // number of elements
  Eu:  502, // number of unique elements
})

// Tailwind: 937380,
// BEM: 614145,
// Tailwind / BEM: 1.5263170749578682

Tailwind size is 1.5 times larger

Optimization

For BEM, we could optimize CSS and for each property list all classes with that property in the selector. Then the total length of all properties should decrease:

.lc * Eu * C * P { 
  lp * Eu;
}

The formula for BEM will be as follows:

lc * Eu * C * P + lp * Eu + lc * E * C

Let's consider the same GitHub, but with class name obfuscation and optimization:

function calc({lt, lc, lp, Pu, P, C, E, Eu}) {
  const Tailwind = lt * Pu + lp * Pu + lt * E * P
  const BEM = lc * Eu * C * P + lp * Eu + lc * E * C
  return {
    Tailwind,
    BEM,
    diff: Tailwind / BEM
  }
}

calc({
  lt:  5, // average length of a Tailwind class (with obfuscation)
  lc:  5, // average length of a BEM class (with obfuscation)
  lp:  35, // average length of a CSS property
  Pu:  3956, // number of unique properties
  P:  24, // average number of properties per element
  C:  1.5, // average number of BEM classes per element
  E:  3164, // number of elements
  Eu:  502, // number of unique elements
});

// Tailwind: 537920
// BEM: 131660
// Tailwind / BEM: 4.085675224061978

With optimization and obfuscation, Tailwind's size is 4 times larger than BEM's.

But, unfortunately, such optimization is not possible. This example illustrates why:

<style>
.a {
  color: red;
}
.b {
  color: blue;
}
.c {
  color: red;
}
</style>

<div class="a b"></div> <!-- Blue -->
<div class="b c"></div> <!-- Red -->

=========================

<style>
.a, .c {
  color: red;
}
.b {
  color: blue;
}
</style>

<div class="a b"></div> <!-- Blue -->
<div class="b c"></div> <!-- Blue -->

=========================

<style>
.b {
  color: blue;
}
.a, .c {
  color: red;
}
</style>

<div class="a b"></div> <!-- Red -->
<div class="b c"></div> <!-- Red -->

But class name obfuscation is possible. Let's consider the case without impossible optimization, but with obfuscation.

calc({
  lt:  5, // average length of a Tailwind class (with obfuscation)
  lc:  5, // average length of a BEM class (with obfuscation)
  lp:  35, // average length of a CSS property
  Pu:  3956, // number of unique properties
  P:  24, // average number of properties per element
  C:  1.5, // average number of BEM classes per element
  E:  3164, // number of elements
  Eu:  502, // number of unique elements
});

// Tailwind: 537920,
// BEM: 449175,
// Tailwind / BEM: 1.1975733288807258

Moreover, the size of a Tailwind class significantly impacts the total HTML/CSS size more than the size of a BEM class. This is understandable since the total number of elements on a page is 7 times more than the unique ones.

Is the size of CSS/HTML important, and to what extent?

How big can CSS actually be? With BEM, it's not hard to get 3 megabytes. But gzip compresses 3MB to just 60kB. Of course, after downloading, the browser still needs to unpack the CSS and then analyze it, which takes some time. According to my tests, it's 0.5-1 second on desktop. On mobile devices, this time should be significantly longer. Fast loading and quick analysis of CSS/HTML are more important than images or even scripts. Scripts are given a small head start because the user does not interact with the page immediately. Without HTML/CSS, the page won't even display correctly, and image loading won't start.

Script for analyzing a specific site

Run this script in the console for any site, and you will know the difference in sizes between Tailwind and BEM.
Preferably run it with browser protection disabled so that the script takes into account all styles loaded from CDNs:

chrome.exe --disable-web-security --user-data-dir="C:/Temp/ChromeDevSession"

The algorithm does not consider cascading styles, i.e., all that contain the symbols " >+~". It's very difficult to account for them, so it's better to just choose well-coded sites with little cascading. The algorithm also assumes that for BEM, each unique element has its unique style sheet. Therefore, in reality, the CSS size for BEM will be less than the algorithm estimates.
The calculations do not consider the current method of class naming. Only the quality of design and its coding affects the result. The Utility First approach forces more quality design and coding, i.e., adhering to certain predefined style sets. Therefore, probably sites coded with Tailwind show better results in terms of HTML/CSS size.
The script takes about a minute to run due to the element.matches(rule.selectorText) function. I don't know how to optimize this.

function walkRules(rules, callback, mediaRule) {
  Array.from(rules).forEach(rule => {
    if (rule instanceof CSSStyleRule) {
      callback(rule, mediaRule)
    } else if (rule instanceof CSSMediaRule) {
      walkRules(rule.cssRules, callback, rule)
    }
  })
}

function getRules() {
  const rules = []
  Array.from(document.styleSheets).forEach(sheet => {
    // ignore cross-origin stylesheets
    try {
      sheet.cssRules
    } catch (err) {
      console.warn(`Stylesheet ${sheet.href} is not accessible`)
      return
    }

    walkRules(sheet.cssRules, (rule, mediaRule) => {
      if (
        !/\.[\w-]/.test(rule.selectorText) || // only class selectors
        /[ >+~]/.test(rule.selectorText) // exclude cascading selectors
      ) {
        return
      }
      const style = {}
      for (let i = 0; i < rule.style.length; i++) {
        const key = rule.style[i]
        style[key] = rule.style.getPropertyValue(key).trim().toLowerCase()
      }
      rules.push({ rule, mediaRule, style })
    })
  })

  return rules
}

function getElements(rules) {
  const allElements = Array.from(document.querySelectorAll('[class]'))
  const filteredElements = []

  const time0 = Date.now()
  console.log('getElements START')

  let logTime = Date.now()
  const nonVisualTags = ['SCRIPT', 'STYLE', 'LINK', 'META', 'TITLE', 'NOSCRIPT']
  allElements.forEach((element, i) => {
    if (nonVisualTags.includes(element.tagName)) {
      return
    }
    const elementRules = rules.filter(({ rule }) => {
      return element.matches(rule.selectorText)
    })
    if (elementRules.length === 0) {
      return
    }
    filteredElements.push({ element, rules: elementRules })
    if (Date.now() - logTime > 1000) {
      console.log(
        `getElements: ${((i / allElements.length) * 100).toFixed(2)}% ${
          (Date.now() - time0) / 1000
        }s`,
      )
      logTime = Date.now()
    }
  })

  console.log('getElements END', performance.now() - time0)

  return filteredElements
}

function calcStat() {
  const rules = getRules()
  const elements = getElements(rules)

  const uniqueElements = Array.from(
    elements
      .reduce((a, e) => {
        const key = e.rules.map(({ rule }) => rule.selectorText).join(' ')
        if (!a.has(key)) {
          a.set(key, e)
        }
        return a
      }, new Map())
      .values(),
  )

  const stat = {
    total: {
      html: {
        elementsCount: 0,
      },
      css: {
        selectorCount: 0,
        mediaCount: 0,
        mediaSize: 0,
        styleSize: 0,
        propCount: 0,
      },
    },
    tailwind: {
      html: {
        classCount: 0,
      },
      css: {
        selectorCount: 0,
        styleSize: 0,
        propCount: 0,
      },
    },
    bem: {
      html: {
        elementsCount: 0,
      },
      css: {
        selectorCount: 0,
        mediaCount: 0,
        mediaSize: 0,
        styleSize: 0,
        propCount: 0,
      },
    },
  }

  const uniqueProps = uniqueElements.reduce((a, e) => {
    e.rules.forEach(({ style }) => {
      Object.keys(style).forEach(key => {
        a.add(key + ':' + style[key] + ';')
      })
    })
    return a
  }, new Set())

  // Total
  stat.total.html.elementsCount = elements.length
  rules.forEach(({ rule, mediaRule, style }) => {
    Object.keys(style).forEach(key => {
      stat.total.css.propCount++
      const prop = key + ':' + style[key] + ';'
      stat.total.css.styleSize += prop.length
    })
    stat.total.css.selectorCount++
    if (mediaRule) {
      stat.total.css.mediaCount++
      stat.total.css.mediaSize += mediaRule.media.mediaText.trim().length
    }
  })

  // Tailwind
  stat.tailwind.css.selectorCount = uniqueProps.size
  stat.tailwind.css.propCount = uniqueProps.size
  uniqueProps.forEach(prop => {
    stat.tailwind.css.styleSize += prop.length
  })
  elements.forEach(({ element, rules }) => {
    const elemUniqueProps = new Set()
    rules.forEach(({ rule, mediaRule, style }) => {
      Object.keys(style).forEach(key => {
        elemUniqueProps.add(
          key +
            ':' +
            style[key] +
            ';' +
            (mediaRule?.media?.mediaText?.trim() || ''),
        )
      })
    })
    if (!elemUniqueProps.size) {
      debugger
    }
    stat.tailwind.html.classCount += elemUniqueProps.size
  })

  // BEM
  stat.bem.html.elementsCount = elements.length
  stat.bem.css.selectorCount = uniqueElements.length
  uniqueElements.forEach(({ element, rules }) => {
    const uniqueMedia = new Set()
    rules.forEach(({ rule, mediaRule, style }) => {
      const mediaText = mediaRule?.media?.mediaText?.trim() || ''
      if (mediaText) {
        uniqueMedia.add(mediaText)
      }
      Object.keys(style).forEach(key => {
        const prop = key + ':' + style[key] + ';'
        stat.bem.css.styleSize += prop.length
        stat.bem.css.propCount++
      })
    })
    stat.bem.css.mediaCount += uniqueMedia.size
    uniqueMedia.forEach(media => {
      stat.bem.css.mediaSize += media.length
    })
  })

  return stat
}

var stat = calcStat()
console.log(JSON.stringify(stat, null, 2))

function tailwindVsBem({
  stat,
  bemClassSize,
  bemClassesPerElement,
  tailwindClassSize,
}) {
  const bemCssSize =
    stat.bem.css.styleSize +
    stat.bem.css.mediaSize +
    stat.bem.css.selectorCount * bemClassSize +
    stat.bem.css.mediaCount * bemClassSize
  const bemHtmlSize =
    stat.bem.html.elementsCount * bemClassSize * bemClassesPerElement

  const tailwindCssSize =
    stat.tailwind.css.styleSize +
    stat.tailwind.css.selectorCount * tailwindClassSize
  const tailwindHtmlSize = stat.tailwind.html.classCount * tailwindClassSize

  const bemSize = bemCssSize + bemHtmlSize
  const tailwindSize = tailwindCssSize + tailwindHtmlSize
  const diff = tailwindSize / bemSize

  console.log(`
${document.location.href}
Tailwind = ${tailwindCssSize} (CSS) + ${tailwindHtmlSize} (HTML) = ${tailwindSize}
BEM = ${bemCssSize} (CSS) + ${bemHtmlSize} (HTML) = ${bemSize}
Tailwind / BEM = ${diff}
`)
}

tailwindVsBem({
  stat,
  bemClassSize: 35,
  bemClassesPerElement: 1.5,
  tailwindClassSize: 10,
})

Results

Pages with pure CSS:

https://www.youtube.com
Tailwind = 38936 (CSS) + 347670 (HTML) = 386606
BEM = 129424 (CSS) + 202230 (HTML) = 331654
Tailwind / BEM = 1.1656907499984923

https://dzen.ru/
Tailwind = 19449 (CSS) + 165240 (HTML) = 184689
BEM = 80186 (CSS) + 75232.5 (HTML) = 155418.5
Tailwind / BEM = 1.1883334352088073


https://habr.com/ru/articles/774524/
Tailwind = 1173 (CSS) + 370 (HTML) = 1543
BEM = 946 (CSS) + 157.5 (HTML) = 1103.5
Tailwind / BEM = 1.3982782057091074

Pages with Tailwind or another Utility First approach:

https://github.com
(Микс чистого CSS и Tailwind)
Tailwind = 25103 (CSS) + 482850 (HTML) = 507953
BEM = 155295 (CSS) + 155190 (HTML) = 310485
Tailwind / BEM = 1.6359985184469459

https://stackoverflow.com/questions/588004/is-floating-point-math-broken/588014
Tailwind = 25317 (CSS) + 449170 (HTML) = 474487
BEM = 132373 (CSS) + 140437.5 (HTML) = 272810.5
Tailwind / BEM = 1.7392549040451155

https://www.facebook.com/random_user
Tailwind = 42286 (CSS) + 400300 (HTML) = 442586
BEM = 378248 (CSS) + 170415 (HTML) = 548663
Tailwind / BEM = 0.8066627419745819

https://tailwindcss.com
Tailwind = 22325 (CSS) + 159330 (HTML) = 181655
BEM = 120739 (CSS) + 121800 (HTML) = 242539
Tailwind / BEM = 0.7489723302231805

https://www.shopify.com
Tailwind = 25053 (CSS) + 102080 (HTML) = 127133
BEM = 179634 (CSS) + 78750 (HTML) = 258384
Tailwind / BEM = 0.4920312403244783

https://www.netflix.com/tudum/top10/
Tailwind = 13288 (CSS) + 80360 (HTML) = 93648
BEM = 48737 (CSS) + 60375 (HTML) = 109112
Tailwind / BEM = 0.8582740670137107

https://io.google/2022/
Tailwind = 11124 (CSS) + 27390 (HTML) = 38514
BEM = 43079 (CSS) + 21682.5 (HTML) = 64761.5
Tailwind / BEM = 0.5947051874956572

https://dotnet.microsoft.com/en-us/
Tailwind = 15199 (CSS) + 27520 (HTML) = 42719
BEM = 49361 (CSS) + 13860 (HTML) = 63221
Tailwind / BEM = 0.6757090207367805

Conclusions

Tailwind reduces HTML/CSS size only if the entire web page (both design and coding) is designed using the Utility First approach. Of course, this must be agreed upon by everyone: designer, coder, and client. With very good design and coding, you can achieve a size twice smaller than with BEM coding.
If there is an arbitrary layout and you need to code in Pixel Perfect, then Tailwind is more likely to increase the size by 1.5 times. Also, Tailwind won't help if the page has a lot of repetitive elements (like the StackOverflow site, for example).

P.S.

Tailwind lies about phenomenal performance improvements. (In this article, it only considers the size of the files for download). It writes that Netflix has only 10KB of CSS, but doesn't mention the increased size of HTML. The total length of all "class" attributes equals 87231. This is a bit more than what I calculated here. In fact, Tailwind only saved 15% of the total size of uncompressed HTML+CSS.

Here's a script for calculating the total size of classes in HTML:

Array.from(document.querySelectorAll('[class]'))
  .reduce((a, o) => {
    a += o.getAttribute('class').length
    return a
  }, 0)

I would be happy to hear any criticism, remarks, your personal experience, ...