Oxlint JS Plugins Preview

Oxlint представили API для плагинов на JS. При этом есть 2 версии API - частично совместимое с Eslint, что позволяет подключить eslint-правила в oxlint без доп приседаний, и oxlint API, которое позволяет делать более производительные правила.

Пока что это превью, поэтому нет полноценной поддержки eslint API и плюс есть еще куда ускорится. Тем не менее, переход на oxlint в моменте даст значительное ускорение - даже с кастомными плагинами oxlint работает в 15 раз быстрее eslint.

При этом API плагинов для oxlint не сильно отличается от eslint. С миграцией кода с eslint на oxlint вполне справится любая LLM. С точки зрения разрабов oxlint было бы правильно выложить prompt или rules для переписывания правил на основе LLM или AI-агентов.

https://oxc.rs/blog/2025-10-09-oxlint-js-plugins.html

#development #javascript #oxlint #eslint

Node.js 22 Features You Should Be Using

Nodejs 22 стал LTS, а значит пора обновляться и смотреть, чего же там нового принесли в Nodejs.

Основные изменения:
- WebSocket клиент теперь стабильная фича, можно смело переходить на него
- fetch теперь также стабильная фича, можно смело переходить на встроенный fetch
- улучшили модель разрешений. Можно лочить использование файловой системы или env-переменных

node --experimental-permission \
     --allow-fs-read=/app/data \
     --allow-env=NODE_ENV index.js

- Стабилизировали использование require из ES-модулей. Это должно упростить жизнь на время перехода экосистемы к ES-модулям
- Встроенный тест-раннер теперь поддерживает кастомные репортеры, сбор тестового покрытия и мокирование таймеров
- Поддержка AbortController в нативных API


https://nodesource.com/blog/nodejs-22-features

#development #javascript #nodejs #releaseNotes

Исходники веб-версии app store

Чуваки из эпла, которые разрабатывают веб версию апстора, случайно сделали сорсмапы кода открытыми на проде. И теперь исходный код апстора стал общественным достоянием - энтузиасты скачали его и залили на гитхаб. Репозиторий уже прикрыли, но вы легок можете найти другие репозитории поиском по гитхабу по строке apps.apple.com. Скорее всего уже можно посмотреть и не на гитхабе.

Всегда приятно посмотреть чужой продакшн код, а здесь сам апстор, которым пользуются миллионы людей.

Я посмотрел краем глаза, что увидел:
- Используется svelte и scss
- Не смотря на использование svelte, встречается импеативная работа с DOM (создание элементов, навешивание классов)
- Иногда встречаются достаточно объемные комментарии к работе кода - респект людям, описывающие нюансы работы решения в комментариях
- У каждой уважающей себя команды непременно должен быть написан свой логгер. Чтобы было уж совсем по-взрослому - нужен базовый логгер и его наследник - ConsoleLogger. У эпла все серьезно - логгеры с наследованием
- Используется нативный dialog для модалок + полифилл. Также респект за использование нативного dialog

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

https://github.com/rxliuli/apps.apple.com

#development #javascript #svelte #appStore #apple

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