Розробка · 14 квітня, 17:30 183

Дмитро Наумчук, Full Stack Technical Lead

Чому skeleton-и у 2026 все ще болять (і що з цим робити)

Привіт, спільното!

Хочу поділитись open-source інструментом, який зробив для себе і який, сподіваюсь, стане в нагоді іншим.

Якщо коротко: skeleton-и — це штука, яка всіма використовується, але майже ніким не любиться, як я зрозумів) Я давно працював з внутрішніми продуктами, і коли почав вникати в те, що відбувається зараз з публічними сайтами — здивувався від ситуації з підвантаженням даних. Бо по факту є лише 2 підходи:

1. Ручний

Типу react-loading-skeleton або компоненти з UI-китів.

Плюси:

швидко стартанути
зрозуміло Мінуси:
дублюєш layout
підтримуєш 2 версії UI
будь-яка зміна дизайну → правиш і skeleton

Виглядає як технічний борг, який росте разом з продуктом

2. Runtime генерація

Типу react-content-loader або wrapper-и, які аналізують DOM.

Плюси:

менше ручної роботи

Мінуси:

runtime cost
магія, яку складно контролювати
не дуже дружить з SSR / складними layout
іноді генерує «приблизно те», що треба

Що тут не так?

Обидва підходи працюють з наслідком, а не з причиною. Причина проста — skeleton не є частиною dev-процесу

Інший підхід (skeletal-ui)

Я для себе спробував перевернути це і зараз ділюсь з вами — зробити skeleton не runtime-фічею, а build/dev інструментом. Так зʼявився skeletal-ui

Це CLI-тулза, яка:

аналізує реальний UI (сторінку або компонент)
генерує статичний skeleton
який ти використовуєш як звичайний компонент

Що це дає на практиці

Було:

Component.tsx

SkeletonComponent.tsx

Стало:

Component.tsx
→ згенерований component.skeleton.tsx (1 раз)

І далі:

без runtime генерації
без дублювання руками
без магії

Чим це відрізняється від існуючих рішень

Підхід	Приклад	Коли генерується	Мінуси
Ручний	react-loading-skeleton	dev	дублювання
SVG	react-content-loader	dev	багато ручної роботи
Runtime	wrapper libs	runtime	перф / SSR
skeletal-ui	CLI	build/dev	(поки що early stage)

Де це має сенс

складні UI (дашборди, таблиці, адмінки)
SSR / Next.js / streaming
команди, де важлива швидкість змін

Висновок

Skeleton-и — це маленька деталь, яка дуже швидко стає великою проблемою. І поки більшість рішень оптимізують «як намалювати skeleton». Мені здалось цікавіше оптимізувати — як його взагалі не писати руками.

Я виклав це в open source, бо цікаво:
чи це тільки моя біль, чи є ще такі кейси

NPM: www.npmjs.com/package/skeletal-ui
Демо та доки: web-scavenger.github.io/skeletal

Якщо у вас є продакшн-кейси зі skeleton-ами — буде цікаво почути, як ви це вирішуєте. Ну і Сам проект, якщо зацікавив — пишіть, хочу його розвивати

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті

Теми: Open source, pet project, розробка

👍ПодобаєтьсяСподобалось0

До обраногоВ обраному0

Facebook

Twitter

Ctrl + Enter

Володимир Обрізан Засновник в Testinel 15.04.2026 12:41

Обидва підходи працюють з наслідком, а не з причиною.

Причина — це те що сервер не віддає усю сторінку або дані одразу за 50 мс. З такою швидкістю людина не помічає, що взагалі щось завантажується. Віддайте користувачу данні одразу без затримок.

Відповісти

Підтримати

Ярослав Характерник Golang Developer в DocHQ 15.04.2026 12:05

Ось такий побачив тиждень тому github.com/Aejkatappaja/phantom-ui на HN

import { useQuery } from "@tanstack/react-query";
import "@aejkatappaja/phantom-ui";

function UserProfile({ userId }: { userId: string }) {
  const { data: user, isLoading } = useQuery({
    queryKey: ["user", userId],
    queryFn: () => fetch(`/api/users/${userId}`).then((r) => r.json()),
  });

  return (
    <phantom-ui loading={isLoading}>
      <div className="card">
        <img src={user?.avatar ?? "/placeholder.png"} width="48" height="48" />
        <h3>{user?.name ?? "Placeholder Name"}</h3>
        <p>{user?.bio ?? "A short bio goes here."}</p>
      </div>
    </phantom-ui>
  );
}