ESLint Plugin for Baseline JavaScript

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

https://baselinejs.vercel.app/

#development #javascript #eslint #baseline

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-javascript-cleaner-debugging-with-error-cause/

#development #javascript #error

JavaScript engines zoo

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

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

#development #javascript #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 #javascript #snapchat #framework #crossPlatform

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

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

https://tsdiagram.com

#development #javascript #typescript #diagram

The Performance Inequality Gap, 2026

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

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

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

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

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

#development #javascript #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 #javascript #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 #javascript #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 #javascript #performance #sentry #speculationRules

The JavaScript Bundler Grand Prix

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

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

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

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

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

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

#development #javascript #bundler