💡 Ошибки с async/await в JavaScript

Асинхронный код в JavaScript стал проще с появлением async/await, но у него есть коварная ловушка: ошибки в промисах могут «утекать» и не обрабатываться. Это приводит к UnhandledPromiseRejection, который проявляется далеко не сразу и часто маскирует настоящую причину бага.

Решение — всегда оборачивать асинхронный код в обработку ошибок. На уровне функции это try/catch:

async function fetchData(url) {
  try {
    const res = await fetch(url)
    if (!res.ok) {
      throw new Error(`HTTP error: ${res.status}`)
    }
    return await res.json()
  } catch (err) {
    console.error("Ошибка при получении данных:", err)
    throw err // пробрасываем выше, если нужно
  }
}

Но есть нюансы:
– Локальный try/catch хорош для точечной обработки (например, показать пользователю алерт).
– Глобальная обработка нужна для неожиданных ошибок: в браузере это window.onunhandledrejection, в Node.js — process.on('unhandledRejection').
– Параллельные вызовы лучше обрабатывать через Promise.allSettled(), чтобы ошибка одного промиса не обрушала весь батч.

🙈 Ловушки двойного равенства в JavaScript

Одна из самых частых проблем в JavaScript — неочевидные результаты сравнения с помощью ==. Алгоритм абстрактного сравнения (Abstract Equality Comparison) приводит типы «на лету», из-за чего код может вести себя неожиданно:

0 == false    // true
'' == false   // true
[0] == false  // true (!)

В реальных проектах это часто превращается в баги при проверке пользовательского ввода или данных из API.

Решение — использовать строгое сравнение ===, которое сравнивает и значение, и тип:

0 === false   // false
'' === false  // false
[0] === false // false

Нюансы:
– Валидацию входных данных всё равно нужно делать вручную: === не спасёт, если вы сравниваете строку "42" и число 42.
– Иногда == может быть уместным (например, при проверке на null и undefined одновременно: value == null). Но такие кейсы стоит явно документировать, чтобы не путать коллег.
– Линтеры вроде ESLint (eqeqeq: "error") позволяют сразу исключить двусмысленное сравнение на уровне правил проекта.

🤔 Почему браузеры ограничивают JavaScript таймеры?

Команда JavaScript for Devs подготовила перевод статьи о том, почему браузеры намеренно замедляют выполнение setTimeout и других таймеров.

Автор объясняет, как это связано с защитой пользователей, рассказывает о своём бенчмарке разных подходов (setTimeout, MessageChannel, scheduler.postTask) и делает прогноз, какие таймеры будут использоваться в будущем.

📚 Подробности на Хабр: https://habr.com/ru/articles/945872/

🫡 Еженедельный дайджест №1

Для тех, кто был слишком занят на неделе или просто пропустил некоторые посты, публикуем дайджест!

Статьи:
– Google Chrome исполнилось 17 лет: история браузера и его будущее
– Кэширование DNS в NodeJS
– Почему браузеры ограничивают JavaScript таймеры?

Новости:
– Supply Chain атака через NPM снова в деле

Самый популярный комментарий этой недели – комментарий к статье "Google Chrome исполнилось 17 лет: история браузера и его будущее" от пользователя @Einherjar:

"Если функция полезна только Chrome, но вредит открытому вебу — мы её пересматриваем. Chrome всё больше будет становиться умным ассистентом для жизни в интернете: помогать справляться с потоком информации"
Ага, например возможность установить uBlock Origin, капец как вредит открытому вебу и особенно (!) мешает справляться с потоком информации. Этому челу бы в политики идти, лицемерия и вранья просто через слово.
Прочитав статью задонатил мозилле - вот мой подарок гуглхрому

@js_for_devs

😎 Как Node.js выжимает максимум из I/O в 2025 году

Команда JavaScript for Devs подготовила перевод статьи о том, как Node.js выжимает максимум из I/O в 2025 году.

В ней подробно объясняется цикл событий, порядок фаз и то, как правильно писать код, чтобы серверы оставались отзывчивыми даже под нагрузкой.

📚 Подробности на Хабр: https://habr.com/ru/articles/947524/

⚡ JavaScript всё ещё в топ-6, но теряет позиции

JavaScript держится на 6-м месте TIOBE Index с долей 3.22%, но за год просел на −0.70%. Вспомним, что в 2005 он был всего на 11-й позиции — путь наверх он прошёл впечатляющий.

🤔 Как думаете, сможет ли JS удержаться в топ-10 ещё 10 лет — или его место займёт TypeScript?

Источник.

#news@js_for_devs

😵 React-монополист: как мы сами убиваем развитие фронтенда

Выбор React «по умолчанию» тормозит инновации, мешает развитию альтернативных фреймворков и превращает всю экосистему в монокультуру.

Пора выбирать фреймворки по их соответствию задачам и техническим достоинствам, а не по инерции. Ваш следующий проект заслуживает большего, чем "React по умолчанию". Экосистема заслуживает инноваций, которые возможны только при разнообразии.

📚 Подробности на Хабр: https://habr.com/ru/articles/948072/