DEV Community: Marat Sabitov

CSS Art Challenge: I do love Chicken Pilaf!

Marat Sabitov — Wed, 12 Aug 2026 17:05:32 +0000

This is a submission for Frontend Challenge - Comfort Food Edition, CSS Art.

Inspiration

When I saw the title of the challenge, I immediately knew — it was time to make chicken pilaf. This is one of my favorite dishes that I can feed all my loved ones with.

I also decided to experiment with CSS in this project — writing styles in a way I don't usually do. For example, I didn't use class or data attributes selectors. I also forbade myself from using pixels — so that I could use only relative sizes.

The result is a simple website that will tell you how to cook this wonderful dish.

Demo

msabitov.github.io

Here is the StackBlitz preview, also you can view the site on GitHub Pages.

And here is a link to the source code.

The project is licensed under the Apache License 2.0.

Journey

The first thing I did was imagine a world without JavaScript. It means, we don't have React, Vue, or Svelte — possibly we write websites in a notebook and render HTML in our heads. And when we want to share a website, we tear out a sheet of paper from a notebook, fold it into an airplane and launch it to the recipient ✈️.

But seriously, manually setting up styles without any CSS-in-JS, Tailwind or Material UI feels like true creativity. For me, it's like painting or making wood crafts — you have to work on every detail step by step, evaluate it from afar, and start a new iteration.

So, I freed myself from the JavaScript craving and reached Zen 🧘‍♂️. After that, I started searching for a suitable palette and fonts — this should create some emotional background. Then I began thinking about the site's structure-one that would be free of stock images and ads. I envisioned the site as a small game world that should feel alive-with a little interactivity, interesting text, and a clear goal.

The only JavaScript code I inlined into the HTML is related to checking all the checkboxes. This is more of a UX issue – I'd be too lazy to click through all the recipe steps, so I decided to give the user a shortcut — perhaps you're a professional chef who knows the recipe perfectly.

As a result I made 4 sections:

Intro
Ingredients
Recipe
Dish

The ingredients section took me the longest — I decided to write full-fledged CSS components, and in the end I essentially got one hero component, to which parameters are passed via CSS variables and from these parameters come different ingredients. I find this experience most valuable — it shows how to use familiar patterns in an unfamiliar environment without props, state, or lifecycle hooks. I wish attr() function for custom attributes would finally be supported in all browsers—then CSS components would be revealed from a new side.

When this happens, I will rewrite the site to make sure once again that CSS is more powerful than many think.

P.S. When creating the site, I decided to hide all sorts of references within it — to people, games, and more. I wonder how many you can find?😏

EffCSS hydration: server work, client trust, zero waste

Marat Sabitov — Sat, 08 Aug 2026 10:27:17 +0000

Currently the CSS-in-JS ecosystem is split into two camps:

Runtime CSS-in-JS (Emotion, styled-components) keeps JS on the client for full dynamism. At hydration it reuses the SSR-injected styles, so the CSSOM isn't duplicated but JS code still runs.
Zero-runtime (Linaria, Vanilla Extract, Panda CSS) removes runtime entirely: styles become static .css files at build time. The price is equally radical — dynamic styles are limited to CSS-native abilities such as Custom Properties, and you need a build plugin.

Both ask you to accept a trade-off: full dynamism or perfomative runtime. But I think it is an effect of the deeper problem.

I suppose we need to look at the deeper thing: every CSS-in-JS approach answers the same question: how do you map a piece of logic to a CSS selector? Runtime and zero-runtime give two different answers, and both tie the style to its identity. Understanding exactly what they tie together is the key to the third path.

Runtime Emotion CSS: the selector is a hash of the style

To keep the comparison fair, this article picks the vanilla runtime, @emotion/css — the fairest opponent, because it is already framework-agnostic: its css() is a plain function with no React and no render. The catch is how it names a style. On every call, css() runs the whole pipeline in @emotion/serialize, invoked from the core css() in @emotion/css — it evaluates the interpolations, assembles the CSS string and hashes it, returning <cacheKey>-<hash(styles)>:

const buttonClass = css`
  color: white;
  background-color: ${variant === 'primary' ? '#2192a7' : '#9d41ab'};
`;

Therefore, the classname is a function of the CSS text itself — the identity of the style is welded to its bytes. There is no name without the string. The only part that is cached is the DOM write: insertStyles skips re-insertion for a classname it has already seen, so the CSSOM isn't duplicated and the server work isn't wasted — but it is re-done. Because the selector derives from the string, retrieving an existing selector means rebuilding and re-hashing it. The coupling forces the recomputation.

Zero-runtime Vanilla Extract: the selector is a build-time constant

Vanilla Extract compiles a styles into static .css classes:

export const btn = style({
  height: '1.5rem',
  borderRadius: '0.25rem',
  color: 'white',
});
export const btnBg = styleVariants({
  primary: { backgroundColor: '#2192a7' },
  secondary: { backgroundColor: '#9d41ab' },
});

Here the coupling goes the other way: the selector and the CSS are fixed together at build time, and both server and client use the same constant classnames. No generator ever runs — no recomputation, but also no freedom: the set of selectors is closed the moment you compile. style, styleVariants, etc. all come from the Vanilla Extract docs.

If you need a dynamic value you fall back to CSS variables (var(--btn-bg)) or to the Dynamic package, which adds a JS runtime and breaks the "zero-runtime" label. Fully static design systems — finite variants, known tokens — fit zero-runtime perfectly. But what if you need a style that wasn't enumerated at build time?

The pattern: style and selector are binded

Now we can see some patterns. Both tools bind the selector to a specific amount of "styles":

Emotion binds selector = hash(cssText). The selector is computed from the style. You cannot extract a selector without re-executing the generation.
Vanilla Extract binds selector = name fixed at build. The selector is frozen together with the style. You never recompute, but you also never go off the precompiled list.

Both treat the selector as a derived value of the style. What if we make it an independent artifact? What if the mapping "logical name → selector" exists on its own, serializable, restorable and dynamic — while the CSS it points to is a separate, lazily generated thing?

That is exactly what EffCSS does. And once you have that split, styles' hydration becomes a nice bonus to the developer's experience.

EffCSS: style and selector are decoupled

EffCSS takes a slightly different approach. It doesn't strip styles at runtime like Vanilla Extract, nor does it run generator functions on the client like @emotion/css. It decouples the selector from the CSS it points to. The selector is generated from a namespace/ordinal, not from the CSS string, and the resulting mapping "logical name → minified selector" is kept as a separate dictionary — an isolated artifact:

import { classNames } from 'effcss';

export type TComponents = {
  btn: {
    bg: 'primary' | 'secondary';
  };
};

export const clsResolver = classNames<TComponents>((selectors) => {
  const { btn } = selectors;
  return {
    [btn]: {
      height: '1.5rem',
      borderRadius: '0.25rem',
      color: 'white',
    },
    [btn.bg.primary]: { backgroundColor: '#2192a7' },
    [btn.bg.secondary]: { backgroundColor: '#9d41ab' }
  };
});

Because the selector is decoupled, the dictionary and the styles are two independently serializable artifacts. The library remembers everything it generated, so extracting them on the server side is a trivial task:

import { serialize, serializeMeta } from 'effcss';

// After rendering all components:
const html = renderToString(<App />);

// EffCSS styles
const css = serialize();
// <style data-effcss-key="f0">
//   .f0_1 { height: 1.5rem; ... }
// </style>

// EffCSS metadata — the independent selector dictionary
const meta = serializeMeta();
// <script type="application/json" data-effcss-key="f0">
//   {"btn":"f0_1","btn_bg_primary":"f0_2", ... }
// </script>

// add all to hydrate on the client side
const head = css + meta;

Serialization on the server side is described in more detail in the documentation.

Notice the two payloads. serialize() ships the CSS itself. serializeMeta() ships the selector dictionary — the mapping from logical names to selectors, restored later without re-executing any generator. These are independent, and that independence is the whole point.

Hydration is the payoff of the split

Because styles and selectors travel separately, hydration becomes a trivial lookup instead of a recomputation. What happens on the client:

When the HTML loads, the browser parses the <style> into CSSOM - standard behavior.
The first time you call clsResolver({ btn: { bg: 'primary' }}), EffCSS looks for a <style[data-effcss-key]> element with server-generated CSS.
If found, it skips CSS creation.
It finds the <script> with the meta dictionary and restores the selector mapping without calling the generator function.
Then, using the dictionary, it simply computes the required selectors.

The key idea: EffCSS sees ready-made styles and metadata and reuses them. The generators are not re-run, because the generator's output — the selector dictionary — was shipped alongside. All that remains on the client is a dictionary lookup and, when you actually need a selector, a cheap resolution. Any combination of selectors from the dictionary can be used on the client.

No more style recomputation, but still full dynamism

This split stands EffCSS out in comparison to each camp:

To runtime: @emotion/css re-run every interpolation and re-hash the string to get back an existing name. EffCSS doesn't have to: the selector was already a separate artifact on the server, so the client just restores the dictionary and reads it out.
To zero-runtime: Vanilla Extract avoids recomputation by freezing the selector at build time — and with it, the whole set of styles. EffCSS selectors can be computed in new combinations. You unlock serverside-computed styles for free, and full runtime dynamism for whatever wasn't there.

So the unique feature of EffCSS hydration is that generators do not need to run again at all: we resolve selectors from a restored dictionary and the dictionary contains only what is implemented in styles.

Same benefit for CSR

I thought it was unfair that client-side rendering couldn't take full advantage of EffCSS, so I wrote a plugin for Viute. With vite-plugin-effcss, for CSR the generated CSS and metadata are injected into the HTML at both dev and build time. Client-side rendered apps get the same hydration behaviour without changing your application — just add the plugin to the Vite config:

// vite.config.ts
import { defineConfig } from 'vite';
import react from '@vitejs/plugin-react';
import effcss from 'vite-plugin-effcss';

export default defineConfig({
  plugins: [react(), effcss()],
});

The use of the plugin is described in detail in the documentation.

Key difference

The foundation — how each camp binds a style to its selector — determines everything else:

	@emotion/css (runtime)	Vanilla Extract (zero-runtime)	EffCSS
Selector identity	Hash of the CSS text	Frozen constant from build	Independent dictionary entry (namespace/ordinal)
Style ↔ selector	Welded: name needs the string	Welded: name frozen with styles	Decoupled
Server CSS → client	Rebuilt, same `<style>` reused	Static `.css` file	Same `<style>`, reused
Generator on client	Re-runs on every `css()` call	Never runs	Only for new styles
Selector resolution	Re-serializes + re-hashes on every call	Build-time only	Restored from meta dict
Dynamic styles	Full support at runtime	CSS vars or special runtime package	Full support
CSR hydration	Always runtime	Always static	Via `vite-plugin-effcss`
SSR extraction	Manual / `@emotion/server`	Build-time tooling	`serialize()` + `serializeMeta()`

Conclusion

Runtime CSS-in-JS computes a selector from the style and pays for it by recomputing on the client. Zero-runtime CSS-in-JS freezes the selector with the style and pays for it by closing the set of styles. Both treat the selector as a binded value of CSS.

EffCSS makes the selector an independent artifact (that's why I call EffCSS "contract-first library"). Styles and the selector dictionary are serialized once and restored separately: since they are ready, nothing needs to be reconstructed, only selectors should be computed from a dictionary. So the hydration works similarly and predictably for both CSR and SSR.

Enjoy your Frontend Development!

EffCSS v5: Self-Confident CSS-in-TS for Modern Frontend

Marat Sabitov — Wed, 08 Jul 2026 05:00:00 +0000

Docs
GitHub
NPM

What Is EffCSS?

EffCSS is a zero-dependency, framework-agnostic CSS-in-TS library that leverages native browser APIs (CSSStyleSheet, adoptedStyleSheets) instead of runtime injection or build plugins. Version 5 is a complete rethink that moves away from the useStyleProvider / TStyleSheetMaker pattern of v4 toward standalone utility functions. The new version gets rid of unnecessary abstractions in favor of a simple API.

Core API in v5.3.0

The library exports a small set of core at-rules utils:

variable and variables create @property rules,
animation and animations create @keyframes rules,
layer and layers create @layer rules,
container and containers create @container rules,
font and fonts creates @font-face rules.

They can be used as follows:

import {
  variable, variables,
  animation, animations,
  layer, layers,
  container, containers,
  font, fonts
} from 'effcss';

// variables
const singleVariable = variable('10px');
const multipleVariables = variable({
    primary: {
        syntax: 'color',
        inherits: false,
        initialValue: '#2192a7'
    },
    secondary: 'black'
});
const variableStyles = {
    // override value
    [singleVariable]: '12px',
    // use value
    background: multipleVariables.primary(),
    // use value with fallback
    color: multipleVariables.secondary('black')
};

// animations
const singleAnimation = animation({
    from: {
        transform: 'rotate(0deg)',
    },
    to: {
        transform: 'rotate(360deg)',
    },
});
const multipleAnimations = animations({
    simple: {
        '50%': {
            visibility: 'hidden'
        }
    },
    smooth: {
        '0%': {
            opacity: 1
        },
        '50%': {
            opacity: 0
        },
        '100%': {
            opacity: 1
        }
    }
});
const animationStyles = {
    '.spin': {
        animation: `200ms ${singleAnimation}`
    }
    '.blink': {
        animationName: multipleAnimations.smooth,
        animationDuration: '3s'
    }
};

// layers
const singleLayer = layer();
const multipleLayers = layers(['theme', 'layout', 'utilities']);
const layerStyles = {
    [singleLayer]: {
        button: {
            border: 'none'
        }
    }
    [multipleLayers.theme]: {
        body: {
            background: 'white'
        }
    }
};

// containers
const singleContainer = container();
const multipleContainers = containers({
    normal: '',
    inline: 'inline-size',
    scrollState: 'size scroll-state'
});
const containerStyles = {
    '.container-1': {
        container: singleContainer()
    },
    [singleContainer + ' (max-width: 768px)']: {
        '.offset-s': {
            width: '8px'
        }
    },
    '.container-2': {
        container: multipleContainers.inline()
    },
    [multipleContainers.inline + ' (max-width: 768px)']: {
        '.offset-s': {
            width: '4px'
        }
    }
};

// fonts
const singleFont = font({
    src: `url("https://mdn.github.io/shared-assets/fonts/FiraSans-Regular.woff2")`,
    genericName: 'sans-serif'
});
const multipleFonts = fonts({
    primary: {
        src: `url("/fonts/roboto-regular.woff2") format("woff2"), url("/fonts/roboto-regular.woff") format("woff")`,
        weight: 400,
        style: 'normal',
        display: 'swap'
    },
    secondary: {
        src: `url("https://mdn.github.io/shared-assets/fonts/FiraSans-Regular.woff2")`
    }
});
const fontStyles = {
    body: {
        fontFamily: globalFonts.first()
    },
    '.font-primary': {
        // secondary as fallback
        fontFamily: multipleContainers.primary(multipleContainers.secondary)
    }
};

Besides at-rules, you can create an arbitrary CSS rules with className or attribute - they just return selectors of different types:

import { className, attribute } from 'effcss';

// returns string
const cls = className({
    padding: '0.5rem',
    '&:focus': {
        borderBottom: '4px solid grey'
    }
});
// returns object
const attr = attribute({
    margin: 'auto',
    '&:hover': {
        outline: '2px solid black',
        '.child': {
            background: 'grey'
        }
    }
});

export const Component = () => {
    return <div {...attr} className={cls}>
        ...
    </div>
};

In addition, you can create entire stylesheets using the classNames, attributes and customStyles utilities. The first two implement the contract-first approach, let's look at this approach in more detail.

Contract-first approach

1. Declare a Type Contract

You describe your design system as a TypeScript type. This becomes the source of truth for both implementation and consumption:

type Components = {
  rounded: true;
  h: 'full' | 'half';
  card: {
    bg: 'primary' | 'secondary';
    disabled: boolean;
  };
  spinner: {};
};

type Utils = {
  w: 's' | 'm' | 'l';
  spacing: 0 | 1 | 2;
  blink: true;
};

2. Implement with `attributes` or `classNames`

attributes generates scoped data-attribute selectors (returns a props object for spread):

const styleComponents = attributes<Components>((selectors) => {
  const { rounded, card, spinner } = selectors;

  return {
    [rounded.true]: { borderRadius: '50%' },
    [spinner]: { animation: `${spinAnimation} infinite 6s linear` },
    [card]: { display: 'flex', justifyContent: 'center' },
    [card.bg.primary]: { background: colors.primary() },
    [card.bg.secondary]: { background: colors.secondary('cyan') },
  };
});

classNames generates class selectors (returns a className string):

const styleUtils = classNames<Utils>((selectors) => {
  const { w, blink } = selectors;

  return {
    [blink.true]: { animation: `${blinkAnimations.smooth} 2s infinite` },
    [w.s]: { width: widthVars.s() },
    [w.m]: { width: widthVars.m() },
    [w.l]: { width: widthVars.l() },
  };
});

3. Apply

const cardAttrs = styleComponents({ card: { bg: 'primary', disabled: true } });
const utilsCls = styleUtils({ w: 'm' });

export const App = () => (
  <div {...cardAttrs} className={utilsCls}>...</div>
);

Other utils

There are also other specialized utilities:

stylesheet returns the created stylesheet by resolver,
configure affects style generation if it is called before the first stylesheet is created,
serialize converts its argument or all created stylesheets to an HTML string.

Key Strengths

Aspect	Benefit
Zero dependencies	No runtime overhead, no build plugins, no PostCSS config
Framework agnostic	Works identically in React, Vue, Svelte, Solid, Lit, Angular, vanilla TS
TypeScript contract	Autocompletion for selectors — impossible to misspell a variant
Selector isolation	Unique scoped names/attrs out of the box; optional minification
SSR ready	`serialize()` dumps stylesheets to HTML strings with zero extra config
Browser-native	Uses `CSSStyleSheet` + `adoptedStyleSheets` — no style tag injection

When to Use EffCSS

Design-system libraries — the type-contract pattern lets you expose a typed API while hiding implementation.
Component libraries — scoped selectors eliminate style leaks without CSS Modules or Shadow DOM.
Projects that value TypeScript DX — autocompletion for every modifier/value reduces context-switching.
Micro-frontends / multi-team setups — each stylesheet is fully isolated by default.

When to Consider Alternatives

You're already deep in Tailwind — EffCSS is a different paradigm (component-scoped vs. utility-first). They can coexist, but Tailwind's ecosystem is larger.
You want a build-time zero-runtime solution (Linaria, vanilla-extract) — EffCSS has a small runtime (~3.7 KB minzipped size) for stylesheet management.
You need CSS Modules — if your team is already comfortable with them and doesn't need TypeScript-driven selectors.
Pure CSS solves all your problems – and that's great!

Final thoughts

EffCSS v5 fills a specific niche: type-safe, isolated, framework-agnostic styling with zero tooling overhead. It's not a Tailwind killer or a styled-components replacement — it's a different approach where the TypeScript compiler becomes your style guide enforcer. If you value compile-time safety and want styles that "just work" across any framework, it's worth a serious look.

In any case, I would be interested to know whether you use CSS-in-JS, what attracts you to it or, on the contrary, repels you.

Enjoy your Frontend Development!

Different shades of CSS-in-TS

Marat Sabitov — Mon, 08 Jun 2026 02:00:00 +0000

For me, it's important that all resources I use in a project have a predictable API, so I don't have to dig into the source code later. So, when using CSS styles, I want to see whether I'm using the correct selectors in my components.

That’s why CSS-in-TS seems like the perfect tool for control and performance improvement. But in reality, it's not just one single tool but rather an entire ideology with various shades of implementation. In this article, we will look at 3 different CSS-in-TS tools and see how they differ. The main goal is to evaluate the impact of a tool on the development process, not to choose the best solution – everyone has their own. Let's start, perhaps, with the most popular approach.

CSS Modules + typed-css-modules

The CSS Modules library allows you to write styles in CSS files, but isolates those files from each other to prevent naming conflicts.

In a typical scenario, we first write styles in a file with the format *.module.css:

/* Base button */
.btn {
    height: 1.5rem;
    border-radius: 0.25rem;
    color: white;
    background-color: #58666d;
}

/* Background variants */

/* Button with primary bg */
.btn-primary {
    background-color: #2192a7;
}
/* Button with secondary bg */
.btn-secondary {
    background-color: #9d41ab;
}

/* Width variants */

/* Button with full width */
.btn-full {
    width: 100%;
}
/* Button with half width */
.btn-half {
    width: 50%;
}

Then we generate TypeScript types for these styles using typed-css-modules. For our module, we get the following TypeScript declaration style.module.css.d.ts:

declare const styles: {
  readonly "btn": string;
  readonly "btnFull": string;
  readonly "btnHalf": string;
  readonly "btnPrimary": string;
  readonly "btnSecondary": string;
};
export = styles;

And then we can use it in our components, fully benefiting from TypeScript autocomplete functionality:

import { btn, btnFull, btnPrimary } from './style.module.css';

const Component = () => (
    <button className={`${btn} ${btnPrimary} ${btnFull}`}>
        Use CSS-in-TS
    </button>
);

Thus, in this scenario, CSS styles are the primary source – types are created based on them, and our components depend on types.

vanilla-extract

vanilla-extract suggests describing styles directly in TypeScript files from the start, while questions of selectors uniqueness and isolation are resolved at the level of individual calls to its utilities.

In a typical scenario, we first write styles in a file with the format *.css.ts:

import { style, styleVariants } from '@vanilla-extract/css';

/* Base button */
export const btn = style({
    height: '1.5rem',
    borderRadius: '0.25rem',
    color: 'white',
    backgroundColor: '#58666d'
});

/* Background variants */
export const btnBackground = styleVariants({
    /* Button with primary bg */
    primary: {
        backgroundColor: '#2192a7'
    },
    /* Button with secondary bg */
    secondary: {
        backgroundColor: '#9d41ab'
    }
});

/* Width variants */
export const btnWidth = styleVariants({
    /* Button with full width */
    full: {
        width: '100%'
    },
    /* Button with half width */
    half: {
        width: '50%'
    }
});

There is no need to manually generate TypeScript declarations for these styles – it's sufficient to import them into your components and use them:

import { btn, btnWidth, btnBackground } from './style.css.ts';

const Component = () => (
    <button
        className={`${btn} ${btnBackground.primary} ${btnWidth.full}`}
    >
        Use CSS-in-TS
    </button>
);

Thus, in this scenario, the primary source is the CSS styles from *.css.ts – they generate types and enable TypeScript autocomplete.

EffCSS

EffCSS generates styles using StyleSheet maker functions and suggests first explicitly declaring a function type, then implementing and using it. This library isolates styles obtained from different functions.

In a typical scenario, we first describe the contract type in a file with the format *.ts:

export type TBtn = {
    /**
     * Button
     */
    btn: {
        /**
         * Background
         */
        bg: 'primary' | 'secondary';
        /**
         * Width
         */
        width: 'full' | 'half';
    };
};

Then we describe our styles according to TBtn:

import { classNames} from 'effcss';

export type TBtn = {...};

export const btnClsResolver = classNames<TBtn>(selectors) => {
    const { btn } = selectors;
    return {
        [btn]: {
            height: '1.5rem',
            borderRadius: '0.25rem',
            color: 'white',
            backgroundColor: '#58666d'
        },
        [btn.bg.primary]: {
            backgroundColor: '#2192a7'
        },
        [btn.bg.secondary]: {
            backgroundColor: '#9d41ab'
        },
        [btn.width.full]: {
            width: '100%'
        },
        [btn.width.half]: {
            width: '50%'
        }
    }
};

All selectors are resolved using the selectors arg, so TypeScript will complain if you try to implement selectors not defined in the contract. Therefore, the TypeScript contract restricts both the person who writes styles and the one who uses them.

Next, we can use these styles in a component:

import { btnClsResolver } from 'btn-styles.ts';

const btnCls = btnClsResolver({
    width: 'full',
    bg: 'primary'
});

const Component = () => (
    <button className={btnCls}>Use CSS-in-TS</button>
);

Thus, in this scenario, the primary source is the TBtn contract – it checks selector correctness both when creating and using styles.

Conclusion

If we summarize, although all three tools essentially achieve the same result – TypeScript autocomplete – their usage scenarios differ significantly:

The arrows in the figure indicate the dependencies between the blocks - the source resources are on the left, and the consumers are on the right. This clearly shows that having a common goal doesn't make tools identical. Moreover, the considered scenarios demonstrate differences in initial conditions – you can use existing CSS, base your styles on CSS-in-JS, or even start with TypeScript types. Although choosing a library is often a matter of taste or corporate standards, it is often useful to choose something that will require less effort to integrate into a particular project.

Enjoy your Frontend Development!

SVG animations with Friction

Marat Sabitov — Fri, 08 May 2026 09:54:55 +0000

In the previous article, I talked about ways to create animated SVGs without using third-party libraries. This approach works well for simple animations and when the amount of work is insignificant. But what if you need to animate a lot of SVGs?

In this case, it is much easier to use specialized software. In my opinion, one of the best candidates is Friction. It is amazing motion graphics application that can create an animated SVG file using the SMIL format.

Let's take a look at this tool in action.

Export restrictions

Before creating an animation, let's check the documentation for any limitations. It would be frustrating to create a masterpiece and then not be able to save it in the required format. So we have two options - save animated SVG or video.

When exporting to SVG, Friction can correctly save the following types of animations:

Transforms (translation, rotation, scale, shear, pivot and opacity),
Gradients,
Images,
Texts,
Keyframes,
Graph,
Expressions,
Transform effects (follow path),
Path effects (trim path and more),
Raster assets (images/videos),
Blur effect,
Shadow effect,
Shape morphing,
Masking (Blend Mode DstIn and DstOut),
Mix Blend Modes (it is needed to enable it at export dialog).

In my opinion, this is more than enough to create SVG animation. If you don't know where to start, I recommend reading the section on animation techniques - this will help you evaluate the program's capabilities.

But don't rush to create figures directly in Friction - the developers themselves emphasize in the Usage section that this is a tool for animation, not for creating vector images. Personally, I'm used to using Inkscape, so I first prepare the figure there and then import it into the Friction project. To fully appreciate the benefits of using this software, I will be using the character from the previous article - Mr. Pearman is already here

Workflow

In fact, everything is very simple - you need to create a new project and import the prepared SVG into it. When creating a project, you need to specify the animation duration, frame rate, size, and background. And then the classic creation of animation based on keyframes. In my case, it looked something like this

Things to keep in mind:

you can duplicate keyframes so as not to create them again,
you can customize Bezier curves to adjust the smoothness of the animation,
you can move object pivot to set up transformations.

You can open the relevant section of the documentation for a wealth of useful tips. These tips will help you animate faster and more easily. As a result, I obtained the following animated SVG file:

For comparison, the Static section contains the original SVG, and the Dynamic section contains the one animated using JS and CSS. Please note that in the Friction section SVG is added to the layout via a simple <img/> tag, it is not interactive and does not contain CSS or JS scripts. To make this SVG file interactive, you need to explicitly place it in the markup and use, for example, pauseAnimations() and unpauseAnimations() methods. These methods control all child animations of the SVG. Technically, there is a way to access individual animations through SVGAnimationElement methods, but I don't think this is entirely correct if we're considering an SVG image as a complete and independent element. In any case, this would require additional JS and some extra work outside of Friction.

Conclusion

I think Friction is a very useful and necessary software, there are at least 5 reasons for this:

it is open source (so that your wallet doesn't suffer),
it is suitable for different operating systems (you can simply download and install),
it has well-developed documentation (I found answers to all my questions),
it supports many export formats (instead of SVG, you can use for example MP4 or WebM),
it supports scripting through ECMAScript (for true followers of JS).

And the most important thing is that by mastering simple SVG animation, you can go further in the motion graphics and expand professional skills.

Enjoy your Frontend Development!

A journey into the world of animated SVGs

Marat Sabitov — Wed, 08 Apr 2026 09:35:10 +0000

I was recently reading the Vue documentation and came across a mention of Pinia, a library for state management. And when I clicked on the link, this library won me over thanks to its creative logo. It would seem like this is just a documentation site, where all you need to post is code descriptions and examples. So, it was a surprise to me when Pinia started following my cursor. I even forgot my original goal and simply started searching for all her reactions. Such attention to detail certainly deserves praise. This cheerful character blinks, opens its mouth when hovering and follows the cursor with its eyes - in other words, it is interactive and seems to be alive.

And I wondered - how is it implemented under the hood? And how would I implement the same thing?

Pinia Alchemy

The logo is designed as a separate Vue component, inside which all the magic happens. The component uses the full power of the Vue ecosystem, as can be seen from the imports

import { computed, nextTick, onMounted, onUnmounted, reactive, ref } from 'vue'
import { useSpring } from 'vue-use-spring'
import {
  useMouse,
  useEventListener,
  useDebounceFn,
  useIdle,
  whenever,
} from '@vueuse/core'

This approach works great for Vue, but what if you need to embed an animated SVG file on a React website? Fortunately, SVG can be animated without frameworks. It should be noted right away that SVG animations can be created using various tools such as SVGator, but browser APIs are sufficient for simple animations. In general, I identify four types of SVG animation:

SMIL animation,
pure CSS animation,
attribute driven CSS animation and direct styles manipulation via JS,
Web Animations API.

We'll look at all of these options using a practical example - I created a character that Pinia might be familiar with.

Meet Mr. Pearman

To animate an SVG, you need to be sure of the correct structure and layer placement. When using ready-made SVGs, you need to be prepared for limitations and adapt to its styles. That's why I prefer to design the character behavior first and then implement it myself. This serious guy was created with Inkscape.

For this character, I plan to animate:

cape movement (to make it look more epic),
facial expressions when hovered over (this guy doesn't like being pointed at),
color change when clicked (his mood gradually worsens after each click, but returns to its original state after the cursor moves out),
working out with a dumbbell while waiting for the cursor movement (Mr. Pearman has to be strong to do justice).

A good solution is to group elements that should or can be transformed at the same time. I also recommend checking in an SVG editor how the image should look at different points in the animation to make sure you've made the right choice. And the most important thing is not to complicate the SVG.

Once the image is ready, you can start writing the animation in any text editor.

Animating Mr. Pearman

The SMIL animation looks the most organic for SVG. Essentially it all comes down to choosing the right element (animate, animateTransform, animateMotion) and passing the correct attributes. I will use animate to realize the cape emovement:

<path
     style="fill:#4b7229;fill-opacity:1;stroke-width:0.264583"
     d="m 146.05723,123.12633 c 0,0 41.89228,89.47314 45.40039,99.76848 3.50811,10.29534 -8.11042,8.66023 -14.26613,6.44205 -4.60132,-1.65806 -4.47508,-6.82347 -12.01742,-5.92669 -5.21874,0.6205 -7.61486,8.14833 -12.74747,9.27818 -16.81689,3.70192 -33.45177,-10.04425 -50.67129,-10.05122 -18.861521,-0.008 -36.908207,14.0719 -55.512045,10.96477 -4.649159,-0.77648 -7.517475,-6.97037 -12.229259,-7.09955 -5.107148,-0.14002 -8.571991,7.45123 -13.657138,6.95742 -4.019026,-0.39028 -10.8529692,-3.65626 -9.53423,-7.47278 18.178826,-52.61078 46.809504,-105.37833 46.809504,-105.37833 z"
>
    <animate
        attributeName="d"
        dur="4s"
        repeatCount="indefinite"
        fill="freeze"
        values="m 146.05723,123.12633 c 0,0 41.89228,89.47314 45.40039,99.76848 3.50811,10.29534 -8.11042,8.66023 -14.26613,6.44205 -4.60132,-1.65806 -4.47508,-6.82347 -12.01742,-5.92669 -5.21874,0.6205 -7.61486,8.14833 -12.74747,9.27818 -16.81689,3.70192 -33.45177,-10.04425 -50.67129,-10.05122 -18.861521,-0.008 -36.908207,14.0719 -55.512045,10.96477 -4.649159,-0.77648 -7.517475,-6.97037 -12.229259,-7.09955 -5.107148,-0.14002 -8.571991,7.45123 -13.657138,6.95742 -4.019026,-0.39028 -10.8529692,-3.65626 -9.53423,-7.47278 18.178826,-52.61078 46.809504,-105.37833 46.809504,-105.37833 z;
        m 146.05723,123.12633 c 0,0 33.46693,74.61111 35.60848,80.44234 2.14155,5.83123 4.11806,9.17987 2.2934,10.56986 -5.76505,4.39171 -9.62872,-1.92751 -17.17106,-1.03073 -5.21874,0.6205 -5.23418,7.59514 -9.26877,9.27818 -17.15536,7.15639 -37.18589,0.86369 -55.76397,0.25115 -14.805226,-0.48815 -25.545341,1.96964 -44.329665,-3.12698 -4.844665,-1.31447 -14.28973,0.65633 -21.238085,-0.7204 -4.016258,-0.79577 -6.395465,-6.68193 -11.50726,-4.29596 -3.574065,1.66822 -10.079924,2.27042 -8.761185,-1.5461 18.178826,-52.61078 41.713027,-92.33903 41.713027,-92.33903 z;
        m 146.05723,123.12633 c 0,0 41.89228,89.47314 45.40039,99.76848 3.50811,10.29534 -8.11042,8.66023 -14.26613,6.44205 -4.60132,-1.65806 -4.47508,-6.82347 -12.01742,-5.92669 -5.21874,0.6205 -7.61486,8.14833 -12.74747,9.27818 -16.81689,3.70192 -33.45177,-10.04425 -50.67129,-10.05122 -18.861521,-0.008 -36.908207,14.0719 -55.512045,10.96477 -4.649159,-0.77648 -7.517475,-6.97037 -12.229259,-7.09955 -5.107148,-0.14002 -8.571991,7.45123 -13.657138,6.95742 -4.019026,-0.39028 -10.8529692,-3.65626 -9.53423,-7.47278 18.178826,-52.61078 46.809504,-105.37833 46.809504,-105.37833 z"
    />
</path>

As you can see SMIL allows to realize SVG path morphing, while CSS solution is still not baseline.

Pure CSS animations are my favorite in most cases, allowing to attach animations and transitions not only to elements but also to their pseudo-states. Here I will use the following CSS to animate :hover pseudostate:

<style>
    #mouth {
        transition: transform 200ms linear;
        transform-origin: center;
    }
    #right_eye > *, #left_eye > * {
        transition: ry 200ms linear;
    }
    #left_eyebrow {
        transition: transform 200ms linear;
        transform-origin: center;
    }

    svg:has(#figure:hover) {
        #mouth {
            transform: skewY(-10deg);
        }

        #right_eye > *, #left_eye > * {
            ry: 2px;
        }

        #left_eyebrow {
            transform: skewY(10deg);

        }
    }
</style>

To implement a color change animation, we need to store and compare states - this is where JS comes in handy. In fact, you'll only end up here if you're lacking in CSS or SMIL capabilities. We will simply set a new attribute value based on its current value, and at the end of the timeout, we will return the initial color:

<style>
    svg {
        transition: filter 250ms linear;
        filter: grayscale(0%);
    }
    #figure {
        cursor: pointer;
    }

    svg[data-lvl="1"] {
        filter: grayscale(30%) contrast(150%);
    }
    svg[data-lvl="2"] {
        filter: grayscale(70%) contrast(200%);
    }
    svg[data-lvl="3"] {
        filter: grayscale(100%) contrast(200%);
    }
</style>
<script type="text/javascript">
    //<![CDATA[
    const svg = document.currentScript.parentElement;
    const figure = svg.querySelector('#figure');

    figure.addEventListener('click', () => {
        const level = +svg.dataset.lvl || 0;
        if (level < 3) {
        const nextLevel = level + 1;
        svg.dataset.lvl = nextLevel;
        }
    });

    figure.addEventListener('mouseleave', () => {
        delete svg.dataset.lvl;
    });
    //]]>
</script>

Sometimes it becomes necessary to dynamically identify keyframes and accurately monitor the progress of animation - this is where the Web Animations API comes to the rescue. Before using this tool, I always ask myself the question - do I really need it? Sometimes the reason for the complexity of the code is poor documentation of requirements, so it's better to clarify all the conditions and understand the scenario before starting to implement it. CSS and attribute bindings may be enough for you. Let's use the API to create training animations that depend on whether the cursor is over Pearman:

<style>
    #left_hand_bottom {
        transform-origin: 25.639345px 180.89267px;
    }
</style>
<script
    type="text/javascript"
    id="script3"
>
    //<![CDATA[
    const doc = document.documentElement;
    const svgElem = document.currentScript.parentElement;
    const hand = svgElem.querySelector('#left_hand_bottom');
    const figureElem = svgElem.querySelector('#figure');

    let timeoutId;
    let animation;
    let reset;

    function start() {
        if (hand.getAnimations().length) return;
        else if(figureElem.matches('*:hover')) {
        animation = hand.animate([
            {
                transform: 'rotate(0deg)'
            },
            {
                transform: 'rotate(-65deg)'
            },
            {
                transform: 'rotate(0deg)'
            }
        ], {
            duration: 8000, easing: 'cubic-bezier(.2,.34,0,1.05)', iterations: 'Infinity'
        });
        } else {
        animation = hand.animate([
            {
                transform: 'rotate(0deg)'
            },
            {
                transform: 'rotate(-45deg)'
            },
            {
                transform: 'rotate(0deg)'
            }
        ], {
            duration: 2000, easing: 'ease', iterations: 'Infinity'
        });
        }
    }

    function stop() {
        if (animation && !reset) {
        animation.pause();
        reset = hand.animate([
            {
                transform: 'rotate(0deg)'
            }
        ], {
            duration: 500, easing: 'ease'
        });
        reset.finished.then(() => {
            animation.cancel();
            animation = undefined;
            reset.cancel();
            reset = undefined;
        });
        }
    }

    doc.addEventListener('mousemove', () => {
        clearTimeout(timeoutId);
        stop();
        timeoutId = setTimeout(() => start(), 5000);
    });
   //]]>
</script>

The Web Animation API is so powerful that it cannot be described in one example. But with great power comes great responsibility, and the likelihood of mistakes also increases. Therefore, I rather consider it as a foundation for writing specialized libraries than as a direct animation tool.

So, we can collect all the animations in one SVG to simply use in a browser. As a result, we get the following SVG

As you can see, SVG is embedded directly into the HTML document so that its scripts can reach the document. There is also the option of embedding interactive SVGs via iframe, but then they will be in their own HTML document. This is one of the nuances to keep in mind - a regular img tag will not show all the embedded animations. This is why Pinia can catch cursor movements - it is built into the Vue component.

Conclusion

In fact, I'm really inspired by the fact that we can animate almost anything in the browser without any external dependencies. And interactive SVGs can not only attract attention but also make a website more lively and interesting. The key with animation is not to overdo it.

Like any front-end component, animation should serve a purpose, not just distract from the task at hand. And if you focus on small features, there will usually be enough CSS animations to make the site pleasant to interact with.

In addition, you need to be prepared to embed SVG containing scripts directly into HTML or via an iframe. This is not always acceptable, and extra scripts on the page can cause chaos.

I hope that the world of SVG animations has become closer to you after reading.

Enjoy your Frontend Development!

CSS only components

Marat Sabitov — Sun, 08 Mar 2026 12:03:37 +0000

Modern CSS has become so powerful that the basic layout can be styled without using third-party tools. And simple user interface templates can be described using pure CSS. Let's look at an example in which we will try to create a simple CSS component, organizing it in the manner of React.

Initial styles

Let's imagine that we are describing a button group component that defines both its own and nested button styles, including for :hover and :active states:

.btn {
  width: calc(100% * var(--offset) / 2);
  border-radius: calc(1rem * (var(--offset) - 1));
  background-color: var(--neutral-color);
}

.btn-group {
  display: flex;
  gap: 0.25rem;
  margin: 1rem 0;

  & > * {
    flex: 1 1 auto;
    padding: 0.5rem;
    background: oklch(from currentColor 0.8 calc(c / 4) h / 0.2);
    border: none;
    cursor: pointer;
    transition: all 100ms ease-in 0s;
    transition-property: background translate box-shadow;

    &:hover {
      background: oklch(from currentColor 0.8 calc(c / 4) h / 0.6);
      box-shadow: 0 0.2rem 0 currentColor;
    }
    &:active {
      translate: 0 0.2rem;
      box-shadow: 0 0 0 currentColor;
    }
  }
}

For now, it's just CSS that can't be customized. At the same time React component can accept props and have a state. Let's try to implement similar mechanics.

Thinking in React way

The component's props allow you to customize its behavior from the outside. Let's say I want to be able to adjust the color of the button, the size of the shadow, and the duration of the transition.

Component states are something that can change according to internal logic and affect the final rendering. If you look at the initial example, you can highlight such states as the value of the alpha channel of the button color, the size of the shadow, and the value of the button translate property.

Then we will get the following code:

.btn-group-component {
  /* props */
  --color-prop: currentColor;
  --shadow-size-prop: 0.2rem;
  --duration-prop: 100ms;

  /* state */
  --alpha-state: 0.2;
  --shadow-size-state: 0;
  --translate-state: 0;

  /* render */
  display: flex;
  gap: 0.25rem;
  margin: 1rem 0;

  & > * {
    flex: 1 1 auto;
    padding: 0.5rem;
    background: oklch(from var(--color-prop) 0.8 c h / var(--alpha-state));
    box-shadow: 0 var(--shadow-size-state) 0 var(--color-prop);
    translate: 0 var(--translate-state);
    border: none;
    cursor: pointer;
    transition: all var(--duration-prop) ease-in 0s;
    transition-property: background translate box-shadow;

    &:hover {
      --alpha-state: 0.6;
      --shadow-size-state: var(--shadow-size-prop);
    }

    &:active {
      --translate-state: var(--shadow-size-prop);
      --shadow-size-state: 0;
    }
  }
}

So we have defined special CSS variables for props and states, but we forgot that each React component has its own scope and name. Let's fix this:

@scope (btn-group) {
  /* props */
  --color-prop: currentColor;
  --shadow-size-prop: 0.2rem;
  --duration-prop: 100ms;

  /* state */
  --alpha-state: 0.2;
  --shadow-size-state: 0;
  --translate-state: 0;

  /* styles */
  :scope {
    display: flex;
    gap: 0.25rem;
    margin: 1rem 0;

    & > * {
      flex: 1 1 auto;
      padding: 0.5rem;
      background: oklch(from var(--color-prop) 0.8 c h / var(--alpha-state));
      box-shadow: 0 var(--shadow-size-state) 0 var(--color-prop);
      translate: 0 var(--translate-state);
      border: none;
      cursor: pointer;
      transition: all var(--duration-prop) ease-in 0s;
      transition-property: background translate box-shadow;

      &:hover {
        --alpha-state: 0.6;
        --shadow-size-state: var(--shadow-size-prop);
      }

      &:active {
        --translate-state: var(--shadow-size-prop);
        --shadow-size-state: 0;
      }
    }
  }
}

@scope helps to use contextual proximity to resolve conflicts between styles. Additionally, it visually highlights the isolation of styles within their context. However, I would like to pass React style properties as separate HTML attributes rather than a single string within the style attribute. Fortunately, this future is just around the corner.

`attr()` will change all

Imagine what will happen if the attr() function can be used in arbitrary CSS properties - then HTML attributes can be used as real component props:

@scope (btn-group) {
  /* props */
  --color-prop: attr(color type(<color>), currentColor);
  --shadow-size-prop: attr(shadow-size type(<length>), 0.2rem);
  --duration-prop: attr(duration type(<time>), 100ms);

  /* state */
  --alpha-state: 0.2;
  --shadow-size-state: 0;
  --translate-state: 0;

  /* styles */
  :scope {
    display: flex;
    gap: 0.25rem;
    margin: 1rem 0;

    & > * {
      flex: 1 1 auto;
      padding: 0.5rem;
      background: oklch(from var(--color-prop) 0.8 c h / var(--alpha-state));
      box-shadow: 0 var(--shadow-size-state) 0 var(--color-prop);
      translate: 0 var(--translate-state);
      border: none;
      cursor: pointer;
      transition: all var(--duration-prop) ease-in 0s;
      transition-property: background translate box-shadow;

      &:hover {
        --alpha-state: 0.6;
        --shadow-size-state: var(--shadow-size-prop);
      }

      &:active {
        --translate-state: var(--shadow-size-prop);
        --shadow-size-state: 0;
      }
    }
  }
}

Just one feature can change the way you approach web styling. Just try it in Chrome to feel the power.

Your can explore all code examples with StackBlitz:

Final thoughts

I think that the CSS-only approach, which has been promoted so long and hard with Bootstrap, Tailwind, Bulma, and many other frameworks, is finally taking shape. But now, CSS can be more than just a collection of utilities or classes; it can be a complete set of components. And I'm looking forward to having the attr() function for all properties becoming widely available.

Enjoy your Frontend Development!

Useful TypeScript generics for tree structures

Marat Sabitov — Mon, 23 Feb 2026 10:03:41 +0000

Developers are surrounded by hierarchies of objects, such as the DOM tree, React component tree, and NPM dependency tree. Tree-like data structures are quite common in code, and reliable Typescript types make working with them more confident. In this article, I want to share with you some generics that benefit me the most.

Deep partial

Sometimes we are willing to provide default values for all parameters of a third-party function, even nested ones, so they are all optional. In that case DeepPartial type is helpful:

type DeepPartial<T> = T extends object
    ? {
          [P in keyof T]?: DeepPartial<T[P]>;
      }
    : T;

type InitialType = {
    header: {
        size: 'sm' | 'md' | 'lg';
        color: 'primary' | 'secondary';
        nav: {
            align: 'left' | 'right';
            fontSize: number;
        }
    };
    footer: {
        fixed: boolean;
        links: {
            max: 5 | 10;
            nowrap: boolean;
        }
    }
};

type ResultType = DeepPartial<InitialType>;
/*
type ResultType = {
    header?: {
        size?: "sm" | "md" | "lg" | undefined;
        color?: "primary" | "secondary" | undefined;
        nav?: {
            align?: "left" | "right" | undefined;
            fontSize?: number | undefined;
        } | undefined;
    } | undefined;
    footer?: {
        fixed?: boolean | undefined;
        links?: {
            max?: 5 | 10 | undefined;
            nowrap?: boolean | undefined;
        } | undefined;
    } | undefined;
};
*/

Paths

Another case is that you need to infer all the available tree paths as a type. Paths generic can solve this:

type Paths<T> = T extends object ? {
        [K in keyof T]: `${Exclude<K, symbol>}${
            '' | Paths<T[K]> extends '' ? '' : `.${Paths<T[K]>}`
        }`;
    }[keyof T] : never;

type InitialType = {
    header: {
        size: 'sm' | 'md' | 'lg';
        color: 'primary' | 'secondary';
        nav: {
            align: 'left' | 'right';
            fontSize: number;
        }
    };
    footer: {
        fixed: boolean;
        links: {
            max: 5 | 10;
            nowrap: boolean;
        }
    }
};

type ResultType = Paths<InitialType>;
/*
type ResultType = "header.size" | "header.color" | "header.nav.align" |
"header.nav.fontSize" | "footer.fixed" | "footer.links.max" |
"footer.links.nowrap";
*/

Sometimes path should include leaves, so you can use the next generic:

type Paths<T> = T extends object ? {
        [K in keyof T]: `${Exclude<K, symbol>}${
            '' | Paths<T[K]> extends '' ?
                '' :
                `.${Paths<T[K]>}`
            }`;
    }[keyof T] : T extends string | number | boolean ? T : never;

type InitialType = {
    header: {
        size: 'sm' | 'md' | 'lg';
        color: 'primary' | 'secondary';
        nav: {
            align: 'left' | 'right';
            fontSize: number;
        }
    };
    footer: {
        fixed: boolean;
        links: {
            max: 5 | 10;
            nowrap: boolean;
        }
    }
};

type ResultType = Paths<InitialType>;
/*
type ResultType = "header.size.sm" | "header.size.md" | "header.size.lg" |
"header.color.primary" | "header.color.secondary" | "header.nav.align.left" |
"header.nav.align.right" | `header.nav.fontSize.${number}` |
"footer.fixed.false" | "footer.fixed.true" | "footer.links.max.5" |
"footer.links.max.10" | "footer.links.nowrap.false" |
"footer.links.nowrap.true";
*/

You may notice a strange element header.nav.fontSize.${number} in the ResultType. It appears due to the fact that the fontSize parameter can take an infinite number of values. We can modify the generic to eliminate such paths:

type Paths<T> = T extends object ? {
        [K in keyof T]: `${Exclude<K, symbol>}${
            '' | Paths<T[K]> extends '' ? '' : `.${Paths<T[K]>}`
        }`;
    }[keyof T] : T extends string | number | boolean ?
    `${number}` extends `${T}` ? never : T :
    never;

type InitialType = {
    header: {
        size: 'sm' | 'md' | 'lg';
        color: 'primary' | 'secondary';
        nav: {
            align: 'left' | 'right';
            fontSize: number;
        }
    };
    footer: {
        caption: string;
        fixed: boolean;
        links: {
            max: 5 | 10;
            nowrap: boolean;
        }
    }
};

type ResultType = Paths<InitialType>;
/*
type ResultType = "header.size.sm" | "header.size.md" | "header.size.lg" |
"header.color.primary" | "header.color.secondary" | "header.nav.fontSize" |
"header.nav.align.left" | "header.nav.align.right" | "footer.caption" |
"footer.fixed.false" | "footer.fixed.true" | "footer.links.max.5" |
"footer.links.max.10" | "footer.links.nowrap.false" |
"footer.links.nowrap.true";
*/

Nodes and Leaves

In many algorithms, it is necessary to distinguish the nodes of the tree from the leaves. If we consider those parameters that have object values as nodes, then we can apply the following generics:

type Nodes<T> = T extends object ? {
        [K in keyof T]: T[K] extends object ?
            (
                `${Exclude<K, symbol>}` |
                `${Exclude<K, symbol>}.${Nodes<T[K]>}`
            ) : never;
    }[keyof T] : never;

type Leaves<T> = T extends object ? {
    [K in keyof T]: `${Exclude<K, symbol>}${
            Leaves<T[K]> extends never ? "" : `.${Leaves<T[K]>}`
        }`
    }[keyof T] : never;

type InitialType = {
    header: {
        size: 'sm' | 'md' | 'lg';
        color: 'primary' | 'secondary';
        nav: {
            align: 'left' | 'right';
            fontSize: number;
        }
    };
    footer: {
        caption: string;
        fixed: boolean;
        links: {
            max: 5 | 10;
            nowrap: boolean;
        }
    }
};

type ResultNodes = Nodes<InitialType>;
type ResultLeaves = Leaves<InitialType>;
/*
type ResultNodes = "header" | "footer" | "header.nav" | "footer.links";
type ResultLeaves = "header.size" | "header.color" | "header.nav.align" |
"header.nav.fontSize" | "footer.fixed" | "footer.caption" |
"footer.links.max" | "footer.links.nowrap";
*/

Conclusion

As you can see, Typescript has the necessary flexibility to simplify your code. And although tree structures seem to be quite complex, generics help to cope with them without types duplication. I hope that you have found something interesting in this article.

Enjoy your frontend development!

You don't need CSS preprocessor

Marat Sabitov — Sun, 08 Feb 2026 09:49:49 +0000

There was a time when CSS preprocessors seemed like a magical elixir for any CSS problems. It was only necessary to learn a new syntax, set up the environment and add several dependencies to your project. But as time passed, web technologies developed, and preprocessors seemed to remain in their own isolated world. So right now I don't see any reason to use these tools in development.

Let's take a look at what preprocessors offer us, and how valuable their features are at the moment.

Variables, Nesting, Operations and Scope

Modern CSS has matured significantly compared to its original version. Now you can create variables using @property, limit the scope of selectors using @scope, describe complex operations with calc and use nested CSS rules. Therefore, such features are no longer advantages.

Mixins, Maps and Functions

Сomplex data structures such as Mixins, Maps and Functions seem to be a real advantage of preprocessors. But don't you think that there is already a programming language in web development that has been able to do all this for a long time?

The very concept of CSS-in-JS has an important message - not to invent a new programming language, but to use JavaScript. And browsers have supported this concept with a class of CSS constructed StyleSheets. Constructed stylesheet can be added to the HTML Document and to the HTML Element ShadowRoot. This makes it easier to reuse styles and dynamically change them. Besides this has radically changed the balance of power.

Take a look at the following mixin example from the Sass documentation:

@mixin theme($theme: DarkGray) {
  background: $theme;
  box-shadow: 0 0 1px rgba($theme, .25);
  color: #fff;
}

.info {
  @include theme;
}
.alert {
  @include theme($theme: DarkRed);
}
.success {
  @include theme($theme: DarkGreen);
}

You can replace it using JS:

const DarkGray = '169, 169, 169';
const DarkRed = '139, 0, 0';
const DarkGreen = '0, 100, 0';

function theme(value = DarkGray) {
    return `background: ${value};` +
        `box-shadow: 0 0 1px rgba(${value}, 0.25);` +
        'color: #fff;';
}

const sheet = new CSSStyleSheet();
sheet.replaceSync(
    `.info{${theme()}}` +
    `.alert{${theme(DarkRed)}}` +
    `.success{${theme(DarkGreen)}}`
);

Next, let's take a look at the example of maps usage from the Less documentation:

#colors() {
  primary: blue;
  secondary: green;
}

.button {
  color: #colors[primary];
  border: 1px solid #colors[secondary];
}

You can simplify it using JS:

const COLORS = {
    primary: 'blue',
    secondary: 'green'
};

const sheet = new CSSStyleSheet();
sheet.replaceSync(
  `.button {` +
  `color: ${COLORS.primary};` +
  `border: 1px solid ${COLORS.secondary};` +
  `}`
);

Finally, let's take a look at an example of functions from the Stylus documentation:

add(a, b)
  a + b

sub(a, b)
  a - b

invoke(a, b, fn)
  fn(a, b)

body
  padding invoke(5, 10, add)
  padding invoke(5, 10, sub)

Well it's too simple for JS:

const add = (a, b) => a + b;
const sub = (a, b) => a - b;
const invoke = (a, b, fn) => fn(a, b);

const sheet = new CSSStyleSheet();
sheet.replaceSync(
  `body {` +
  `padding: ${invoke(5, 10, add)};` +
  `padding: ${invoke(5, 10, sub)};` +
  `}`
);

It looks like all the features of CSS preprocessors can be implemented using pure JS. Without dependencies. Without binding to the framework. So what price do you have to pay for using preprocessors?

At what cost?

Let's walk the path of working with a CSS preprocessor.

Our first step is to install a preprocessor, so I suggest taking a look at the Package Phobia report for Sass, Less, and Stylus:

Well, these are not particularly lightweight libraries. But what can you not do for the sake of new experiences.

Our second step is to master the syntax of the library. This definitely entails spending time and mental effort. Let's say we're smart enough to do it in less than a week.

Our third step is to set up the build tools. It is quite easy (Praise be to Vite!). But then there is an awareness of the problem.

We just moved away from CSS to come back. It was an exciting adventure but we got the usual static CSS at the output. Is the cost fair?

I'm sure someone will say, look, you've saved so much time than if you were writing in pure CSS. But I spent a lot more effort than I would have written in pure JS.

In addition, the new syntax always imposes its own limitations. And the most important limitation is the scope of application. CSS preprocessors solve only one problem, which is now easy to solve without them.

Final thoughts

In my opinion, using a CSS preprocessor is like flying in a hot air balloon. The destination will be reached, but with less comfort than by plane.

I think that the constructed stylesheets have completely changed the balance, now everything that is not implemented in CSS can be done directly using JS. And now it makes sense to create any CSS-in-JS solution only on top of constructed stylesheets. When I started using them, I lacked TypeScript support, server-side rendering, and selectors minification, which is why the idea of EffCSS was born.

It is useful to know about CSS preprocessors. It will be great to add them to your resume. But, it's hardly worth using them.

Enjoy your Frontend Development!

Bundle size badges are just numbers

Marat Sabitov — Wed, 28 Jan 2026 15:15:45 +0000

While exploring GitHub or NPM you can see that many packages use badges - small rectangles that show package metrics and characteristics. I noticed that these badges are often perceived as indicators of the package quality. This is especially true for the bundle size badges, which use beautiful numbers and a green background to manipulate our choice. I suppose these badges are not what they seem at first glance and in practice mean nothing.

To make the article more visual, let's look at such popular CSS-in-JS libraries as Emotion CSS and Styled Components as an example.

Reason #1: bundle size !== package install size

There are two excellent services for estimating package size - Bundlephobia and Package Phobia. While the first calculates "bundle size", the second calculates "publish size" and "install size".
The "install size" is the result of recursively summing up all the package dependencies. The result of such an evaluation may surprise.

Firstly, let's take a look at the libraries badges. We are interested in gzip size and minzipped size:

Then let's look at the Package Phobia reports:

It's a pretty strong difference. The most surprising thing for me is that the install size of the framework-agnostic @emotion/css library exceeds its highly specialized competitor. This brings us to the second point.

Reason #2: bundle size !== feature-richness

Typically, the core library provides only basic functionality. This is a perfectly reasonable approach — you only load what's really needed. But on the other hand, the library author can move almost everything out of the core to achieve a minimal bundle size — and voila, beautiful bundle badges are ready.

This also relates to framework integrations. You can create framework agnostic core and lots of integrations. So actually, let's replace @emotion/css with @emotion/react. Now these libraries should be at least comparable across the framework. By the way, this version contains more different features, for example, it supports server rendering (via @emotion/server).

So, the Package Phobia report is already done.

Well, it was expected. The publish size has increased several times compared to the original, which is the price for new features. Thus, we see two approaches to feature packaging: distributed and monolithic. This division is somewhat arbitrary, because we cannot define a clear boundary between extreme cases, but simply indicate which side is closer. And this fuzziness brings us to the third point.

Reason #3: bundle size !== code performance

In Web Development high performance is often associated with a small bundle size, as pages with large resources can delay the first rendering. But if you open the Performance DevTools Panel, you will see that it is more complex. And the bottom line is that your page metrics reflect the state of the entire page, not the performance of a single library. Of course, you can compare tools in test examples. By the way, such a comparison of Emotion CSS and Styled Components has already been described in another article. But how significant is this?

The result of the work is determined not only by the tools, but also by your skills. You can have the most effective tool, but not be able to handle it, and vice versa. With experience, your skills determine the quality of the product to a greater extent.

If we go back to our examples, we need to evaluate which features of these tools are really needed. And it's always useful to evaluate native capabilities. Modern CSS allows you to flexibly customize theme via @property, isolate selectors via @scope, and write queries via @container. Also you can add or change styles dynamically via constructed stylesheets. Using native Browser APIs you can achieve success with less effort and less dependencies. Therefore, sometimes it is most effective not to use additional packages at all.

Final thoughts

So what can we say about bundle size badges?

They don't show how lightweight a package is.
They don't show how feature-rich a package is.
They don't show how effective a package is.

They are just numbers. I think these numbers only show the package author's approach to coding and bundling. It's probably weird to evaluate this on the positive or negative side.

And I hope that you will not judge the packages only by their bundle size badges.

Enjoy your Frontend Development!

CSS @scope: advanced nesting

Marat Sabitov — Sun, 18 Jan 2026 08:20:46 +0000

When you write complex CSS rules, you often have to handle style conflicts. The concepts of cascade and specificity significantly affect the final CSS, so sometimes it becomes difficult to understand and maintain it. CSS nesting seems like a better alternative to create visually сlear code, and along with @scope it offers completely new possibilities for grouping and isolating CSS rules. Such power is often taken too literally, which leads to some misconceptions about @scope. Let's dispel common myths and take a pragmatic look at the @scope real power.

Myth #1: `@scope` fully isolates styles

No, it doesn't. CSS property inheritance is not prevented. Properties such as font-size, font-weight, color can use the computed value of the parent element - in other words they can cross the @scope limit. If this is critical, you can explicitly use the initial value.

Myth #2: `@scope` has the highest-priority

Actually, importance, layers, and specificity have higher priority. Therefore, reducing the specificity of the rules using scope may rather weaken your CSS styles in relation to others. This should always be kept in mind.

Myth #3: `@scope` is better to use with type selectors

You'll probably agree with me that CSS classes can be too long and verbose (especially when you are using BEM). And I've already read a lot of articles about how the @scope syntax allows you to avoid this through type selectors. But there is one nuance - this way is how your CSS force HTML to use specific elements and semantics. Take a look at the following code example:

@scope (.feature) {
  img {
    border: 5px solid black;
    background-color: goldenrod;
  }
}

<div class="feature">
    <img />
</div>

Everything works fine as long as you only use <img/>. But, for example, you decide to use a ready-made third-party <Avatar/> component:

<div class="feature">
    <Avatar />
</div>

and <Avatar/> has structure:

<div class="outer">
    <img class="inner"/>
</div>

Then your CSS will try to interfere with the internal styles of <Avatar/>. This is usually not what we want to do. Components encapsulate their behavior and styles. They only expect parameters from you, not intervention. Therefore, any type selectors actually only limit styles, not make them better. And @scope may well do without them.

`@scope` real power

In my opinion, the most promising feature of the @scope is the ability combine it with @property at-rules. Just look at the next code block:

@scope (.list) {
    @property --list-bg {
        inherits: false;
        syntax: "<color>";
        initial-value: aquamarine;
    }
    @property --list-rounded {
        inherits: false;
        syntax: "<integer>";
        initial-value: 0;
    }

    :scope {
        --list-item-offset: 1rem;
        background-color: var(--list-bg);
        border-radius: calc(1rem * var(--list-rounded));
        width: 100%;

        &.rounded {
            --list-rounded: 1;
        }
        &.primary {
            --list-bg: grey;
        }
        &.secondary {
            --list-bg: purple;
        }
        &.offset-s {
            --list-item-offset: 0.5rem;
        }
        &.offset-l {
            --list-item-offset: 2rem;
        }
    }

    /* nested scope */
    @scope (.item) {
        @property --item-bg {
            inherits: false;
            syntax: "<color>";
            initial-value: white;
        }
        @property --item-rounded {
            inherits: false;
            syntax: "<integer>";
            initial-value: 0;
        }
        :scope {
            margin: 0 var(--list-item-offset) var(--list-item-offset);
            background-color: var(--item-bg);
            border-radius: calc(1rem * var(--item-rounded));
            width: calc(100% - 2 * var(--list-item-offset));

            &.rounded {
                --item-rounded: 1;
            }
            &.primary {
                --item-bg: coral;
            }
            &.secondary {
                --item-bg: bisque;
            }
        }
    }
}

This is somewhat similar to BEM, but it does not limit the nesting. It's also similar to Atomic CSS, but the utilities here only affect CSS custom properties. The provided CSS can be described using the TypeScript type:

type TStyles = {
    /**
     * List scope
     */
    list: {
        /**
         * List background
         */
        bg?: 'primary' | 'secondary';
        /**
         * Is list rounded
         */
        rounded?: '';
        /**
         * List offset
         */
        offset?: 's' | 'l';
        /**
         * List item scope
         */
        item?: {
            /**
             * Item background
             */
            bg?: 'primary' | 'secondary';
            /**
             * Is item rounded
             */
            rounded?: '';
        };
    };
}

Do you see what I'm getting at?
Scoped CSS styles can describe abstract UI components without HTML binding. And it looks promising.

Final thoughts

In the previous article, I described multilevel CSS theming using @property at-rule. And in the final example, we saw how @scope allows you to group styles into components. This is exactly what is required at the lower level of theming - specific component styles, grouped, isolated, framework and preprocessor agnostic. Of course, there are still questions about the uniqueness of selectors, their minification, etc., but more on that another time. This time, I just hope inspired you to make your CSS great again.

Enjoy your frontend development!

CSS @property: advanced theming

Marat Sabitov — Thu, 08 Jan 2026 11:05:04 +0000

When it comes to theming a web application, CSS variables turn out to be the simplest and most convenient way. And this is quite logical - you can set the value of a variable once and use it everywhere. But it seems to me that the potential of CSS variables is much broader.

Local variables

The @property CSS at-rule allows to create variables which are not inherits. Thus, these variables are essentially local. This allows you to customize the styles of specific HTML elements without worrying about a cascade of CSS rules. For example, I want to describe a box style where I can configure border radius and background color:

@property --box-radius {
    syntax: "*";
    inherits: false;
    initial-value: 16px;
}
@property --box-background {
    syntax: "*";
    inherits: false;
    initial-value: #a2a3a3;
}

.box {
    background: var(--box-background);
    border-radius: var(--box-radius);
}

.box-dark {
    --box-background: #626262;
}

.box-light {
    --box-background: #d4d6d7;
}

.box-rad-s {
    --box-background: 8px;
}

.box-rad-l {
    --box-background: 32px;
}

Now, if you put one box inside another, the parent element will not override the appearance of the child. In other words, they will have an independent states:

<div class="box box-light box-rad-s">
    Parent box with customized property values
    <div class="box">
        Child box with initial property values
    </div>
</div>

I think you've noticed that the color and size values in the code example are fixed. The best way would be to use global variables as values.

Global variables

The idea is very simple - local variables can take values defined in global variables:

:root {
    --global-background: light-dark(#dedede, #676767);
    --global-radius: 16px;
}

@property --box-radius {
    syntax: "*";
    inherits: false;
}

@property --box-background {
    syntax: "*";
    inherits: false;
}

.box {
    background: var(--box-background, var(--global-background));
    border-radius: var(--box-radius, var(--global-radius));
}

.box-dark {
    --box-background: oklch(from var(--global-background) calc(l - 0.2) c h / alpha);
}

.box-light {
    --box-background: oklch(from var(--global-background) calc(l + 0.2) c h / alpha);
}

.box-rad-s {
    --box-radius: calc(var(--global-radius) / 2);
}

.box-rad-l {
    --box-radius: calc(var(--global-radius) * 2);
}

Now we can have any number of local variables - the entire theme will be determined by only a few global values. But we're losing control of the local variables. If each of them uses its own set of calculations, then this will break the very idea of themization - the styles will not be uniform. So, how to limit them?

Computed variables

Computed variables link global and local variables. They act as a compromise between a large number of theme settings and arbitrary local transformations:


:root {
    /* global vars */
    --global-background: light-dark(#dedede, #676767);
    --global-radius: 16px;

    /* computed vars */
    --radius-s: calc(0.5 * var(--global-radius));
    --radius-m: var(--global-radius);
    --radius-l: calc(2 * var(--global-radius));

    --background-normal: var(--global-background);
    --background-dark: oklch(from var(--global-background) calc(l - 0.2) c h / alpha);
    --background-light: oklch(from var(--global-background) calc(l + 0.2) c h / alpha);
}

/* local vars */
@property --box-radius {
    syntax: "*";
    inherits: false;
}

@property --box-background {
    syntax: "*";
    inherits: false;
}

.box {
    --box-background: var(--background-normal);
    --box-radius: var(--radius-m);
    background: var(--box-background);
    border-radius: var(--box-radius);
}

.box-dark {
    --box-background: var(--background-dark);
}

.box-light {
    --box-background: var(--background-light);
}

.box-rad-s {
    --box-radius: var(--radius-s);
}

.box-rad-l {
    --box-radius: var(--radius-l);
}

Thus, our theme has only six variants for internal styles. Please note that now global and local variables do not interact directly - this is how we separate the external API of the theme and its internal implementation. We impose restrictions to make the styles predictable and uniform.

Final thoughts

I think using three layers of CSS variables makes it easier to customize theme and extend it. It looks like a kind of the Open-Closed Principle -
you can extend theme with new CSS rules and local variables but your global variables remain constant.

In the future the layer of computed variables can be implemented via @function at-rule. This will really protect them from being changed.

Of course, the possibilities of theming are much wider when using JavaScript, with the help of TypeScript, styling becomes more obvious., but that's a completely different story.

Enjoy your frontend development!

DEV Community: Marat Sabitov

CSS Art Challenge: I do love Chicken Pilaf!

Inspiration

Demo

Journey

EffCSS hydration: server work, client trust, zero waste

Runtime Emotion CSS: the selector is a hash of the style

Zero-runtime Vanilla Extract: the selector is a build-time constant

The pattern: style and selector are binded

EffCSS: style and selector are decoupled

Hydration is the payoff of the split

No more style recomputation, but still full dynamism

Same benefit for CSR

Key difference

Conclusion

EffCSS v5: Self-Confident CSS-in-TS for Modern Frontend

What Is EffCSS?

Core API in v5.3.0

Contract-first approach

1. Declare a Type Contract

2. Implement with attributes or classNames

3. Apply

Other utils

Key Strengths

When to Use EffCSS

When to Consider Alternatives

Final thoughts

Different shades of CSS-in-TS

CSS Modules + typed-css-modules

vanilla-extract

EffCSS

Conclusion

SVG animations with Friction

Export restrictions

Workflow

Conclusion

A journey into the world of animated SVGs

Pinia Alchemy

Meet Mr. Pearman

Animating Mr. Pearman

Conclusion

CSS only components

Initial styles

Thinking in React way

attr() will change all

Final thoughts

Useful TypeScript generics for tree structures

Deep partial

Paths

Nodes and Leaves

Conclusion

You don't need CSS preprocessor

Variables, Nesting, Operations and Scope

Mixins, Maps and Functions

At what cost?

Final thoughts

Bundle size badges are just numbers

Reason #1: bundle size !== package install size

Reason #2: bundle size !== feature-richness

Reason #3: bundle size !== code performance

Final thoughts

CSS @scope: advanced nesting

Myth #1: @scope fully isolates styles

Myth #2: @scope has the highest-priority

Myth #3: @scope is better to use with type selectors

@scope real power

Final thoughts

CSS @property: advanced theming

Local variables

Global variables

Computed variables

Final thoughts

2. Implement with `attributes` or `classNames`

`attr()` will change all

Myth #1: `@scope` fully isolates styles

Myth #2: `@scope` has the highest-priority

Myth #3: `@scope` is better to use with type selectors

`@scope` real power