Intl.ListFormat это удобный способ собрать список в строку с учетом локали, без самописных костылей.

onst getMessage = (users) => {
  const formatter = new Intl.ListFormat("en-US", {
    style: "long",
    // long (по умолчанию), short, narrow
    type: "conjunction"
    // conjunction (and), disjunction (or), unit
  });
  return `Hello ${formatter.format(users)}!`;
};

// Автоматически подстраивает грамматику
console.log(getMessage(["Alice"]));
// → "Hello Alice!"

console.log(getMessage(["Alice", "Bob"]));
// → "Hello Alice and Bob!"

console.log(getMessage(["Alice", "Bob", "Charlie"]));
// → "Hello Alice, Bob, and Charlie!"

По сути, он сам правильно ставит запятые, союзы и форматирует список в зависимости от языка. Удобнее, чем писать if users.length === 2 ... else ... и поддерживать всё вручную.

@WebDev_Plus

Мигель сделал расширение для Visual Studio Code

Оно называется Better SVG и делает работу с SVG удобнее.

Постоянный предпросмотр и оптимизация кода в один клик, не выходя из редактора.

@WebDev_Plus

В следующей версии ArkType любой Standard Schema будет валидным определением.

Миграция с Zod станет куда проще

@WebDev_Plus

Свежая партия апдейтов по TypeScript 7. Новый нативный порт уже подъехал, и выглядит очень бодро.

Что умеет:

• проверяет типы в любом проекте
• поддерживает флаги --build и --incremental
• уже завезли полноценные фичи для редакторов
• и при этом работает примерно в 10 раз быстрее

Короче, можно пробовать прямо сейчас — версия уже в состоянии «юзабельно и приятно».

@WebDev_Plus

Нравится этот шрифт?

Это Glass TTY VT220. Ссылка на шрифт - https://github.com/svofski/glasstty

А финальный ретро-вайб дает Cool Retro Term с эффектом послесвечения.

@WebDev_Plus

Эксперимент на WebGL, который показывает, как VAT может масштабироваться прямо в браузере.

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

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

@WebDev_Plus

Ресурс для создания диаграмм на основе вашего TypeScript.

→ http://tsdiagram.com

@WebDev_Plus

В React Server Components обнаружена критическая уязвимость, описанная как CVE-2025-55182, которая затрагивает React 19 и использующие его фреймворки.

Исправление опубликовано в версиях React 19.0.1, 19.1.2 и 19.2.1. Рекомендуем немедленно обновить версию.

@WebDev_Plus

Самые ценные сайты для разработчиков:

http://roadmap.sh
http://playcode.io
http://usehooks.com
http://devhints.io
http://jsoncrack.com
http://realtimecolors.com
http://regex101.com
http://bundlephobia.com
http://caniuse.com
http://toolbox.googleapps.com

@WebDev_Plus

Используй стандартное поле Node.js imports вместо алиасов TypeScript.

@WebDev_Plus

Настоящий TypeScript ещё ни разу по-настоящему не пробовали.

@WebDev_Plus

Это может стать настоящей революцией в веб-разработке!
Сейчас разрабатывают протокол проверки email-адресов (Email Verification Protocol).

Можно будет валидировать почту без отправки писем и без соцлогина.
Прямо из браузера и на 100% приватно.

Пока это только предложение, но выглядит очень интересно.

@WebDev_Plus

Просто небольшое напоминание: для описания ограниченного набора возможных состояний лучше использовать union type.
А не жонглировать кучей boolean-полей и потенциально невалидными состояниями.

@WebDev_Plus

Chainable async API

Меня всегда интересовало, как DrizzleORM
удаётся чейнить async-функции вроде await delete() и await delete().where().

Они реализовали свой кастомный Promise, от которого наследуются все операции с БД, например PgDelete для delete в Postgres.

Чейнящиеся методы типа delete() и where() просто изменяют внутреннее состояние и всегда возвращают this (тот же самый инстанс промиса).

Поэтому, когда ты делаешь await delete(), под капотом вызывается then() этого промиса, который запускает this.execute().

Реальный запрос к базе выполняется именно в методе execute, который переопределяется в каждом подклассе.

Я считаю, что это очень крутой дизайн API, а сама идея имплементить Promise — просто отличная.

Ссылка на QueryPromise
Ссылка на PgDelete

@WebDev_Plus

Обеспечьте исчерпывающую проверку на этапе компиляции с помощью утилитарного типа Record в TypeScript

@WebDev_Plus

У <dialog> вместе с формами есть простой способ сделать кнопку Cancel без единой строчки JS. Помимо POST и GET, формы внутри <dialog> могут использовать метод DIALOG. В этом режиме кнопка submit просто закрывает диалог, не отправляя данные на бэкенд.

Удобный и чистый механизм, когда нужно отменить действие и закрыть окно без лишней логики.

Когда форма внутри <dialog> отправляется методом dialog, само диалоговое окно закрывается, состояние контролов формы сохраняется, но ничего не уходит на сервер. При этом returnValue принимает значение той кнопки, по которой пользователь кликнул.

Чистый и удобный способ обработать отмену или выбор без полноценного сабмита.

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

Подробнее на MDN: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/dialog

@WebDev_Plus

Нужны эффектные анимации для React Native?

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

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

Исходники: github.com/enzomanuelmangano/demos

@WebDev_Plus

По мне, это самый удобный вариант монорепы без отдельного шага сборки:

• pnpm workspaces и установка через workspace:*
• внутренние пакеты, которые экспортируют *.ts файлы
• опционально: pnpm publishConfig, чтобы при публикации подменять экспорты на *.js

{
  "name": "@internal/foo",
  "version": "1.0.0",
  // Экспорт исходников TypeScript
  "main": "./src/index.ts",
  "types": "./src/index.ts",
  "exports": {
    ".": "./src/index.ts"
  },
  // Экспорт собранного кода при публикации
  "publishConfig": {
    "access": "public",
    "main": "./dist/index.js",
    "types": "./dist/index.d.ts",
    "exports": {
      ".": "./dist/index.js"
    }
  },
  "dependencies": {
    // Установка других внутренних пакетов из workspace
    "@internal/bar": "workspace:*"
  }
}

@WebDev_Plus

React провернул трюк на миллиард долларов. Он превратил невозможную задачу O(n³) в O(n).

Сама задача такая. Ты обновляешь UI. У React есть две виртуальные DOM-деревья: одно отражает то, что сейчас на экране, второе то, что должно быть на экране. Нужно понять, что изменилось.

Классическое решение? Сравнить каждый узел дерева A с каждым узлом дерева B, чтобы найти оптимальное преобразование. Это алгоритм вычисления расстояния между деревьями. Его сложность O(n³).

Для 1000 элементов UI это миллиард сравнений. Приложение зависает на 10 секунд каждый раз, когда ты нажимаешь кнопку. Лента Facebook? Таймлайн Instagram? Нереально.

React посмотрел на эту классическую CS-задачу и решил: а что если нам не нужен идеальный результат? Что если достаточно «достаточно хорошего»?

Они сделали два жестких компромисса.

Компромисс 1. Разные типы компонентов? Даже не сравниваем их детей. Старое поддерево выкидываем целиком. Новое создаем целиком. Ноль анализа. Мгновенное O(1) решение. Иногда расточительно? Да. Быстро? Да.

Компромисс 2. Один и тот же тип? Сравниваем только узлы на одном уровне дерева. Не ищем более удачные соответствия где-то глубже. Какие-то оптимизации теряются? Конечно. Но сложность падает с O(n³) до O(n).

В итоге миллиард операций превращается в тысячу. 10 секунд превращаются в 2 миллисекунды. Невозможное становится тривиальным.

Поэтому ленты Instagram листаются плавно. Поэтому Facebook не зависает, когда ты ставишь лайк. Поэтому твое React-приложение с 10 000 компонентов ощущается мгновенным. Поэтому веб ощущается почти нативным.

React не решил невозможную задачу. Он просто сменил задачу.

Главный вывод: стремление к идеалу убивает скорость. А скорость — единственное, что действительно важно пользователю.

@WebDev_Plus