Error chaining in JavaScript: cleaner debugging with Error.cause

Как-то я пропустил момент, когда в JS стандартизировали иерархию ошибок. А она уже давно доступна во всех браузерах. Статья посвящена этой фиче и по шагам рассказывает особенности и кейсы для использования.

Решаемая проблема
Когда в коде возникает ошибка, а вы ее заворачиваете во что-то более читаемое, то вы теряете корневой источник ошибки. Как это делается без Error.cause

try {
  JSON.parse('{ bad json }');
} catch (err) {
  throw new Error('Something went wrong: ' + err.message);
}

Здесь мы сохраняем исходную ошибку только через упоминание в error.message и не сохраняем стак-трейсы

Решение: Error.cause
Стандартизировали возможность передать исходную ошибку как причину новой ошибки, что позволяет сохранять весь контекст на любом уровне

try {
  try {
    JSON.parse('{ bad json }');
  } catch (err) {
    throw new Error('Something went wrong', { cause: err });
  }
} catch (err) {
  console.error(err.stack);
  console.error('Caused by:', err.cause.stack);
}

В выводе содержатся оба стактрейса

Error: Something went wrong
    at ...
Caused by: SyntaxError: Unexpected token b in JSON at position 2
    at JSON.parse (<anonymous>)
    at ...

Это и есть вся фича. В целом так делали и до стандартизации этого подхода, но хорошо что стандартизировали

В статье упоминаются еще пара интересных моментов. Один из них: хелпер для удобного вывода всей иерархии.

Например, у вас в иерархии 3 уровня: ошибка сети => ошибка доступа к БД => ошибка сервиса

class ConnectionTimeoutError extends Error {}
class DatabaseError extends Error {}
class ServiceUnavailableError extends Error {}

try {
  try {
    try {
      throw new ConnectionTimeoutError('DB connection timed out');
    } catch (networkErr) {
      throw new DatabaseError('Failed to connect to database', { cause: networkErr });
    }
  } catch (dbErr) {
    throw new ServiceUnavailableError('Unable to save user data', { cause: dbErr });
  }
} catch (finalErr) {
  logErrorChain(finalErr);
}

Можно реализовать logErrorChain следующим образом

function logErrorChain(err, level = 0) {
  if (!err) return;
  console.error(' '.repeat(level * 2) + `${err.name}: ${err.message}`);

  if (err.cause instanceof Error) {
    logErrorChain(err.cause, level + 1);
  } else if (err.cause) {
    console.error(' '.repeat((level + 1) * 2) + String(err.cause));
  }
}

Тогда мы увидим вот такой вывод

ServiceUnavailableError: Unable to save user data
  DatabaseError: Failed to connect to database
    ConnectionTimeoutError: DB connection timed out

https://allthingssmitty.com/2025/11/10/error-chaining-in-javanoscript-cleaner-debugging-with-error-cause/

#development #javanoscript #error

Дайджест за 2025-11-17 - 2025-11-21

Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl
Пост в блоге Мартина Фаулера где автор пытается разобраться в новомодном в AI-тусовке термине Spec-Driven-Development, рассматривая его имплементацию разными инструментами


Применяем что-то типа Specification Driven Development на практике
В предыдущем посте написал про Spec Driven Development и упомянул, что вдохновился подходоми решил его попробовать.


ESLint Plugin for Baseline JavaScript
Eslint Plugin для проверки использования слишком нового синтаксиса и фичей веба. Вы выбираете baseline threshold, а плагин контролирует, чтобы вы его придерживались


Codefest 16: Call for Papers
Codefest открыл сбор заявок на доклады на 2026 год. Сбор заявок продлится до 1 марта. Если хотите выступить - отправляйте заявки. Конференция ламповая, хожу на нее в качестве и спикера и слушателя уже лет 10, почти без перерывов.


Error chaining in JavaScript: cleaner debugging with Error.cause
Как-то я пропустил момент, когда в JS стандартизировали иерархию ошибок. А она уже давно доступна во всех браузерах. Статья посвящена этой фиче и по шагам рассказывает особенности и кейсы для использования.

JavaScript engines zoo

Сколько JS-движков вы можете вспомнить с ходу? Скорее всего большинство назовет 3: v8 в хроме, что-то в firefox и что-то в safari. Более прошаренные чуваки вспомнят еще штуки 3-4 специфичных. А их оказывается десятки. На сайте собрана сравнительная таблица существующих (и существовавших) JS-движок с верхнеуровневым сравнением движков друг с другом

https://ivankra.github.io/javanoscript-zoo/

#development #javanoscript #jsEngines

Valdi

Snapchat заопенсорсил свой фреймворк для кросс-платформенной разработки UI. Пока супер бета (beta-0.0.1). Код пишется на jsx, но затем компилируется в нативный код. Snapchat использует фреймворк уже 8 лет.

Пример кода

import { Component } from 'valdi_core/src/Component';

class HelloWorld extends Component {
  onRender() {
    const message = 'Hello World! 👻';
    <view backgroundColor='#FFFC00' padding={30}>
      <label color='black' value={message} />
    </view>;
  }
}

Что поддерживается:
- Комиляция в android, ios, desktop (не понял что конкретно они имеют в виду под десктопом)
- JSX + TypeScript
- Hot Reloading
- Дебаг в VSCode
- Супер оптимизированный UI на выходе (по крайней мере заявляется)

Глубоко не погружался, но выглядит слишком амбициозно, чтобы быть правдой. Но если даже частично правда - выглядит интересно.

https://github.com/Snapchat/Valdi

#development #javanoscript #snapchat #framework #crossPlatform

Дайджест за 2025-11-24 - 2025-11-25

JavaScript engines zoo
Сколько JS-движков вы можете вспомнить с ходу? Скорее всего большинство назовет 3: v8 в хроме, что-то в firefox и что-то в safari. Более прошаренные чуваки вспомнят еще штуки 3-4 специфичных. А их оказывается десятки. На сайте собрана сравнительная таблица существующих (и существовавших) JS-движок с верхнеуровневым сравнением движков друг с другом


Valdi
Snapchat заопенсорсил свой фреймворк для кросс-платформенной разработки UI. Пока супер бета (beta-0.0.1). Код пишется на jsx, но затем компилируется в нативный код. Snapchat использует фреймворк уже 8 лет.


——————————————

Спасибо что читаете, ставите реакции и отмечаетесь в комментариях. Если вы хотите помочь каналу - расскажите о нем своим коллегам или друзьям. Также оставляйте фидбек по формату, материалу и чему-угодно еще 🙂

TSDiagram is an online tool that helps you draft diagrams quickly by using TypeScript

TSDiagram - инструмент, в котором вы описываете диаграммы с помощью Typenoscript. Вы описываете классы, типы и интерфейсы, а инструмент отображает связи между ними в виде диаграмм. Лично для себя пока не представляю кейсов использования, но выглядит интересно

https://tsdiagram.com

#development #javanoscript #typenoscript #diagram

The Performance Inequality Gap, 2026

Огромнейший отчет, описывающий тренды пользования сайтами. Если коротко: размер JS-бандлов растет намного быстрее, чем мощность устройства среднего пользователя. За последние 5 лет средний размер загружаемого js вырос на треть, в то время как прочие форматы данных (кроме видео контента), выросли на скромные 5-10%.

Этот отчет, как я понимаю, предшествует новой рекомендации от автора по перформансу сайтов. В этом отчете - куча графиков - про сайты, про устройства, про пользователей. Если вам не лень - можете погрузиться и узнать много нового. Этот отчет классно показывает, что средний пользователь - это не юзер айфона с вайфаем, а человек с бюджетным андроидом и сетью около 10мб.

Также интересно, что хотя большинство сайтов и стараются быть SPA, но в среднем у SPA соотношение софт-переходов (без перезагрузки страницы) к хард-переходам (с перезагрузкой) - один к одному

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

https://infrequently.org/2025/11/performance-inequality-gap-2026/

#development #javanoscript #web #performance #research

93% Faster Next.js in (your) Kubernetes

Очень интересная статья про перформанс nodejs веб-серверов. Особенно она интересна для тех, кто поддерживает работающие nodejs приложения на проде. В статье рассказывается, как можно ускорить nextjs (и вообще любой другой nodejs-фреймворк) на 93% перейдя с pm2 или одноядерных подов в кубе на watt

Если вы хотите себе серверный рендеринг или крутить какой-то сервер на nodejs, то вам надо придумать как вы будете оркестрировать запросы. Есть 2 популярных паттерна:

1. Горизонтальное масштабирование с кубом - деплоим в куб столько подов приложения, сколько нам нужно, и выделяем каждому одно ядро
2. Делаем более жирные поды с воркерами, который оркестрирует pm2

У второго подхода проблема в том, что pm2 на коммуникациях с воркерами теряет много времени и цпу ресурса.

У первого подхода проблема в том, что k8s ничего не знает о загрузке конкретных подов и роутит запросы round-robin'ом, т.е. поочередно в разные поды закидывает запросы. Как следствие, может возникнуть ситация, что одному поду достаются простые запросы, а второй - умирает на обработке тяжелых запросов.

Хотелось бы получить нулевые издержки на коммуникацию с воркерами и при балансировке учитывать текущее состояние воркеров. Именно это позволяет сделать Watt.

Watt, как я понял, аналог pm2, но с одной особенностью - он умеет использовать фичу линукса, которая позволяет переиспользовать сокеты между несколькими процессами. Это, в свою очередь, позволяет убрать "налог" на коммуникацию между мастером и воркерами - воркеры сами подключаются к сокету (еще и могут переиспользовать кеши, если я правильно понял)

Автор приводит бенчмарк k8s 6 pods vs PM2 3x2 workers vs Watt 3x2 workers . Результаты следующие:


Single-CPU pods (6×1)
• Throughput: 972 req/s
• Success Rate: 93.7%
• Median Latency: 155 ms
• P95 Latency: 1,000 ms

PM2 (3×2 workers)
• Throughput: 910 req/s
• Success Rate: 91.9%
• Median Latency: 182 ms
• P95 Latency: 1,260 ms

Watt (3×2 workers)
• Throughput: 997 req/s
• Success Rate: 99.8%
• Median Latency: 11.6 ms
• P95 Latency: 235 ms

Выглядит хорошо. Если вы используете pm2 в продакшне, то можете попробовать перейти на Watt и получить ускорение работы сервисов.

https://blog.platformatic.dev/93-faster-nextjs-in-your-kubernetes

#development #javanoscript #nextjs #nodejs #kubernetes #pm2 #watt

Use Nemo - Custom Directives Library

React вводит директивы use client и use server в рамках серверных компонентов, чтобы немного по-разному компилить код. Если вы когда-либо хотели быть как React и придумать свои директивы, то библиотека use-nemo для вас! Она позволяет описывать свои директивы, которые встраиваются в сборку кода в vite. Хотите сделать свою директиву use somewhat, которая будет переопределять что-то в коде - велкам.

Как это работает

Шаг 1: придумывайте директиву и описываете ее в коде

// src/components/MyComponent.tsx
"use nemo";

export function MyComponent() {
  return <div>My component</div>;
}

Шаг 2: описываете обработчик директивы и регистрируете ее

// src/directives/useMyDirective.ts
import { directiveRegistry, injectCode } from "use-nemo";
import type { DirectiveHandler } from "use-nemo";

const myDirective: DirectiveHandler = {
  name: "nemo", // This is the name used in "use nemo"
  handler({ code, id, directiveName }) {
    // Transform the code as needed
    return injectCode(code, () => {
      console.log("🐟");
    });
  },
};

directiveRegistry.register(myDirective);

Шаг 3. Подключаете плагин в vite

// vite.config.ts
import customDirectives from "use-nemo";

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

Мое мнение: это одновременно интересная штука и игрушка дьявола. Не позавидую тому, кому в достанется на поддержку легаси-проект, в котором кто-то обмазался кастомными директивами и инжектится в компиляцию(или сборку) кода, вместо того чтобы делать логику в коде.

Однако, наверняка можно придумать что-то полезное. Если у вас есть какая-то интересная идея для кастомных директив - поделитесь в комментах. Интересно было бы услышать

https://github.com/Ademking/use-nemo

#development #javanoscript #vite

less than 100ms E-commerce: Instant loads with Speculation Rules API

Еще одна обзорная статья про Speculation Rules. Speculation Rules позволяют сказать браузеру, какие ресурсы стоит предзагрузить и каким образом - начиная предзагрузкой html и заканчивая запуском следующей страницы в фоне. Технология пока экспериментальная, но уже можно пользоваться ей в хромиум-браузерах

Пока есть 2 типа предзагрузки ресурсов - prefetch и prerender.

Prefetch - это предзагрузка ресурса. Например, можно предзагрузить html, js, css или любой другой ресурс, который можно загрузить fetch'ом

Preprender - это не просто предзагрузка ресурса, но и его исполнение. Например, можно сделать prerender следующей страницы. В этом случае браузер сделает запрос страницы и начнет ее исполнять, как если бы она была открыта в соседней вкладке - загрузит все ресурсы, запустит JS, начнет делать запросы. При переходе на следующую страницу переход для пользователя будет моментальным.

С точки зрения пользовательского опыта prerender выглядит круто (хотя на слабых устройствах или при злоупотреблении фичей может нормально так подлагивать).

Но с точки зрения техники конечно есть нюансы:
- Аналитика или АБ-тесты могут работать некорректно т.к. теперь нельзя считать, что если JS-исполнился, значит пользователь перешел на страницу. Кроме аналитики могут быть и другие особенности - например, мы можем ожидать что пользователь выбрал фильтры на предыдущей странице и они сохранены в localstorage или cookie, а пользователь их еще не выбрал т.к. это пререндер а не настоящий переход
- Если пользователь не перейдет на страницу, то зря потратили ресурсы при серверном рендере и на обработку запросов. А они могут стоить денег
- Пока не представляю как дебажить проблемы в случае prerender'а. Можно ли поставить брекпоинт в коде, удобно ли смотреть сетевые запросы?

Эти директивы можно устанавливать в html, а можно из JS. При грамотном использовании они могут значительно улучшить UX.

https://blog.sentry.io/less-than-100ms-e-commerce-instant-loads-with-speculation-rules-api/

#development #javanoscript #performance #sentry #speculationRules

Code review на автопилоте: наш путь к прозрачному процессу

Достаточно простая статья от Ленты про код-ревью. Никакой большой новизны там нет, но, как и любые простые советы, кому-то может помочь. В Ленте чуваки столкнулись с обыденной проблемой - МР-ы делаются, а код-ревью не делается. Ребята автоматизировали процесс выбора ревьюеров на МР и это помогло ускорить процесс кодревью.

В чем была проблема:
- Разработчик оформляет МР
- Скидывает ссылку на МР в чат
- В чате работает закон коллективной ответственности, в народе сформулированный как "у 7 нянек дите без глазу". Ссылка в чат скинута, а из команды никто не смотрит
- Когда все таки кто-то смотрит - комментарии могут потеряться
- Как итог - код-ревью может идти неделями

Классическое решение: ~~отменить codereview~~ автоматизировать процесс код-ревью. Решение, на самом деле, на поверхности и делается на коленке за пару вечеров (если у вас нет требований чтобы расширить это решение на большую компанию и учитывать отпуска)

Наивное решение:
- При создании МР автоматически отсылается сообщение в чат
- Ревьюеры выбираются автоматически и призываются в тред
- Любые коменты в МР тригерят отправку сообщений в тред с запросом в код-ревью или в личку авторам и ревьюерам. Не суть куда - главное нотифицировать, что требуется обсуждение
- Если МР уже долго висит с незаконченным кодревью - пушить всех участников, что надо завершить кодревью
- Когда получили нужное количество апрувов - надо пушить автора вливать МР (или вливать автоматом)

У Ленты примерно такое решение, только с БД и учетом графика отпусков.

В общем, если у вас в команде есть кодревью и вы чувствуете боль, что то ревьюеры не ревьюят, то МР-ы теряются, то возьмите какое-то решение из опенсорса или завайбкодьте свое решение для автоматического менеджмента кодревью

https://habr.com/ru/companies/lentatech/articles/936266

#development #Codereview

Немного запоздавший дайджест за 2025-12-01 - 2025-12-05

TSDiagram is an online tool that helps you draft diagrams quickly by using TypeScript
TSDiagram - инструмент, в котором вы описываете диаграммы с помощью Typenoscript. Вы описываете классы, типы и интерфейсы, а инструмент отображает связи между ними в виде диаграмм. Лично для себя пока не представляю кейсов использования, но выглядит интересно


The Performance Inequality Gap, 2026
Огромнейший отчет, описывающий тренды пользования сайтами. Если коротко: размер JS-бандлов растет намного быстрее, чем мощность устройства среднего пользователя. За последние 5 лет средний размер загружаемого js вырос на треть, в то время как прочие форматы данных (кроме видео контента), выросли на скромные 5-10%.


93% Faster Next.js in (your) Kubernetes
Очень интересная статья про перформанс nodejs веб-серверов. Особенно она интересна для тех, кто поддерживает работающие nodejs приложения на проде. В статье рассказывается, как можно ускорить nextjs (и вообще любой другой nodejs-фреймворк) на 93% перейдя с pm2 или одноядерных подов в кубе на watt

Use Nemo - Custom Directives Library
React вводит директивы use client и use server в рамках серверных компонентов, чтобы немного по-разному компилить код. Если вы когда-либо хотели быть как React и придумать свои директивы, то библиотека use-nemo для вас! Она позволяет описывать свои директивы, которые встраиваются в сборку кода в vite. Хотите сделать свою директиву use somewhat, которая будет переопределять что-то в коде - велкам.


less than 100ms E-commerce: Instant loads with Speculation Rules API
Еще одна обзорная статья про Speculation Rules. Speculation Rules позволяют сказать браузеру, какие ресурсы стоит предзагрузить и каким образом - начиная предзагрузкой html и заканчивая запуском следующей страницы в фоне. Технология пока экспериментальная, но уже можно пользоваться ей в хромиум-браузерах
——————————————

Спасибо что читаете, ставите реакции и отмечаетесь в комментариях. Если вы хотите помочь каналу - расскажите о нем своим коллегам или друзьям. Также оставляйте фидбек по формату, материалу и чему-угодно еще 🙂

Похоже, что уязвимость в react server тянет на премию biggest frontend fuckup

Ещё пара уязвимостей в React Server Components

Спустя неделю после просьбы обновить уязвимые библиотеки команда React просит сделать это снова. На этот раз исследователи нашли две уязвимости, которые могут быть крайне неприятны.

CVE-2025-55184 и CVE-2025-67779 — позволяет дёрнуть серверную функцию так, чтобы вызвать бесконечный цикл, что может грохнуть или избыточно нагрузить ваш серверный CPU.

CVE-2025-55183 — позволяет достать исходный код серверной функции. Опасно, только если вы прямо в коде храните пароли или супер-секретную бизнес-логику пишете прям в серверных функциях.

В общем, снова нужно обновить библиотеки из списка в статье. И фреймворки, у которых они в зависимостях (особенно Next.js).

Интересно, как много команд завело встречку в календаре обсудить «Переезд на <не-реакт, подставить нужное>».

https://react.dev/blog/2025/12/11/denial-of-service-and-source-code-exposure-in-react-server-components

+30% к скорости написания автотестов и сотни чек-листов в день: как мы внедряем LLM в QA

Пост от Яндекса про внедрение LLM в процесс обеспечения качества. В посте нет никакого хардкора (ни строчки кода!), но есть интересный опыт внедрения LLM в цикл разработки.

В Яндексе, как и почти в каждой крупной компании, есть core-команда QA, которая занимается развитием инструментария и подходов обеспечения качества для всех команд Яндекса.

Они решили попробовать автоматизировать часть рутины работы QA с помощью LLM. Работа QA - хороший кандидат на автоматизацию рутины т.к. у QA-артефактов есть четкая и понятная структура (чеклист, тесткейс, тестплан) и эти артефакты описываются на естественном языке.

Быстро столкнулись с тем, что легко на коленке за пару вечеров собрать рабочее MVP, но сложно довести его до такого качества, чтобы масштабировать на сотни команд. Как следствие, многие команды сами на коленке собрали свои MVP.

Поэтому команда сместила фокус на обеспечение инфраструктуры для генерации этих артефактов: MCP-серверы для внутренней инфраструктуры, инструментарий для ревью и управления сгенерированными артефактами, а также базовое решение для генерации, в которое периодически заносят лучшие практики из MVP команд.

Даже после внедрения всех лучших практик LLM все еще частенько генерирует тест-кейсы, которые идеально описаны с точки зрения формата, но абсолютно плохи как тест-кейсы для провекри фичи. Поэтому внедрили подход LLM-as-a-judge - это когда одна LLM генерирует результат, а другая его проверяет на соответствие критериям или эталону и ставит оценку. Если хорошо - идем дальше, если нет - перезапускаем генерацию.

Кроме тест-кейсов команда также занялась и автоматизацией тестирования в двух направлениях: генерация автотестов (тут все достаточно банально - обучение, лучшие практики, мемори банки) и автоматизация прохождения ручных тест-кейсов.

Автоматизация прохождения ручных тест-кейсов это, по сути, взять тест-кейс с шагами и отдать его ИИ-агенту для прохождения в браузере. Звучит прикольно. В статье говорится, что на старте ИИ-агент корректно мог пройти 45% тест-кейсов - это слишком слабый показатель чтобы полагаться на такой инструмент. Но, если этот показатель достигнет 80+%, то такой инструмент будет мега полезен



https://habr.com/ru/companies/yandex/articles/970428/

#development #qa #testing #llm #ai #yandex

The JavaScript Bundler Grand Prix

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

В посте есть инфографика по годам появления бандлеров и основным атрибутам бандлеров (кто поддерживает и язык) и четко видно динамику - если в начале бандлеры были на JS и поддерживались сообществом, то начиная с 2020-го года все бандлеры развиваются под началом крупных коммерческих компаний и пишутся на нативных языках (в основном Rust).

Бандлеры превратились из инструментов, создаваемыми энтузиастами для удобной разработки, в критичную инфраструктуру веб-разработки. Как следствие - поменялись подходы.

Сейчас у бандлеров в фокусе - быстрая сборка т.к. это критично важно разработчикам. А для этого необходимо использование быстрых языков (Rust) и другая архитектура бандлеров. Архитектура старых бандлеров (например, webpack) выстроена так, что в ней нельзя сделать быстрый бандлер. Новые бандлеры учитывают опыт предыдущих и сразу закладывают архитектуру под скорость работы.

Ожидаем, когда фокус изменится со скорости сборки, на качество результата.

https://redmonk.com/kholterhoff/2025/12/16/javanoscript-bundler-grand-prix/

#development #javanoscript #bundler

I ported JustHTML from Python to JavaScript with Codex CLI and GPT-5.2 in 4.5 hours

Есть стандарт, описывающий как парсить HTML. Он сложный, в особенности правила парсинга невалидного html. Есть библиотеки, которые реализуют эту сложную логику. Одна из них - justhtml - имплементация парсера на python, над которой человек работал несколько месяцев и которая проходит все тесты. Автор поста решил попробовать переписать эту имплементацию на JS с помощью ИИ-агентов. Codex справился за 4 часа и $29.

В посте описано, как автор взаимодействовал с Codex - какие промпты давал, как предлагал что делать.

Основные выводы:
- Если у вас есть тесты, которые надо пройти и ИИ может их запустить, то с большой вероятностью агент сможет написать решение самостоятельно
- Текущие ИИ агенты справляются со сложными задачами, включающими сотни вызовов тулов и кучу под-задач
- ИИ хорошо справляется с переносом кода с языка на язык
- Раньше был спор, что является результатом работы разработчика - код или работающий продукт. Многие уваажаемые инженеры в сфере разработки говорили, что код - побочный продукт, главное, что делает инженер - проектирует решение. Но раньше этот "побочный продукт" был дорогим (буквально можно не уметь проектировать решения но уметь писать код и получать зарплату), а теперь код стоит дешево, благодаря ЛЛМ

Автор также задается вопросами этики и легальности:
- Легально ли публиковать переписанный код?
- Этично ли переписывать чужой код, не добавляя ничего своего, и публиковать его?
- Что если ИИ-агент взял чужой код и переписал его - на ком лежит ответственность в случае какого-то конфликта?

https://simonwillison.net/2025/Dec/15/porting-justhtml/

#development #javanoscript #llm #refactoring

Let your Coding Agent debug your browser session with Chrome DevTools MCP

В бетке google chrome появилась возможность подключиться к браузеру через mcp. Теперь Chrome DevTools MCP сервер позволяет ИИ-агенту подключится к вашему браузеру и посмотреть, что происходит в вашей вкладке.

На видео-примере использования пользователь ловит ошибку в браузере и спрашивает в терминале у gemini, что не так. Gemini подключается к браузеру и выясняет, что не так.

Выглядит, конечно, потрясно

https://developer.chrome.com/blog/chrome-devtools-mcp-debug-your-browser-session

#development #javanoscript #llm #googleChrome #mcp

Node.js Testing Best Practices

Репозиторий с 50+ бест практисами тестирования в Node.js. Как обычно - часть пунктов странные, часть очевидные, часть интересные. Каждый точно найдет что-то интересное для себя. Я лишь выделю пару громких интересных поинтов.

1. Всегда начинайте с интерационных тестов. E2E-тестов и юнит-тестов должно быть мало.
2. Пишите тесты во время разработки, а не после
3. Поднимайте реальную БД для тестирования с помощью докера
4. Используйте бест-практисы юнит-тестирования для интеграционных тестов
5. Структурируйте тесты по роутам и историям
6. Изолируйте компонент (в терминах Component Testing) на уровне HTTP. То есть, грубо говоря, мокайте запросы к внешним сервисам.
7. По умолчанию на все исходящие запросы надо отвечать ошибкой. Каждый тест должен явно прописывать ожидаемые ответы и запросы.
8. Не забывайте тестировать негативные кейсы, в том числе сетевые проблемы, некорректные ответы и сообщения
9. Используйте фейковый брокер сообщений для тестирования

https://github.com/goldbergyoni/nodejs-testing-best-practices

#development #javanoscript #nodejs #testing #bestPractices #github

Вот почти и прошёл очередной год.

В этом году я решил не выступать на конференциях и на сэкономленое время жить на чиле. Вышло, конечно, не так - в плане и работы и жизни год вышел очень насыщенный и напряжённый. Я, кажется, не был таким морально и эмоционально уставшим с момента ремонта в квартире, купленной на вторичке. Поэтому в этом году было много недель без ссылок в канале. Пока выглядит так, что в следующем году тенденция может сохраниться, но я постараюсь все таки выработать привычку регулярного чтения новостей (не зря же прочёл книгу Атомные Привычки, кстати, рекомендую к чтению) и вычитки и исправления своих очепяток (спасибо, кстати, всем, кто не лениться пнуть меня в комментариях к посту за нубские ошибки)

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

Текущие инструменты с ИИ (почти бесплатные между прочим) очень сильно упростили и ускорили работу - написание кода, доки, отчётов, поиск информации и решений. Cursor, chatgpt и perplexity - три инструмента которые я использую почти ежедневно как в работе, так и в сайд проектах (все последние фичи в хром расширении почти полност сделаны курсором) и просто в бытовых ситуациях.

Также теперь воочию наблюдаю как молодёжь изучает программирование с ИИ. Взял студента из новосибирского университета сделать важную фичу в расширении. Теперь наблюдаю, как появляется рабочий код, но "автор" не понимает как он работает и как делать в нем правки. Но, если помогать человеку учить базу программирования, то обучение идёт прям бодро.

Читать новости стало и сложнее и проще одновременно. Проще, потому что я могу попросить перплексити выступить первым фильтром и дать мне краткое саммари статьи, комментариев про неё на других сайтах, почему статья хорошая или плохая. С другой стороны - появилось много нейростатей, в которых просто невообразимая куча воды и мало смысда. В особенности преуспел в этом хабр. Раньше я почти никогда не ставил минусы статьям на хабре, а теперь ставлю регулярно за нейрослоп.

В общем, посмотрим, как разгонится весь ИИ-движ в следующем году.

Всех с наступающим новым годом (или с наступившим, если читаете это в 2026 гожу). Всем быстрых фронтендов, интересных проектов и челленджей, чутких и умных руководителей (и подчинённых, если вы руководитель).

Ну и, конечно же, успехов в личных делах и гармонии в семье
🎉🎉🎉