Анализируем виды тестов для Frontend

Если честно, тесты были даны в качестве наглядных примеров, чтобы читатель понимал, как каждый из видов выглядит в коде на популярных фреймворках/библиотеках ? но все равно спасибо за работу и комментарий!

JSX: как разделять логику и отрисовку в разметке, сгенерированной методом map

А почему вы не использовали паттерн RenderProps ?
C его помощью можно гибко резделять логику и отображение. И отдельно тестировать доменную и тестировать логику будет намного проще.

type User = {
  name: string;
  // другие пропсы
};
// Чистая функция, можно протестировать
function composeUser<T extends User>(
  user: T,
): { fullName: string; date: string; statusColor: string } {
    const fullName = `
    ${user.name.name}
    ${user.name.patronomic ? user.name.patronomic : ''}
    ${user.name.surname}
  `.toLowerCase();
    const date = user.regestrationDate ? moment(user.regestrationDate) : null;
    const statusColor = ["В сети", "Не в сети"].includes(user.status.description)
      ? STATUS_COLORS[user.status.value]
      : "neutral";

  return { fullName, date, statusColor };
}

const Users: FC<{ data: User[]; renderFn: (user: User) => void }> = ({
  data,
  renderFn,
}) => {
  return <>{data.map(renderFn)}</>;
};

const App: FC = () => {
  /// откуда то получаем users

  return (
      <ul className="list">
        <Users
          data={[{ name: "username1" }, { name: "username2" }]}
          renderFn={(c) => {
            const { fullName, date } = composeUser(c);
            return (
              <>
                <li>{fullName}</li>
                <li>{date}</li>
              </>
            );
          }}
        />
    </ul>
  )
}

Использование never в TypeScript опустим мы хотим написать...

Другими словами, ты хочешь добиться поведения похожего на `Discriminated Union`

type Common =  {title: string}

enum R {
    A = 'a',
    B = 'b',
}

type A = Common & {type:  R.A, r: string};

type B = Common & {type: R.B,c: string};

type Props =  A | B;

const a: Props = {
    title: '12',
    type: R.A,
    r: '12',
    c: '12' // Object literal may only specify known properties, and 'c' does not exist in type 'A'
}

Использование never в TypeScript опустим мы хотим написать...

Понял, логика в том, чтобы значение было недоступно даже для присваивания :)

Использование never в TypeScript опустим мы хотим написать...

Почему нельзя было упросить интерфейс до состояния ниже?

type DialogProps = { title: string } & (
  | {
      responsive: boolean;
    }
  | {
      width: number;
      height: number;
    }

);

WebAssembly: короткий обзор ассемблера для фронтенда

Спасибо за уточнение:)

Приведенный вами комплект очень сложный и написать его производительную версию бывает не просто, используя React.

Что на счет Yew. Фронтенд на Yew обещает быть эффективным, но в данном примере утверждать не могу Могу предложить посмотреть на что-то отдаленно похожее в yew-examples.

Я в проде еще не использовал фронтенд на Yew или любом другом фрецмворке/библиотеке на WebAssembly поэтому такого детального опыта у меня нет. Посоветовал спросить у pkirill, он более подробно может сказать о производительности WebAssembly в таких сложных сценариях :)

WebAssembly: короткий обзор ассемблера для фронтенда

Остальные поизучаю, спасибо)

WebAssembly: короткий обзор ассемблера для фронтенда

Сейчас он широко распространяется в отрасли и поддерживается многими языками, в том числе и со сборкой мусора (Garbage Collection). Совсем недавно поддержка стандарта появилась в Google Chrome и Mozilla Firefox.

Да это я уже указал в статье :)

WebAssembly: короткий обзор ассемблера для фронтенда

Все зависит от ... :)

Для JS поведение браузеров тоже может разнится в некторых специфических случая. Нативная скорость плучается не всегда. Поэтому и указано близкую к нативной. Безусловно есть свои особенности и у исполения WebAssembly.

Тут идет речь скорее про то, что VM старается приблизить программу на нативном языке в исполняемый модуль WebAssembly. А не про то, что она всегда будет нативной и быстро исполнятся.

Максимальная производительность WebAssembly равна максимальной производительности
JavaScript, но написать оптимизированный по памяти код иногда проще на
WebAssembly

В статье есть важное дополнение. Я бы посоветовал вам почитать статью про использование WebAssembly и сравнение скоростей . :)

WebAssembly: короткий обзор ассемблера для фронтенда

Можешь ссылочку закинут?)

WebAssembly: короткий обзор ассемблера для фронтенда

Спасибо, сохранил для просмотра:)

WebAssembly: короткий обзор ассемблера для фронтенда

То есть по сути вся обвязка превращается в JS. А есть пример архитектуры? Очень интересно как связывается с модулем на wasm конкретно в Java

WebAssembly: короткий обзор ассемблера для фронтенда

Понял, ну или как babel?

WebAssembly: короткий обзор ассемблера для фронтенда

Я не очень разбираюсь в синтаксисе Java. Поэтому исходники этой либы изучать не полез. Подскажи, во что он перегоняет Java? В строки или в более сложные структуры?

WebAssembly: короткий обзор ассемблера для фронтенда

Я правильно понимаю, что все это обвязка для org.teavm ?

WebAssembly: короткий обзор ассемблера для фронтенда

Обвязок вроде немного. Но кажется, что есть скрытые хитрости в org.sudu.experiments:)

Где найти все что лежит в org.sudu.experiments ?

WebAssembly: короткий обзор ассемблера для фронтенда

Не открывается(

WebAssembly: короткий обзор ассемблера для фронтенда

Я в этой технологии новичок и не могу знать все нюансы на данной момент. На как и в любой технологии все зависит от многого количества факторов. Да, Wasm сейчас развивается в семимильными шагами учитывая, что он разрабатывается как стандарт (перичеслять все плюсы еще раз не будут). Но тут вопрос скорее в дальнейшем развитии и стратегии. Если они будут добавлятья новые крутые фичи, возможно в ближайшее время не нужно будет использовать JS для запуска или писать кучу обвязок. Тогда его популярность значительно вырастет. Но нельзя не отметить что на данном этаме она достачно высока (список поддерживаемых языков достачно большой).

На счет статьи спасибо:)

WebAssembly: короткий обзор ассемблера для фронтенда

Почитать про скорость можно в тут:

• https://mrale.ph/blog/2018/02/03/maybe-you-dont-need-rust-to-speed-up-your-js.html#profiling-the-pure-javascript-version

• https://00f.net/2023/01/04/webassembly-benchmark-2023/

• https://cyberleninka.ru/article/n/issledovanie-webassembly-i-sravnenie-proizvoditelnosti-s-javascript/viewer

Посмотреть:

• https://www.youtube.com/watch?v=s5YihAhAlSM

• https://www.youtube.com/watch?v=InDkFI_LwGM&t=2212s

Есть инструмент PSPDFkit и у него реальной работы wasm https://pspdfkit.com/webassembly-benchmark/ https://pspdfkit.com/webassembly-benchmark/

WebAssembly: короткий обзор ассемблера для фронтенда

В достоинства я это добавил потому, что есть возможность обращаться к DOM и браузерному API. К примеру, если мы бы брали Worker’ы, то они не могут работать с DOM, а браузерное API у него доступно не все. Да с хаками, но можно это главный посыл был. А про связь с JS для общего понимания, чтобы читатели, не знавшие об этом сразу понимали текущую картину.

IMHO правильное наименование этому решению - компромис: между вохможностью доступа к DOM вообще и безопасностью/трудоемкостью реализции интерфейса доступа.

Да, безопастность одно из главных причин. Я думаю, что именно поэтому сейчас есть возможность доступа только через JS. Плюс для запуска все равно нужен JS. Поэтому без накладных расходов никак.

PS А вообще я уже видел в жизни попытки реализовать работу в браузере программ на других языках, компилируемых в JavaVM bytecode (Java Applets) и .NET IL (Silverlight) - не то, чтобы они закончились совсем уж провалом, но, в целом, не взлетели. Но шуму вокруг было не меньше.

Очень интересное замечание. Есть много причин почему они не взлетели и почему может не взлететь WebAssembly. Вы будто правило расшифровали цитату, которую я оставил в конце:)