Bun 1.3

Вышел Bun 1.3. Основные фишки: улучшили поддержку фулстэк-разработки, встроили MySQL и Redis клиенты, улучшили работу с Cookie и роутингом, сделали улучшения для монорепо

Теперь обо всем по порядку

Если вы разрабатывается чисто фронтенд, то теперь достаточно запустить bun './**/*.html' и bun сделает транспиляцию и сборку всех исходников и сразу подтянет HMR. В релиз ноутсах также показывается насколько быстро работает HMR - текст на сайте обновляется мгновенное вместе с редактированием tsx исходника. Выглядит мощно.

Также в bun встроили простой роутинг и стриминг логов с браузера в терминал

import homepage from "./index.html";
import dashboard from "./dashboard.html";
import { serve } from "bun";

serve({
  development: {
    // Enable Hot Module Reloading
    hmr: true,

    // Echo console logs from the browser to the terminal
    console: true,
  },

  routes: {
    "/": homepage,
    "/dashboard": dashboard,
  },
});

Также фулстек приложения можно собирать в исполняемые файлы на разные ОС.

Появились новые хелперы для работы с SQL и новые встроенные DB-клиенты: mysql и redis. Встроенный redis-клиент в разы быстрее внешних библиотек (node-redis и ioredis). По замерам создателей Bun, конечно же. В любом случае - встроенная поддержка популярных СУБД это большой плюс.

Также много работ сделано в менеджере пакетов. В частности - внедрены isolated installs для монореп. Эта настройка делает так, что пакет не сможет достучатся до зависимости, которая не объявлена в его package.json. Эта настройка включена по дефолту. Если нужно вернуть старое поведение необходимо в конфиг bun добавить linker = "hoisted"

Также из интересного: добавили Security Scanner API. Теперь можно устанавливать внешние решения для аудита безопасности пакетов.

Еще сделали большой блок изменений во встроенный в Bun тест-реймворк. Во первых, сделали официальное расширение для VSCode, которое интегрирует bun test в VS Code Test Explorer UI, т.е. тесты можно запускать из UI vscode и там же смотреть результаты. Во вторых - дали явную возможность помечать тесты, как готовые для запуска в параллельном режиме или как требующие последовательного запуска. Это крайне полезно. По умолчанию в параллель запускаются не более 20 тестов, но это значение можно изменить. Важное отличие новой фичи от того, что уже есть в vitest или jest - можно запускать в параллель тесты, написанные в одном файле. Это, конечно, не новая фича (условный ava умеет такое с самого начала, если я правильно помню), но все равно звучит полезно.

Для любителей ATDD или TDD, добавили возможность пометить тест как "ожидается, что упадет". Это полезно, когда вы заранее составляете список тестов, а только потом имплементируете функционал, но при этом в отчете о запуске тестов вы хотите разделить "тест упал" и "функционал еще не реализован".

test.failing("known bug: division by zero", () => {
  expect(divide(10, 0)).toBe(Infinity);
  // This test currently fails but is expected to fail
  // Remove .failing when the bug is fixed
});

test.failing("TDD: feature not yet implemented", () => {
  expect(newFeature()).toBe("working");
  // Remove .failing once you implement newFeature()
});

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

https://bun.sh/blog/bun-v1.3

#development #javascript #bun #releaseNotes

React Compiler v1.0

Вышел React Compiler v1.0. Его можно поставить и, по заверениям разработчиков, забыть о ручном менеджменте useMemo, useCallback, React.memo в 99% кейсах - теперь эту работу должен забрать на себя React Compiler. В остальных 1% кейсов можно заняться ручной оптимизацией для достижения лучших результатов.

React Compiler уже используется в приложениях. Например в Meta Quest Store - магазин приложений для VR гарнитуры Oculus Quest. Использование React Compiler ускорило работу навигации на 12%, а некоторые взаимодействия ускорились в 2.5 раза.

Штош, ждем посты на хабре и доклады на конфах про то, как люди включили React Compiler и их сайт ускорился или им пришлось потратить неделю на поиск бага.

https://react.dev/blog/2025/10/07/react-compiler-1

#development #javascript #react #reactCompiler

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

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

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 #javascript #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 #javascript #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 #javascript #nodejs #testing #bestPractices #github

How to Steal Any React Component

Статья показывает, как восстановить react-компонент с любого сайта без доступа к исходникам. Способ не со 100% гарантией, но, тем не менее, достаточно интересный. Также в статье очень прикольные интерактивные элементы - очень сильно помогают в чтении материала.

Итак, по шагам

Шаг 1: Есть 2 дерева - DOM и React-Fiber и их можно связать.

Первое доступно в браузере
Второе - внутреннее представление компонентов в React, которое также доступно в браузере. React, начиная с 16 версии, выставляет API для минимальной работы с этим деревом, чтобы нам было удобно дебажить сайты в React Developer Tools. В этом API есть возможность узнать, каким React-компонентом создан DOM-элемент и с какими пропасами.

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

Шаг 2: Собираем рендеры одного компонента в кучку
Например, мы обнаружили, что базовый элемент "Кнопка" был отрендерен 10 раз. Тогда мы можем собрать 10 кейсов мапинга props => HTML для кнопки

Шаг 3: Просим LLM на основе мапинга компонента восстановить компонент
Берем полученный мапинг, докидываем минифицированный код компонента (который можно получить через .toString в React Fiber) и просим LLM восстановить читемый код.

Шаг 4: Проверяем, что компонент корректно восстановился
Проверяем, что с теми же входными данными мы получаем тот же HTML. Если это не так - просим LLM поправить код

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


https://fant.io/react/

#development #javascript #react #ai #llm

Бизнес Tailwind сокращается из-за AI

Комментарий к пул-реквесту на github, где автор tailwind сообщает, что из-за AI пришлось уволить 75% разработчиков tailwind.

Tailwind состоит из двух частей:
1. Опенсорсная часть, на которой очень хорошо обучен LLM
2. Tailwind labs - там платные UI-киты, сапорт и все такое

Повсеместное использование LLM разработчиками привело к тому, что:
1. Люди перестали заходить в доку tailwind и видеть рекламу платных фич
2. LLM и сами могут создать хорошие компоненты, поэтому снижается потребность в платных фичах

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

К tailwind можно относиться по разному (лично я - не фанат описания десятка классов, но мне ок если это делает LLM), но его автор сделал крутой инструмент и даже придумал как монетизировать опенсорс продукт - это достойно уважения.




#development #javascript #tailwind #ai