Frontend Developer

🤣🤣🤣

Выпуск №509. Никита Дубко и Вадим Макеев про антивебные API для веба, как LLM и помогает, и убивает Tailwind и про нездоровую зависимость от бандлеров.

— Лайв на Ютубе
— Слушайте на Ютубе
— Ссылки на сайте

Всем привет!
Сегодня прослушала подкаст «Веб-стандарты» #509
и узнала для себя несколько новых и интересных вещей:

— Оказывается, существует специализированный браузер для веб-разработчиков, созданный именно для разработки и тестирования веб-сайтов, а не для обычного просмотра — Polypane
https://polypane.app/

— В подкасте обсуждали статью
https://polypane.app/blog/not-all-browser-apis-are-web-apis/
с говорящим названием о том, что не все браузерные API на самом деле являются «чисто браузерными».
Забавно, что API, которые мы всегда считали стандартными (например, Geolocation API, поддерживаемый и W3C, и MDN), для одних браузеров является платным, а для Chromium — нет.

— Слышали когда-нибудь про файл LLMs.txt?
Это Markdown-файл для сайтов, предназначенный для предоставления контента, удобного для LLM.
Одно из ключевых преимуществ — снижение нагрузки на сайт.
https://llmstxt.org/

— И тут становится ещё интереснее. Думаю, многие из вас слышали новость:
6 января основатель Tailwind CSS Адам Ватан уволил 3 из 4 разработчиков из-за, цитирую, «жестокого влияния AI на наш бизнес».
Он подробно описал ситуацию в треде на GitHub, отклонив pull request с предложением сделать документацию, оптимизированную под нейросети:
https://github.com/tailwindlabs/tailwindcss.com/pull/2388#issuecomment-3717222957

> Трафик на нашу документацию упал примерно на 40% с начала 2023 года, несмотря на то, что Tailwind популярнее, чем когда-либо. Документация — это единственный способ, которым люди узнают о наших коммерческих продуктах, а без клиентов мы не можем позволить себе поддерживать фреймворк.

Подробности тут:
https://dev.to/kniraj/tailwind-css-lays-off-75-of-engineering-team-as-ai-tools-disrupt-revenue-model-1l3d

— К слову, трафик MDN тоже снизился — во многом из-за активного использования LLM.

— В подкасте обсуждали ещё одну статью, но я хочу сначала внимательно её прочитать и уже потом поделиться своими мыслями.

В целом подкаст мне очень понравился, интересно было следить за дискуссией ребят, поэтому я решила сразу поддержать их на Patreon 💙
Ниже будет репост этого выпуска 🎧

🎄 Advent of JavaScript

https://adventjs.dev/

Что это такое:

* 24 дня — 24 задачи на JavaScript / TypeScript / Python
* уровень задач от простых до реально сложных
* отлично прокачивает алгоритмы и логику
* и да, это бесплатно) пользуйтесь)

💡 Идеальный программист

Навыки, которые присущи идеальному разработчику! 😍

Спустя долгое время в разработке я для себя вывела набор качеств, которые реально делают программиста крутым. И вот какие навыки я считаю самыми важными:

1️⃣ Умение не просто выполнять то, что написано в задаче, а понимать — нужно ли это вообще?
Продуктивность не измеряется количеством написанных строк кода.

2️⃣ Умение понятно излагать свои мысли
(в переписке, на созвонах, на ревью — где угодно)

3️⃣ Иметь свою точку зрения и уметь аргументировать её

4️⃣ Быть командным игроком и понимать, что у всех разный уровень
и это нормально 🙌

5️⃣ Постоянно развивать свои навыки и не терять энтузиазм к работе 🔥

А вы что думаете по этому поводу?

Всем привет!
Наткнулась в интернете на статью, где автор делится вопросами, которые ему задавали на интервью в Amazon

Вопросы, которые задавали:

1. Что такое aria-label, aria-labelledby, aria-live — и для чего они нужны?
2. В чём разница между тегом <header> и заголовками <h1>…<h6>?
3. Что такое семантические классы и семантическое именование классов?
4. Каков будет вывод этого JavaScript-кода? (код про event loop)
5. Как «расплющить» (flatten) массив без array.flat()?
6. Реализация компонента Star Rating на React

Главные инсайты:

🔹 Никогда не недооценивайте базу. Даже если вы отлично работаете с React — важно помнить основы языка.

🔹 Коммуникация — это навык. Умение объяснить, *почему* вы делаете так, а не иначе, не менее важно, чем написать рабочий код.

🔹 Провал — это не приговор. Одно неудачное собеседование не определяет вашу ценность.

Если вам интересно — можете почитать оригинал: https://ujjwal3009.medium.com/frontend-developer-interview-amazon-f61e780add81

Начинаем открывать адвент календари.

Ежегодный адвент-календарь о web performance: новые статьи, практики оптимизации, case-studies от инженеров крупных компаний.
https://calendar.perfplanet.com/2025/

Адвент-календарь с анти-паттернами HTML, забавными (и полезными) примерами того, как *не* стоит верстать. Каждый день — новая статья.
https://htmhell.dev/adventcalendar/

Самый популярный адвент-календарь по алгоритмам и программированию: ежедневно выходят интересные задачки разных уровней сложности.
https://adventofcode.com/

Ежедневные снипеты о современной CSS-разработке.
https://cssadventcalendar.dev

Адвент-календарь, посвящённый accessibility: практики, паттерны и методы создания доступных интерфейсов.
https://manuelsanchezdev.com/advent-2025

Как браузер обрабатывает <script> при построении DOM-дерева? 🧐

Когда браузер разбирает HTML, встречающиеся теги <script> могут блокировать дальнейшее построение DOM, что влияет на производительность страницы. И вот как это работает:

1️⃣ Синхронные скрипты (<script>, без async или defer) — блокируют построение DOM до своей загрузки и выполнения. Это замедляет рендеринг страницы.

2️⃣ Асинхронные скрипты (async) агружаются параллельно с HTML, но выполняются сразу, как только файл загружен. Порядок их выполнения непредсказуем и может прервать рендеринг страницы.

3️⃣ Скрипты с defer загружаются параллельно, но выполняются после полного парсинга HTML, в том же порядке, в котором они встречаются в документе.

4️⃣ Модульные скрипты (type="module") загружаются как defer, но имеют строгий режим и поддерживают import/export. Они выполняются после загрузки HTML и поддерживают top-level await.

5️⃣ Динамические скрипты (через document.createElement('script')) ведут себя как async по умолчанию.

👩‍🎓 Немного рекомендаций:

✔️ Используй defer для большинства скриптов, чтобы они не блокировали рендеринг;

✔️ Для независимых скриптов (например, аналитики) используй async;

✔️ Минимизируй количество синхронных скриптов в <head> — это замедляет загрузку страницы.

И помним, скрипты могут блокировать не только DOM, но и рендеринг страницы, влияя на скорость загрузки и пользовательский опыт, поэтому правильное использование async и defer ускоряет загрузку и рендеринг. 👍

Привет! ✨
Собрала полезные материалы для фронтендеров:

1. https://bespoyasov.ru/front-not-pain/
«Фронтенд — это не больно!» — статьи о том, как фронтендеру работать без стресса: взаимодействовать с дизайнерами, бэкендерами и тестировщиками, бороться с рутиной и выгоранием, организовывать рабочий процесс.

2. https://solidbook.vercel.app/
Подробная книга о принципах SOLID. Помогает разобраться, как строить гибкую, предсказуемую и поддерживаемую архитектуру.

3. https://www.patterns.dev/vanilla/module-pattern/
Большая коллекция популярных паттернов разработки в JavaScript, объяснённых просто и визуально. В том числе модульный паттерн и многие другие.

4. https://refactor-like-a-superhero.vercel.app/ru
Практическое руководство по рефакторингу. Чёткие советы, примеры и техники, которые помогают улучшать код без боли и риска всё сломать.

5. https://www.youtube.com/playlist?list=PLaIuVNKRYUyEoKnY0UwapHPk8fEaREHPA
Подробный видеокурс по Figma. По мне часто фронтендеру не хватает этого навыка даже в базовом виде.

Это не было бы так смешно, если бы не было правдой 😄
К сожалению, многие фронты порой настолько зациклены на том, чтобы просто сделать «работающий код», что забывают о «хороших манерах» — например, о том, что не только 200 считается успешным результатом. Есть ещё 201, 204 и другие кейсы ✅

И вообще, помимо привычных 200, 400, 404 и 500, существует множество других статус-кодов, которые могут значительно упростить логику на фронте и сделать API более понятным.

Я уже как-то писала пост с HTTP Code Cheatsheet — можете обратить внимание 👇
https://t.me/frontenddevelopernews/60

Всем привет! 👋

Работая почти 10 лет в разработке, всё чаще замечаю, что многие фронтендеры приходят в профессию без формального IT-образования. Недавно наткнулась на статью, где автор — тоже без классического CS-бэкграунда — делится принципами, которые помогают ему принимать правильные решения «здесь и сейчас».

Мне, человеку с бакалавриатом и магистратурой, было особенно интересно почитать, что же он там написал 🙂

---

🧩 Про «умные» принципы, которые иногда только мешают

Автор пишет, что популярные советы вроде
YAGNI (You Aren’t Gonna Need It),
DRY (Don’t Repeat Yourself)
и «преждевременная оптимизация — корень всех зол»
звучат умно, но в реальной жизни часто создают больше путаницы.

И вот принцип, который действительно помогает ему в работе — правило трёх.

---

📌 Правило трёх

Рефакторить или оптимизировать код стоит только после того, как вы написали его три раза:

1️⃣ Первый раз — просто пишете код, который делает только то, что нужно.
2️⃣ Второй раз — появляется та же логика, и вы буквально копируете её, немного адаптируя.
3️⃣ Третий раз — у вас уже три подобные реализации, и теперь ясно, что обобщать, как упрощать и какой уровень абстракции действительно нужен.

Зачем так делать?
Потому что после трёх повторений вы уже точно знаете:

* что в логике действительно общее,
* что можно упростить,
* какой абстракции хватает,
* и не уйдёте в ненужный оверинжиниринг.

---

⚙️ Принцип «Make it work → Make it right → Make it fast»

Очень хочется оптимизировать всё сразу — но быстрый код часто менее читаемый.

Кент Бек предлагает простой порядок:

🔹 Работает? Если нет — сначала добейтесь этого.
🔹 Делает правильно? Если нет — исправьте логику, входы, поведение.
🔹 Достаточно быстро? Если нет — вот теперь можно оптимизировать.

Смысл простой: нет смысла улучшать код, который пока даже не работает или работает неправильно.

---

✔️ Как итог

Хорошие принципы помогают писать код, который:

* легко читать,
* легко понимать,
* легко изменять,
* легко тестировать.

А плохой код «плох по-разному»: слишком много ответственности, мешанина уровней абстракций, странные оптимизации, лишняя логика.

---

Ссылка на статью:
https://piccalil.li/blog/programming-principles-for-self-taught-front-end-developers/

Вообще, как по мне, разработчики — самые ленивые люди на свете 😄 Не зря же мы через свои приложения пытаемся упростить жизнь людям.

Когда я наткнулась на статью «Ultimate Prompts for Every Developer», сразу стало интересно: "какие там такие промпты, которые действительно полезны в работе?"

Собрала для вас короткую подборку самых практичных — их можно просто копировать и использовать при необходимости 👇

---

1️⃣ Фреймворк для рефакторинга и оптимизации

I have a [language] function in a [framework] project that needs refactoring.

Current code:
[paste code]

Issues I'd like to address:
[specific issue, e.g., low readability]
[specific issue, e.g., non-optimal O(n^2) time complexity]

What I've considered:
[ideas you've already tried]

Constraints:
[must remain backward compatible, no new dependencies]

Please suggest refactored code with explanations,
including trade-offs and potential edge cases.

2️⃣ Code Review от трёх «персон»

Please review this code from three different perspectives:

1. Security specialist:
   - Identify vulnerabilities / injection risks
   - Mention any OWASP Top 10 concerns

2. Performance engineer:
   - Highlight inefficiencies or bottlenecks
   - Suggest better data structures or algorithms

3. Maintainability expert:
   - Point out unclear naming / complex logic
   - Suggest improvements for testability and structure

CONTEXT:
- Tech stack: [React/Node/TS]
- Constraints: [e.g., no new dependencies]

CODE:
[YOUR CODE]

3️⃣ Постепенное проектирование API

I'm designing a RESTful API for a [SPECIFIC DOMAIN] system.
Let's develop this progressively:

STAGE 1: Core resources
- Define resources + relationships
- Primary attributes
- Basic CRUD

STAGE 2: Interaction patterns
- Non-CRUD endpoints
- Filtering, sorting, pagination

STAGE 3: Advanced
- Auth & permissions
- Rate limiting
- Versioning
- Caching (ETag, directives)
- Error format standardization

STAGE 4: Documentation
- Generate OpenAPI spec
- Provide request/response examples

4️⃣ Документация по компоненту/модулю

Generate comprehensive developer documentation for this [FUNCTION/COMPONENT/MODULE]:

[YOUR CODE]

Structure the documentation as follows:

1. OVERVIEW
   - Purpose, functionality, when to use

2. TECH SPECS
   - API, params, return values, types
   - State management (if applicable)
   - Events

3. EXAMPLES
   - Basic example
   - Advanced usage
   - Customization cases

4. TROUBLESHOOTING
   - Common errors
   - Debugging tips
   - Performance considerations

5. RELATED COMPONENTS
   - Dependencies
   - Components frequently used together

---

Полный список из 11 промптов — по ссылке 👇
https://medium.com/@onix_react/ultimate-prompts-for-every-developer-031a6d26a569

Жиза 😂😂😂

💡 Недавно наткнулась на очень полезную статью про 10 недооценённых фич JavaScript

и вот что я там обнаружила 👇

1️⃣ Использование Set для удаления дубликатов и быстрых проверок.
2️⃣ Методы Object.entries() и Object.fromEntries() для преобразования объектов.
3️⃣ Операторы ?? (nullish coalescing) и ??= — более безопасные дефолты по сравнению с ||.
4️⃣ Интернационализация через Intl — форматирование чисел, валют, дат.
5️⃣ IntersectionObserver для ленивой загрузки изображений и бесконечной прокрутки.
6️⃣ Promise.allSettled() для обработки набора промисов, когда нужно дождаться всех, даже если некоторые завершились с ошибкой.
7️⃣ Метод Element.closest() для надёжного поиска в DOM вверх по дереву.
8️⃣ Классы URL и URLSearchParams — работа с URL без регулярных выражений.
9️⃣ Цикл for…of — итерации с поддержкой итераторов и возможностью прерывания.
🔟 Топ-уровневый await (top-level await) — позволяет работать с асинхронным кодом в модулях без обёрток.

📖 Подробнее читай в статье:
👉 https://jsdev.space/underrated-js-features/

🌟 Site of the Day — Nov 10, 2025
https://www.awwwards.com/sites/messenger

💬 Представляю вам сайт дня — Messenger от студии Abeto.

🔗 Ссылка на сам сайт:
https://messenger.abeto.co/

🚀 Вышел Storybook 10!

Крупный релиз популярного инструмента для разработки и документирования UI-компонентов.
Главное изменение — переход Storybook на формат ECMAScript Modules (ESM-only).
Это делает проект современнее, ускоряет установку и уменьшает вес зависимостей,
но требует внимания при обновлении — это breaking change.
🧭 Гайд по миграции: https://storybook.js.org/docs/releases/migration-guide-from-older-version

📘 Подробнее о релизе и всех нововведениях:
https://storybook.js.org/releases/10.0

P.S. я уже как-то писала о том

В чём же разница между CommonJS и ES Modules? - https://t.me/frontenddevelopernews/4
Как вообще уживаются вместе .cjs, .mjs и .js файлы в одном проекте? - https://t.me/frontenddevelopernews/5

😭😭😭🤣🤣🤣

💡 Давайте решим лёгкую задачку:
https://bigfrontend.dev/typescript/implement-Pick-T-K

По моим наблюдениям, многие фронтендеры не всегда до конца знают TypeScript.
Базовые вещи — да 😊, а вот если копнуть чуть глубже, то многие теряются!

---

📘 Условие задачи:

Реализуйте тип MyPick<T, K> самостоятельно.

type Foo = {
  a: string
  b: number
  c: boolean
}

type A = MyPick<Foo, 'a' | 'b'> // { a: string, b: number }
type B = MyPick<Foo, 'c'>       // { c: boolean }
type C = MyPick<Foo, 'd'>       // Ошибка

Использовать встроенный Pick<T, K> — нельзя 🚫

---

🧠 Чтобы решить задачу, нужно вспомнить две вещи:

1. оператор keyof - https://www.typescriptlang.org/docs/handbook/2/keyof-types.html
2. наследование с помощью extends

Тип MyPick принимает:

* первый аргумент — исходный тип T
* второй — K, который может быть только ключом из T

---

✅ Решение:

type MyPick<T, K extends keyof T> = {
  [P in K]: T[P]
}

Так мы получаем новый тип, содержащий только нужные ключи и их типы 👌

🔗 Your URL Is Your State

Недавно наткнулась на статью:
https://alfy.blog/2025/10/31/your-url-is-your-state.html

В ней — простая, но почти забытая философия:
в погоне за фреймворками и глобальными сторами мы перестали ценить то, что веб умел с самого начала — хранить состояние прямо в URL-е.

Хорошо спроектированный URL — это контракт между приложением и пользователем.
Он описывает смысл, сохраняет контекст и делает взаимодействие предсказуемым.

🧭 Когда стоит хранить состояние в URL:
✅ поисковые запросы, фильтры, сортировки, даты, активные вкладки, режимы просмотра
❌ пароли, личные данные, временные состояния, слишком большие объекты

💡 Лучшие практики:
• Делайте параметры читаемыми и последовательными (?theme=dark&page=2)
• Используйте pushState для навигации, replaceState — для мелких обновлений
• Не храните чувствительные данные
• Избегайте чрезмерно длинных или зашифрованных ссылок

📖 В общем, очень советую прочитать статью —
и вспомнить, насколько элегантным может быть веб, если не усложнять то, что уже давно работает идеально.