CEO Surge Эдвин Чен: ИИ создаёт сотрудников, чья производительность в сто раз выше среднестатистической

ИИ забывает какие главные герои

Вроде как эта известная проблема - что забывает героев, лица, контекст.
Думаю, когда эта проблема будет решена - а она скорее всего будет решена (может быть в БД будет ИИ героев записывать), то ИИ шагнёт далеко вперёд и сможет написать книгу, острый сюжет. А автор уже доведёт эту рыбу до ума

CEO Surge Эдвин Чен: ИИ создаёт сотрудников, чья производительность в сто раз выше среднестатистической

Крестьянин того времени не знал, как починить машину, какую таблетку купить в аптеке, как установить windows. Да даже перевести по СБП он не мог, только голубиной почтой

Верните непрерывную интеграцию разработчикам

Попробуйте поднять версию MUI4 на MUI5/6/7 или React 17 на 18/19.

У компаний уходят на это месяцы и то не факт, что получается с первого раза

Количество просмотров на Rutube за год увеличилось в 7,5 раза, всего с начала года в сервисе просмотрено 26 млрд роликов

На рутубе куча пиратки - аниме, сериалы, фильмы. Зайти туда и посмотреть что-то порой уже легче, чем искать фильмы/сериалы на пиратских сайтах

Почему разработка через тестирование (TDD) не приводит к плохому коду

Нужно задать вопрос - как часто нужно TDD и тестирование в целом?

На примере фронта - компоненты из ui-библиотеки тестировать смысла практически нет, свои простые компоненты можно и на мой взгляд лучше тестировать визуально через Storybook (если нужно, там есть функционал play для тестирования), сетевой код особо не протестируешь.

Остаётся небольшой класс задач типа utils - работа со временем, величинами, различными приведениями. Их можно и нужно тестировать. Но они занимают крайне малый объём кода относительного всего проекта с компонентами и большая часть уже протестирована в библиотека date-fns, ramda и т.п.

Отсюда был сделан вывод для нашего проекта - тестируются только utils функции, которые лежат в library. А написать небольшие тесты через TDD методологию или просто написать тесты становится совсем некритичным.

Почему Feature-Sliced Design (FSD) не спасет ваш проект

В относительно небольших проектах

FSD и не нужно. Любая структура будет достаточна для небольших проектов, т.к. там нужно решать проблемы небольших проектов.
А на средних и больших появляются проблемы, дополнительно связанные с FSD.

Почему Feature-Sliced Design (FSD) не спасет ваш проект

Личное мнение
FSD - крайне нерабочая архитектура, в которой сделано 30% нормально, как во всех других архитектурных (наличие папок - да да, они везде есть) и оставшиеся 70% хайп и переусложнения.

В итоге архитектура на FSD превращается в легаси, от которого хочется избавиться и привести проект к более классическому, каноническому виду.

Если в проекте или модуле нужны папки /pages, /components, /api и /utils - то просто создайте их и не делайте мозги себе и команде.

Ценность от FSD крайне преувеличена, а legacy от этого подхода придётся разбирать ещё N лет разработчикам, которые придут после новаторов, которые затащили FSD в проект.

Также она FSD абсолютно сломано без плагинов, которые запрещает импорты компонентов из слоев, которые не должны пересекаться. А без этих плагинов вся головная боль и ответственностьложится на голову разработчиков.

Zod v4: Стал в 17 раз медленнее? (и почему это важно)

Понял, спасибо. Не знал этого

Google представила ИИ-генератор видео Veo 3

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

Есть галлюцинации, но порой они делают книги веселее)

Тестовые идентификаторы: как и где расставлять правильно

Полуавтомтический data-test-id='clients-search__SearchClientInput-lastName--item'

У нас nx-монорепозиторий. Есть соглашение, что в каждом модуле (1-2 страницы со своим api) вложенность компонентов только на 1 уровне - т.к. нет components/a/b/c.

Делюсь рабочим простым, но эффективным рабочим кодом по генерации test-id. Его положили модуль library.

const getString = (text: string | number | null, divider: string) => (text?.toString() ? `${divider}${text}` : '');

export const getTestId =
  (module?: string | null) =>
  (component: string, componentId: string | number | null = '') =>
  (element: string | null = '', modifier: string | number | null = '') => {
    const moduleTitle = module ? `${module}__` : '';

    return `${moduleTitle}${component}${getString(componentId, '_')}${getString(element, '-')}${getString(
      modifier,
      '--'
    )}`;
  };

Для каждого модуля создаём функцию, которая содержит имя модуля. Например, для модуля clients-search.

import { getTestId } from '@bcs/library';

export const useTestId = getTestId('clients-search');

И в самом модуле, в компонент используем useTestId() для компонентов.

import { useTestId } from '../../utils/useTestId';

export const SearchClientInput: React.FC<ISearchClientInput> = ({ name, title, error, value, handleChange }) => {
  const testId = useTestId('SearchClientInput');

  return (
    <FormControl data-test-id={testId()} error={Boolean(error[name])} key={name}>
      <InputLabel htmlFor={name}>{title}</InputLabel>
      <Input
        data-test-id={testId(name)}
        type='text'
        name={name}
        value={value}
        inputProps={{
          'data-test-id': testId(name, 'item'),
        }}
        onChange={handleChange}
      />
      <FormHelperText data-test-id={testId(name, 'error')}>{error && error[name]}</FormHelperText>
    </FormControl>
  );
};

Плюсы такой функции - утилиты:

• Минимальное количество сил для уникальных названий, не надо думать! Достаточно, чтобы в 1 компоненте префикс не повторялся testId('префикс').

• При том очень стабильное поведение. Изменяется только когда сам компонент (его название) меняет название. А это как правило в следствии меняющих требования доработок.

• Уникальность работает в рамках нашей архитектуры, где только 1 уровень вложенности. Кстати, как показывает время - очень простое и удобное решение (по сравнению с FSD xD )

Zod v4: Стал в 17 раз медленнее? (и почему это важно)

Хорошо бы добавить в сравнительную таблицу Sury валидатор Yup - у нас на работе используется.
Посмотреть сравнение по скорости с другими валидаторами

Новая маленькая, но полезная утилита: password.hyoo.ru -...

Скорее всего она лежит в $mol_crypto папке.
Я нашёл такой код, который ссылается на $mol_crypto_sacred_pass https://github.com/hyoo-ru/mam_mol/blob/master/crypto/sacred/pass/pass.ts#L4

Разбор интервью с автором TypeScript о портировании его на Go

Из ветки ответ соавтора, гугл-переводчик.

>>> https://github.com/microsoft/typescript-go/discussions/411#discussioncomment-12466988

Наше решение портировать на Go подчеркивает нашу приверженность прагматичным инженерным решениям. Мы сосредоточились на достижении наилучшего возможного результата независимо от используемого языка. В Microsoft мы используем несколько языков программирования, включая C#, Go, Java, Rust, C++, TypeScript и другие, каждый из которых был тщательно выбран на основе технической пригодности и производительности команды. Фактически, C# по-прежнему остается самым популярным языком внутри компании, безусловно.

Переход компилятора TypeScript на Go был обусловлен определенными техническими требованиями, такими как необходимость структурной совместимости с существующей кодовой базой на основе JavaScript, простота управления памятью и способность эффективно обрабатывать сложную обработку графов. После оценки многочисленных языков и создания нескольких прототипов — в том числе на C# — Go оказался оптимальным выбором, обеспечивая отличную эргономику для обхода дерева, простоту выделения памяти и структуру кода, которая точно отражает существующий компилятор, что обеспечивает более простое обслуживание и совместимость.

На зелёном поле это был бы совсем другой разговор. Но это было не зелёное поле — это порт существующей кодовой базы с 100 человеко-лет инвестиций. Да, мы могли бы перепроектировать компилятор на C# с нуля, и это бы сработало. Фактически, собственный компилятор C#, Roslyn, написан на C# и сам себя загружает. Но это не было перепроектированием компилятора, и переход с TypeScript на Go был гораздо более автоматизированным и более однозначным в своём отображении. Наша существующая кодовая база — это все функции и структуры данных — без классов. Идиоматический Go выглядел так же, как наша существующая кодовая база, поэтому порт был значительно упрощен.

Хотя это решение хорошо подходило для конкретной ситуации TypeScript, оно не умаляет наших глубоких и постоянных инвестиций в C# и .NET. Большинство сервисов и продуктов Microsoft в значительной степени зависят от C# и .NET из-за их непревзойденной производительности, надежной экосистемы и высокой масштабируемости. C# отлично подходит для сценариев, требующих быстрой, поддерживаемой и масштабируемой разработки, поддерживая критически важные системы и многочисленные внутренние и внешние решения Microsoft. Современный, кроссплатформенный .NET также обеспечивает выдающуюся производительность, что делает его идеальным для создания облачных сервисов, которые без проблем работают в любой операционной системе и у нескольких поставщиков облачных услуг. Недавние улучшения производительности в .NET 9 еще раз демонстрируют наши постоянные инвестиции в эту мощную экосистему ( https://devblogs.microsoft.com/dotnet/performance-improvements-in-net-9/ ).

Давайте будем реалистами. Использование Microsoft Go для написания компилятора для TypeScript было бы невозможно или немыслимо в прошлые годы. Однако за последние несколько десятилетий мы увидели сильную и постоянную приверженность Microsoft программному обеспечению с открытым исходным кодом, отдавая приоритет производительности разработчиков и сотрудничеству с сообществом. Наша цель — предоставить разработчикам лучшие доступные инструменты, не обремененные внутренней политикой или узкими ограничениями. Эта свобода выбора правильного инструмента для каждой конкретной работы в конечном итоге приносит пользу всему сообществу разработчиков, стимулируя инновации, эффективность и улучшенные результаты. И вы не можете спорить с десятикратным результатом!

Ни один язык не идеален для всех задач, и в Microsoft мы празднуем силу, которая исходит от разнообразия языков программирования. Наша приверженность C# и .NET остается сильнее, чем когда-либо, мы постоянно совершенствуем эти технологии, чтобы предоставить разработчикам инструменты, необходимые для успеха сейчас и в будущем.

Webpack, Vite или Rspack: что это за зоопарк или чем собирать микрофронтенды в 2025?

Да, есть сложности с архитектурой в проекте в виде связанных 50 микромодулей nх.
Но на вебпаке этой проблемы не возникает, а на vite повылазили

Webpack, Vite или Rspack: что это за зоопарк или чем собирать микрофронтенды в 2025?

Если есть возможность, дополните статью компонентами на 3000 и 5000 элементов (можно больше).
3000+ компонентов - это нормальное среднее количество для проектов в несколько лет.

Мы не можем переехать с Webpack на Vite по причине того, что HMR в Vite примерно на 3000+ компонентах начинает работать крайне медленно из-за особенности сети. Закачиваются 3000 легковесных файлов компонентов, но полностью нагружают Network в консоли.
Может быть они уже починили и всё заработает.

Связанные issues с этим: https://github.com/vitejs/vite/discussions/4803 , https://github.com/vitejs/vite/issues/13570

Надо будет попробовать Rspack, посмотреть как он себя ведёт на больших количествах компонентов

Борьба с перерендерами в React

Перерендеры переоценены, пока они не начнут вызывать явное замедление проекта.

Силы и время, потраченное на бездумное написание useRef/useCallback/memo в каждом компоненте чаще всего только вредят.
Нагрузка на чтение кода с useRef/memo/useCallback возрастает в разы, а связанные с этим баги (забыли пропс в зависимости добавить и т.п.) трудно отловить сразу.

Пишите простой код, пока ваше приложение не начнёт явно замедляться. Потом лучше сделать рефакторинг и пересобрать композицию компонентов, чтобы созависимых компонентов было меньше.
P.S. React 19 движется в этом направлении - React Compiler

Кейс применения useMemo и useCallback в React для оптимизации рендеринга при изменении глобального состояния

Спасибо за статью, было интересно почитать про внутреннее устройство конструктора кликеров.

Волосы:

1. Обновлялись до React 19? Вроде как там обещают оптимизацию useMemo/useCallback

2. Использовать в каждом компоненте useCallback/ useMemo - означает быть подверженным человеческому фактору - лень, забыл, сроки горят. Искали ли вы системное решение данной библиотеки в виде другой библиотеки/своего хука. Мб замена redux на Zustand/Mobx сможет излечить одну из этих родовых травм?

3. Ещё возможно вариант, что вам нужно дополнительно оптимизировать Инпуты - чтобы они не делали лишние действия

Состоялся релиз Bun 1.2 — среды выполнения JavaScript и TypeScript

В статье показали сравнение с Express.
Но как дела обстоят с другими быстрыми фреймворками на bun? Увеличит ли он их скорость в 3 раза?

Fastify - 72158 rps, Koa - 52542 rps.
Из статьи https://habr.com/ru/articles/798469/

useActionState: новый герой в мире React

Писать реакт на классах норм?

От мидла к синьору. Часть первая

Сегодня ты сеньёр крутой, а завтра мидл простой.
(При переходе из одной компании в другую. Работает и в обратную сторону).