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

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

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

Мне тут на глаза попался продукт со смешным названием
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

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

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

И где-то вот тут начинаешь думать что может ворчуны в твиттере были правы и в перспективе больших проектов typescript и правда игрушечный язык, и может стоило все таки взять 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 @typescript/native-preview
53,56s user
4,81s system
469% cpu
12,444 total

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

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

Впечатляет.

Не могу поверить что в инпутах c type="date" значение для min параметра указывается в формате который из Date объекта можно получить только вот таким способом:

new Date().toISOString().split('T')[0];

Не могут же авторы браузерной апи быть настолько аметистами

Web Bluetooth API - это набор апи для того чтобы можно было подключиться к блютуз устройству через браузер.
Мне вот очень не хочется писать для этого мобильное приложение под разные платформы, и я решил его использовать.

И угадайте что - в лисе оно не поддерживается. Хотя тикет был создан 14 лет назад.
3 года назад он был закрыт с пометкой WONTFIX и комментарием (перевод):

Возможно, что позиция Mozilla по поводу этого API изменится в будущем <...> но на данный момент <...> наша официальная позиция заключается в том, что мы считаем ее реализацию вредоносной для Интернета.

И если честно это звучит... не убедительно. Мы же прекрасно понимаем что у маззилы просто нет желания или ресурсов на реализацию, только лишь на сочинение оправданий. Хром вот не считает, зашипил эту апи на 98% пользователей интернета, и теперь ее используют как минимум 50 000 пользователей espruino.com и ничего, брат живой. Может в очередном транше гугла на $ 555 000 000 найдется немножечко денег на то что бы эту апи зашипить. А то лиса скоро растеряет даже тех полтора гика которые у нее остались

Я все еще иногда использую renderProps!
Когда это позволяет избегать избыточной вложенности.

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

Как это обычно пишут (упрощенно):

// Page.tsx
function Page() {
  return (
   <Layout>
     <Header />
     <Form />
     <Footer />
   </Layout>
  )
}

// Form.tsx
function Form() {
  const { pending, error, initialData } = useInitialDataRequest();
  if (error) return <ErrorSplashScreen error={error} />;
  if (pending) return <Spinner />;
  return <FormFields initialData={initialData} />
}

// FormFields.tsx
function FormFields({ initialData }) {
  return <form>
   {/* ... */}
  </form>
}

Теперь если мы будем навигироваться по коду мы будем проходить вот такой вот длинный путь.

A                                                                  
└─► фетчинг данных для B                                     
    └──► B                                             
         └──► фетчинг данных для C                
              └──► C               

(Этот эффект я называю - матрешкой)

Рендер пропы позволяют "вынести за скобки" подготовку данных минуя "технические" прокладки (по сути существующие просто потому, что хуки нельзя вложить в условия), что делает навигацию по коду удобнее*:

// Page.tsx
function Page() {
  return (
   <Layout>
     <Header />
      <InitialDataLoader>
        {initialData => <FormFields initialData={initialData} />}
      <InitialDataLoader/>
     <Form />
     <Footer />
   </Layout>
  )
}

// InitialDataLoader.tsx
function InitialDataLoader({ children }) {
  const { pending, error, initialData } = useInitialDataRequest();
  if (error) return <ErrorSplashScreen error={error} />;
  if (pending) return <Spinner />;
  return children(initialData);
}

// FormFields.tsx (ничего не изменилось)
function FormFields({ initialData }) {
  return <form>
   {/* ... */}
  </form>
}

Теперь мы можем переходить в сразу интересующую нас часть и видеть более цельную струкру

 
A                                                                  
└─► фетчинг данных для B                                     
└──► B                                             
└──► фетчинг данных для C                
└──► C  

Вроде мелочь, а приятно.

Только не забывайте что render пропы в таком виде будут создавать лишний рендер (children функция новая на каждый рендер), поэтому Page здесь лучше сразу обернуть в React.memo

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