Разница между isNaN и Number.isNaN заключается в их поведении при проверке значений, которые нельзя преобразовать в число.

🔹 isNaN(value)
• Преобразует переданное значение в число, а затем проверяет, является ли оно NaN.
• Из-за приведения типов isNaN('abc') сначала пытается преобразовать строку 'abc' в число, получает NaN, а затем проверяет isNaN(NaN), что дает true.

🔹 Number.isNaN(value)
• Проверяет только те значения, которые уже являются NaN без преобразования типов.
• 'abc' не является NaN, а просто строка, поэтому Number.isNaN('abc') возвращает false.

🔥 Разница в работе:

console.log(isNaN('abc')); // true  (так как 'abc' → NaN)
console.log(Number.isNaN('abc')); // false (так как 'abc' не является NaN)

📌 Вывод:
• isNaN менее строгий и преобразует входные данные.
• Number.isNaN более строгий и проверяет только NaN без преобразования.

9 законов, которые избавят тебя от боли в коде и хаоса в команде

Почему стоит их знать?

Потому что эти правила проверены десятками лет, сотнями проектов и тысячами разработчиков. Они помогают писать код проще, управлять проектами спокойнее и не наступать на чужие грабли.

1️⃣ Закон Парето
20% усилий дают 80% результата. Сосредоточься на главном.

2️⃣ Закон Гудхарта
Когда метрики становятся целью, они теряют смысл. KPI ≠ продуктивность.

3️⃣ Закон Конвея
Архитектура повторяет структуру команды. Бардак в команде = бардак в коде.

4️⃣ Закон Питера
Топовый дев ≠ топовый тимлид. Хард- и софт-скиллы — разные вселенные.

5️⃣ Закон Брукса
Больше разработчиков ≠ быстрее. Координация съедает время.

6️⃣ Закон Хайрама
Если у API много пользователей — кто-то точно начнёт использовать баг как фичу. Потом не отвяжешься.

7️⃣ Закон Линуса
Чем больше глаз смотрит на код — тем быстрее найдутся баги. Спасибо, опенсорс.

8️⃣ Закон Кернигана
Сложный код — отложенная боль. Пиши просто, не геройствуй.

9️⃣ Закон Хофтшадтера
Даже если думаешь, что учёл задержки — не учёл. Всегда добавляй буфер.

Использование as в TypeScript — это type assertion (уточнение типа). Хотя это мощный инструмент, у него есть несколько минусов и подводных камней, особенно при неправильном использовании:

❌ 1. Игнорирование реального типа

const value = "hello" as number;

➡️ TypeScript "поверит" вам, что это number, но на самом деле это строка. Это может привести к ошибкам во время выполнения, особенно если вы используете тип не по назначению.

❌ 2. Скрытие ошибок

const user = getUser() as AdminUser;

➡️ Даже если getUser() возвращает GuestUser, компилятор не проверит это, и вы потеряете типовую безопасность.

❌ 3. Сложности с рефакторингом
Если вы используете as повсеместно, IDE и инструменты анализа кода теряют возможность правильно находить ошибки типов при изменениях в коде.

❌ 4. "Двойное" приведение типа — потенциально опасно

const input = "123" as unknown as number;

➡️ Часто используется для обхода ограничений компилятора, но абсолютно небезопасно. Это способ сказать TypeScript: "я знаю, что делаю", но чаще всего — вы не знаете.

❌ 5. Труднее читать и поддерживать
При большом количестве as в коде:
• Сложнее понять, откуда и почему у значения появился тот или иной тип.
• Новому разработчику трудно доверять таким местам в коде.

✅ Когда as допустим:
• Приведение DOM-элементов:

const input = document.querySelector('input') as HTMLInputElement;

• Ситуации, когда TypeScript не может вывести тип, а вы уверены в структуре данных.
• Работа с unknown:

const data = JSON.parse(json) as MyType;

🧠 Альтернатива: Type Guards
Вместо as, по возможности, используйте type guards:

function isAdmin(user: User): user is Admin {
  return (user as Admin).role === 'admin';
}

Использование as должно быть осознанным исключением, а не повседневной практикой.

удалил(-а) Вас из группы

🧠 Web Worker в JavaScript — как запустить многопоточность в браузере

JavaScript — однопоточный, но бывают задачи, которые нагружают главный поток: парсинг больших данных, сложные расчёты и т.п. Чтобы не вешать интерфейс — можно использовать Web Worker!

👷‍♂️ Кто такой Web Worker?
Это отдельный поток, в котором можно запускать JS-код параллельно с основным. Он не имеет доступа к DOM, но может общаться с основным потоком через сообщения.

📦 Пример:
Файл: worker.js

// worker.js
self.onmessage = function (e) {
  const result = e.data * 2;
  self.postMessage(result);
};

Файл: main.js

const worker = new Worker('worker.js');

worker.postMessage(10);

worker.onmessage = function (e) {
  console.log('Результат от воркера:', e.data); // 20
};

🔐 Ограничения:
• Нет доступа к window, document, localStorage и т.п.
• Нельзя напрямую взаимодействовать с DOM
• Работает только с отдельными файлами (или blob'ами)

⚙️ Когда использовать?
✅ Долгие вычисления (например, графика, криптография)
✅ Парсинг больших JSON или CSV
✅ Работа с оффлайн данными или IndexedDB

🕸 DOM — что это такое и какие его бывают типы?
Ты слышал про DOM, Shadow DOM, Virtual DOM, Light DOM... но что это всё значит? Давай разложим по полочкам.

📖 Что такое DOM?
DOM (Document Object Model) — это объектная модель документа.
Когда ты открываешь HTML-страницу в браузере, она превращается в структуру объектов, с которыми можно взаимодействовать через JavaScript.

Каждый HTML-элемент становится узлом дерева DOM, и ты можешь:
• Добавлять/удалять элементы (appendChild, removeChild)
• Менять текст и атрибуты (textContent, setAttribute)
• Реагировать на события (addEventListener)

👉 Это фундамент всей клиентской части фронтенда.

🧩 Основные типы DOM и где они применяются:
🔹 1. HTML DOM — базовый, реальный DOM
Это та модель, которую создаёт браузер из HTML-документа.
С ним ты работаешь ежедневно:

document.querySelector('button').addEventListener('click', () => {
  alert('Привет, DOM!');
});

🔸 Доступ к элементам, атрибутам, тексту
🔸 Изменение структуры страницы
🔸 Добавление и удаление узлов

HTML DOM — это именно то, что ты видишь в инструментах разработчика в браузере (Elements).


🔹 2. XML DOM — работа с XML-структурами
DOM применим не только к HTML. Например, если ты получаешь XML-файл (например, SVG или RSS), ты тоже можешь "обходить" его как дерево.

const parser = new DOMParser();
const xml = parser.parseFromString(xmlString, "application/xml");
console.log(xml.getElementsByTagName('title')[0].textContent);

📌 XML DOM работает так же, как HTML DOM, но с XML-документами.

🔹 3. Virtual DOM — концепт из фреймворков
Это не настоящий DOM, а его копия в памяти.

📌 Фреймворки вроде React, Vue, Preact создают Virtual DOM, чтобы не трогать реальный DOM напрямую.

Как это работает:
1. Рендер компонента создаёт виртуальное дерево
2. Когда данные меняются, создаётся новое дерево
3.. Сравниваются старое и новое → браузеру отправляется минимум изменений

🔧 Это ускоряет перерисовку, особенно при большом количестве элементов.

❗️ Важно: Virtual DOM — это внутренний механизм фреймворка, в браузере его нет.

🔹 4. Shadow DOM — скрытый DOM
Это способ инкапсуляции, введённый вместе с Web Components.

const el = document.querySelector('my-widget');
const shadow = el.attachShadow({ mode: 'open' });
shadow.innerHTML = `<style>p { color: red; }</style><p>Привет</p>`;

Преимущества:
• 🔒 Полная изоляция стилей и структуры
• ✅ Никакие внешние CSS не затрагивают Shadow DOM
• 👀 Используется в <video>, <input type="range">, Web Components

📌 mode: 'open' позволяет получить доступ к shadowRoot, а 'closed' — нет.

🔹 5. Light DOM — то, что вставляется через <slot>
Когда ты используешь Web Component и в него передаёшь контент — этот контент называется Light DOM.

<my-box>
  <p>Я — в Light DOM</p>
</my-box>

А внутри my-box:

<slot></slot>

Light DOM существует вне Shadow DOM, но может быть вставлен внутрь через <slot>.

🔹 6. DOM Tree (дерево узлов)
DOM состоит из узлов (nodes):
• document – корень
• element – HTML-теги
• text – текст между тегами
• comment – <!-- комментарии -->
• attribute – id, class и др. (доступны через .getAttribute())

Это дерево, и ты можешь перемещаться по нему:
parentNode, childNodes, nextSibling, firstElementChild и т.д.

В прошлом посте упоминались Web Components, я хочу рассказать о них подробнее!

Web Components — это нативный способ создавать переиспользуемые, инкапсулированные элементы прямо на чистом JavaScript, без привязки к фреймворкам.

⚙️ Что такое Web Components?
Состоит из трёх ключевых технологий:
1. Custom Elements — создание своих HTML-тегов
2. Shadow DOM — инкапсуляция структуры и стилей
3. HTML Templates — шаблоны с отложенным рендерингом

Пример:

class MyTag extends HTMLElement {
  connectedCallback() {
    this.attachShadow({ mode: 'open' });
    this.shadowRoot.innerHTML = `<p>Привет из компонента!</p>`;
  }
}
customElements.define('my-tag', MyTag);

Теперь ты можешь использовать <my-tag></my-tag> как обычный HTML-элемент.

✅ Плюсы Web Components
🔹 Фреймворк-независимость — работают в любом проекте: React, Vue, Angular или просто HTML
🔹 Изоляция — стили и структура компонента защищены через Shadow DOM
🔹 Гибкость в использовании — можно зашарить компонент через CDN или npm
🔹 Поддержка браузерами — почти все современные браузеры (включая Safari и Edge)
🔹 Идеально для UI-библиотек и виджетов — калькуляторы, формы, кнопки, карты, чаты

🚨 На что обратить внимание
🔍 Не пытайся встроить Web Components в SPA без нужды — в React/Vue уже есть свои системы компонентов, они эффективнее внутри экосистемы

🧪 Тестируй кроссбраузерность — особенно если используешь slot, form-associated custom elements или adoptedStyleSheets

📦 Для сложных компонентов лучше использовать библиотеки-обёртки, например:

• Lit — удобный синтаксис
• Stencil — компилятор, создающий Web Components с возможностью SSR
• Haunted — Web Components + Hooks

Web Components — это не замена фреймворкам, а инструмент. И если использовать его по назначению — это мощная технология:

✅ Пишите компонент один раз → используйте везде
✅ Минимум зависимостей
✅ Идеальны для SDK и внешних виджетов

🚧 Рабочие будни: микрофронты, Astro и новая идея

В последнее время я плотно работаю с Astro — фреймворком, который позволяет миксовать всё, что угодно. У меня в проекте сейчас одновременно используются и React, и Vue, и всё это работает как микрофронтенды внутри одного приложения.

⚙️ Это гибко, но на практике возникает куча проблем:
— нужен UI-kit, который будет одинаково работать во всех фреймворках
— хочется реактивность
— хочется инкапсуляцию и лёгкость переиспользования
— и при этом — минимум зависимости от среды

🧠 Поэтому я решил собрать свой UI-kit, основанный на следующих технологиях:

✅ 💡 Lit — для генерации Web Components с реактивностью и Shadow DOM
✅ 🎨 PostCSS — для трансформации и оптимизации стилей (плагины, кастомизация, минификация)
✅ 🧠 Partytown — чтобы переносить тяжёлые вычисления в Web Workers, разгружая главный поток

📦 В результате я хочу получить:
— Нативные веб-компоненты, работающие в React/Vue/HTML
— Стили, изолированные через Shadow DOM и оптимизированные через PostCSS
— Возможность легко встраивать эти компоненты в любую среду без боевой зависимости от фреймворка
— И, конечно, быструю загрузку и отзывчивость за счёт Partytown

Если тебе интересна тема UI-kit без фреймворк-зависимости, реактивных веб-компонентов, или хочешь следить за тем, как я это буду собирать — напиши в комменты, задавай вопросы и я в будущем оформлю по этой теме новые посты🔥

🛠 Почему я выбрал Astro для SSR

Когда я начал думать о серверном рендеринге (SSR) в своём проекте, выбор стоял между классическими решениями вроде Next.js, Nuxt, а также более лёгкими альтернативами.

🔍 После долгих тестов и сравнений я остановился на Astro. Вот почему:

✅ 1. Истинный Island Architecture
Astro по-настоящему рендерит только то, что нужно.
Компоненты по умолчанию — это просто HTML без JS на клиенте. Хочешь интерактивность? Подключай client:load, client:idle, client:visible — всё под контролем.

Это даёт:
— Меньше JavaScript на клиенте
— Мгновенную отрисовку (zero-js для части контента)
— Отличную производительность из коробки


⚙️ 2. SSR без боли
Astro позволяет включить SSR буквально одной настройкой. Всё работает на Vite, поддерживает адаптеры под любую платформу: Node, Deno, Edge, Vercel, Cloudflare Workers.

Ты пишешь как будто SPA, но получаешь всё, что нужно для SEO и скорости:
— Серверный рендеринг
— Стриминг
— Пререндеринг
— Кэширование

🧩 3. Полная свобода компонентов
Astro позволяет использовать любой фреймворк внутри проекта:
🔹 React
🔹 Vue
🔹 Svelte
🔹 Solid
🔹 Web Components

Можно собирать микрофронты, не переписывая ничего с нуля. У меня в проекте React и Vue живут рядом — и это не вызывает боли.

🧼 4. Простота + мощь
Astro не нагружен абстракциями. Он очень чистый и понятный:
— минимальная настройка
— файлы .astro читаются легко
— всё работает быстро и стабильно

📌 Итог:
Я выбрал Astro, потому что он:
✅ делает SSR проще
✅ уменьшает клиентский JS
✅ даёт контроль и гибкость
✅ не заставляет выбирать один фреймворк

🌐 Проблема современной фронтенд-индустрии

Мы пришли к странной точке: чтобы отрендерить пару кнопок и табов — мы тащим React, Router, Redux, Tailwind, MUI, Query, Zustand, i18n, Formik и ещё десяток обвязок поверх этого всего.

📦 Каждый новый проект начинается не с разработки, а с выбора стека из 20 npm-пакетов.
🧩 Компоненты завязаны на фреймворки.
🐘 Проекты быстро разрастаются, сложны в поддержке и часто зависят от устаревших библиотек.

🔁 Я решил двигаться в обратную сторону.

Моя цель — вернуться к корням:
✅ меньше зависимостей
✅ больше контроля
✅ меньше магии — больше прозрачности

🛠 Как я это делаю:
Я использую Astro как базу, потому что он:

— отлично справляется с SSR
— поддерживает HTML-first подход
— позволяет использовать любой фреймворк, но не заставляет
— работает с чистой ванилой и Web Components без боли

🏗 План:

1. Писать компоненты как Web Components на Lit
2. Использовать PostCSS для стилизации вместо Tailwind и UI-фреймворков
3. Постепенно отказываться от React и Vue
4. Использовать Partytown, чтобы тяжёлые операции не трогали главный поток
5. Держать код максимально лёгким, понятным и кросс-фреймворк-френдли

🧠 Это не "анти-фреймворковая" позиция.
Я просто считаю, что фреймворк должен быть инструментом, а не фундаментом всего.
А сейчас у многих проектов — полная зависимость от того, на чём они начали.

🎯 Почему важно использовать web.dev/baseline

Разработка для веба — это всегда компромисс: хочется использовать новейшие фичи, но нужно поддерживать старые браузеры. Раньше приходилось гуглить поддержку каждой API вручную. Теперь есть Baseline.

🧩 Что такое Baseline?
Это инициатива от Google, которая помогает понять: какие фичи HTML, CSS и JS можно использовать без страха, потому что они стабильно работают в большинстве актуальных браузеров.

💡 Преимущества использования Baseline:

🔍 Чёткие метки в MDN и caniuse: теперь ты увидишь, входит ли API в "Baseline" прямо на странице документации.

📅 Упрощение поддержки: можно целиться в "Baseline 2022" или "2024" — это значит, что фичи стабильно поддерживаются браузерами, обновлёнными после соответствующего года.

🔧 Осознанный выбор технологий: ты не просто вслепую добавляешь :has() или View Transitions API, а знаешь, что они реально работают у большинства пользователей.

🛠 Пример:
Если ты хочешь использовать :has() в CSS — проверь, входит ли она в Baseline текущего года. Если нет — подожди или добавь graceful degradation.

📌 Итог:
Используй web.dev/baseline, чтобы меньше гадать и больше создавать. Это инструмент для уверенных решений и стабильных интерфейсов.

P.s вот ссылка которая должна вам помочь подготовить окружение.

🧹 Lintинг в фронтенде: что использовать для JS, TS, HTML и CSS?

Чистый код — это не только про стиль, но и про производительность и поддержку. Вот актуальные линтеры, которые стоит использовать:

📦 JavaScript и TypeScript
🔧 ESLint — стандарт индустрии.
Поддерживает как JS, так и TS (через @typescript-eslint/parser и @typescript-eslint/eslint-plugin).
Сотни готовых правил + возможность писать свои.

🧱 HTML
🔧 html-eslint
Обёртка над ESLint, которая позволяет линтить HTML как будто это JS-абстракция.
Поддерживает правила вроде обязательного alt, запрета inline styles и т.д.

🎨 CSS
🔧 stylelint
Долгое время был основным инструментом для линтинга CSS, SCSS, Less и даже встроенных стилей.

❗️НО! ESLint недавно добавил официальную поддержку CSS через eslint-plugin-css (aka css-eslint).

Это значит, что можно использовать единый инструмент (ESLint) для всего фронтенда: JS, TS, HTML, CSS.

➡️ Уже стоит рассматривать css-eslint как замену stylelint — особенно для новых проектов.

📌 Итог:
Один ESLint способен покрыть весь ваш стек.Это упрощает конфигурацию, снижает количество зависимостей и улучшает DX.