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

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

Но модель может сделать ее черновой набросок.

Главный момент который постоянно ускользает от наших обезьяньих мозгов - результаты работы LMM не детерминированы и об этом ни в коем случае нельзя забывать когда у нам в голову приходит мысль заменить какие-то инструменты которые защищают от ошибок человеческого фактора (т.е. от не детерминированного поведения человека)

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

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

Странно, но я почему-то не обнаружил такого готового хука:

 useAsyncEffect(
   async (signal, onAbort) => {
   }
, [params])

на глаза попадается какая-то дичь

Поэтому написал свою наивную реализацию, критика велком

const isAbortError = (e: unknown) => e && typeof e === 'object' && 'name' in e && e.name === 'AbortError';

const useAsyncEffect = (cb: (signal: AbortSignal, onAbort: (cb: () => void) => void) => Promise<void>, deps?: React.DependencyList) => {
  useEffect(() => {
    const controller = new AbortController();
    (async () => {
      try {
        const onAbort = (cb: () => void) => {
          if (controller.signal.aborted) {
            cb();
          } else {
            controller.signal.addEventListener('abort', cb, { once: true });
          }
        };
        await cb(controller.signal, onAbort);
      } catch (e) {
        if (!(isAbortError(e))) {
          queueMicrotask(() => {throw e});
        }
      }
    })();
    return () => controller.abort();
  }, deps);
};

Интересное решение от XCENA на эту же тему.

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

Естественно никто кроме него ей пользоваться не сможет. Тем не менее им удалось - это не распаянная память которая в тоже время очень близко к ЦПУ.

Кстати о нем - это in house разработка с тысячами RISC-V ядрами.

Вставляется это чудо в PCIe 6 (модель MX1) либо сразу в два таких сорта (MX1S).

Про софтверную часть ничего не известно, будет ли она работать в роли CUDA устройства или как то иначе. Но было бы интересно иметь такую карточку с 4мя планками 128 GB

А в знали что можно определить был ли ваш модуль импортирован динамически или нет?

// init.js

export function then(resolve, reject) {
   reject('Nope! Import this statically please')
}

Уже можно попробовать
https://tryandromeda.dev/

Если вдруг по какой-то причине вам надо будет рендерить только css и html без js (ну например - почтовый клиент) то есть такая вот штука Blitz.
Так же он умеет рендерить markdown.

Через раcширения поддерживает - canvas, fetch (для подтягивания ресурсов извне), noscript и так далее.

Мне тут на глаза попался продукт со смешным названием
Nvidia Jetson Orin Nano Super Пупер

При этом спека совсем не шуточная:
В этом девайсе скрестили ARM с Nvidia Карточкой Ampere! (1024 CUDA и 32 тензорных ядер)

В итоге получилась штука для запуска AI моделек с 67 INT8 TOPS и очень быстрой памятью (102 GB/s)

Правда памяти этой всего 8GB так что больше чем 8B модельки на ней не запустить, но если вам важна именно скорость (например VLM - Vision Language Models) это отличный вариант.

Стоит кстати всего $249

Для сравнения - NVIDIA AGX Orin 16GB уже обойдется в $2052

еще альтернативы
https://github.com/jsr-io/jsr

в 25 версии node.js появится пакет node:quic
http3 вам о чем нибудь говорит?
4 года вьетнамской войны ушло на то чтобы заделиверить его в ноду

Платка в m2 слот с AI чипом
Жаль на всего 16GB RAM.

Ну, ооокей
https://demian.ferrei.ro/snake

Вольный TLRD пересказ доклада с ReactConf2025 о том как реакту улучшали перф.

Сначала был сделан бенчмарк для измерения:
- В реакт контексте лежит Map c координатами
- Инпуты добавляют туда значения
- Компоненты в цикле пробегают мапу и селектят по пропу оттуда координаты которые используют в своих стилях.
Реакт рендерил это дело 4 секунды

Потом они прогнали это через реакт компайлер
Рендер стал занимать ~1.2 секунды (благодаря мемоизации)

Потом они переписали реакт на сигналы (на графике - React Forest)

И оказалось что компайлер лучше справляется. Они даже взяли сигналы кем-то уже написаные (преактовские?) - non React signals на графике - чтобы убедиться наверняка.

Потом два года они делали React Fir - novel hybrid eager / lazy incremental rendering, суть которого в том что бы икрементально вычислять изменения в доме (т.е. отказаться от vdom) от изменений в стейте.

Получилось быстро, хотя они так и не реализовали все фичи реакта.

И тут они решили положить в контекст стор вместо мапы

Мастзев набор утилит поверх преактовских сигналов
https://www.npmjs.com/package/@preact-signals/utils

Вот пишешь такой на typenoscript проект, а потом он становиться все больше и больше и в конце концов перф падает до того что вывод типа надо ждать 2 минуты.
А еще позже и вовсе случается это

  error TS7056: The inferred type of this node exceeds the maximum length the compiler will serialize. An explicit type annotation is needed.

И где-то вот тут начинаешь думать что может ворчуны в твиттере были правы и в перспективе больших проектов typenoscript и правда игрушечный язык, и может стоило все таки взять reasonml

Если люди не хотят ставить MAX а упорно сидят в телеграмме надо просто сделать так чтоб телеграмм работал через теже сервера что и MAX

Смотрю тут доклад по vitest от мейнтейнера (Владимир Шеремет)

От самого крутого:

- в vitest с 4 версии будут встроенные браузерные тесты. Причем ничего особо настраивать не нужно. С скриншот тестированием (toMatchScreenshot).

- Но особо отметить хочется то что они могут запускаться прямо в дебагере vscode, хотя выполняются в headless браузере. Ну короче - react компоненты с эффектами можно тестировать как обычный код без кучи сомнительных моков и танцев с бубном.

- на 25% быстрее стартует каждый тест

- Устали ловить флаки тест который воспроизводиться только в CI? Vitest научился генерить playwright трейсы (их потом можно воспроизводить в Trace viewer)
Скачивается как артефакт тестового пайплайна.

- Готов поспорить вы не знали что к тестам можно прикреплять файлы и ссылки (см. КДПВ) через спец апи аннотаций.

- И то что каждый тест принимает signal в виде параметра, так что по ctrl + c или по нажатию кнопочки ⏹️ в ui можно мгновенно прерывать долгоиграющие тесты.

- Теперь можно мокать классы целиком

React Compiler релизнулся. С нетерпением жду докладов кому и насколько он увеличил производительность. Ведь это ещё и статистика того насколько люди понимают как и где оптимизировать реакт на практике. Если это будут 10-15% можно сделать вывод что концепция рендерим все по умолчанию, а что надо мемоизируем в целом рабочая.

Механическая клавиатура но каждая клавиша - с сенсорной поверхностью = тачпад-клавиатура

Сегодня попробовал заюзать tsgo в рабочем проекте.
Сразу оговорюсь - это здоровый монореп где нету разбивки на ts project-ы.
Самое крупное приложение в со всеми зависимостями (не учитывая нод модули) - 4236 ts файла.

С первого раза tsgo (аka ts native) скушал всю оперативку и своп (72 GB) и вылетел по ООМ.
У нас немало циклических зависимостей в конфигурациях, но tsc с ними живет и не зацикливается (благодаря агрессивному кэшированию?) а вот tsgo похоже зациклился.
Пришлось немного навести порядок, выпилить "baseUrl" (tsgo его не поддерживает и судя по всему не будет - вместо него рутом считается директория с tsconfig) и после исправления всех конфигов он таки запустился, вот результаты:

$ time pnpx @typenoscript/native-preview
53,56s user
4,81s system
469% cpu
12,444 total

$ time pnpm --package=typenoscript dlx tsc
95,85s user
3,29s system
147% cpu
1:07,08 total

итого:
tsc - 67 секунд - в полтора потока
tsgo - 12,4 секунд - в 5 потоков

Впечатляет.