WebAssembly намного шире. Возможно использовать библиотеку для криптографии или обработку видео. И можно это писать на разных языках. Плюс это стандарт. Он поддерживается и развивается несколькими браузерами, а котлин зависит только от jetbrains.
Если мы говорим об эффективновности кода, то за нее отвечает среда запуска WebAssembly (в данном случае это браузер) и компилятор, с помощью которого код был скомпилирован в WebAssembly).
Если мы говорим о жизненном цикле (выделени и освобожении памяти) при написании кода, то тут ничего не меняется, если вы пишите на Rust.
Если мы говорим об его контроле памяти во время то тут в дело вступает WebAssembly. Благодаря устройству ее WebAssembly может эффективно читать и писать только в выделенную ему память. Это позволяет единственному web-приложению использовать множество независимых библиотек (использующих WebAssembly) которые могут иметь отдельные и полностью изолированные друг от друга диапазоны памяти. Подробнее тут.
Если мы говорим об управлению стеком. То особенность формата WebAssembly как раз в том, что этот формат стековый. Внутри рантайма, который запускает и исполняет WebAssembly стек свой и управление и выделение памятью происходит отдельно для JS кода со сборкой мусора и для WebAssembly.
Да, я тут именно это и имел ввиду. Скорее опирался на новые веяния фронтеда. Если кто-то пишет про Worker’ы сразу указывает, что он у отдельном потоке исполняется и вызываться с JS с помощью механизма сообщений.
Да, я тут не стал добавлять про использование Worker’ах. Я имел ввиду то, что он конкурирует с исполняется в одном потеке с JavaScript, если ничего с ним не делать.
Что имеется ввиду под сложным кейсом (для всех он разный) ?
Могу привести личный пример. Я неболшой дробдаун, по скорости особых просадок незаметил, единственный момент может вырасти время первой загрузки модуля, даже если он ассинхронный. Но это все решается кэшированием и прогоном через компилятор в более строгом режиме.
Нужно понимать, я использовал такоей пример не для того, чтобы показать какой WebAssembly быстрый. А скорее, что он на нем можно решать не только задачи связанные со сложными алгоритмами, но и верстать UI. К тому же, Rust-имеет более надежную систему типов чем TypeScript, что может помочь в обнаружении ошибок.
Тут нужно понимать, что это непродашнреади решение. Тут нет заморочек с кэшированием модулей, сжатием файлов и сокрашения размера бандра (Особенно для wasm-модуля).
Размеры бандлов:
shell = вендоры (~1Mb uncompressed) + код (~55Kb uncompressed)
react_counter = вендоры (~140Kb uncompessed) + код (~70Kb uncompressed)
Первая проблема была в том, что при выполнении в конвейере нескольких скриптов с ботом последний выполняющийся переписывает результаты работы всех предыдущих. Поэтому я добавил в бот индентификатор, передаваемый через переменную окружения. Идентификатор гарантирует, что каждый скрипт пишет своё сообщение только в свой контейнер. При отсутствии идентификатора и наличии нескольких скриптов, все они будут писать в один контейнер.
Ниже приведу примеры, что я имел ввиду
Без индентификатора
Скрипт проверки качества кода -> контейнер с сообщением №1
Скрипт выбора ревьюера -> контейнер с сообщением №1
С идентификатором
Скрипт проверки качества кода -> контейнер с сообщением №1 (качество кода)
Скрипт выбора ревьюера -> контейнер с сообщением №2 (выбор ревьюеров)
С идентификатором и повторным запуском
Первый прогон
Скрипт проверки качества кода -> контейнер с сообщением №1 (качество кода)
Скрипт выбора ревьюера -> контейнер с сообщением №2 (выбор ревьюеров)
Повторный запуск
Скрипт проверки качества кода -> контейнер с сообщением №1 (качество кода) перетирает сообщение на предыдущем запуске
Скрипт выбора ревьюера -> контейнер с сообщением №2 (выбор ревьюеров) перетирает сообщение на предыдущем запуске
Проблему с перетиранием предыдущего сообщения можно решить путем проверки выбраны ли ревьюеры и выходить из функции.
Планируем сделать то же самое, не поделитесь алгоритмом?
Как раз на днях решал эту проблему. Добавил в общие настройки проекта, список ревьюеров, которых нужно пропускать. Файлик хранить не удобно не хочется, придется создавать новую ветку и подливать ее в мастер, а так перед отпуском добавил ревьюера в исключение и все ок :)
REVIEW_ROULETTE_SKIP_APPROVERS: 'first, second'
Если у вас есть возможность интегрироваться со своей внутренней системой, которая вам может предоставить данные об отпуске сотрудника, можно использовать ее для фильтрации ревьюеров :)
А вот в чем дело!
Тогда хотелось бы узнать, а что использовали из модных штук?:)
Хочется узнать об опыте)
Тут зависит от того не чем его писать. Я так понимаю на Java?
Имеется ввиду проект, который собирается под несколько платформ?
Но кстати про отдельный слой не знал, видимо потому что не пишу на Java или Kotlin:)
В любом случае все кейсы покрыть нет возможности.
Tairu может покрыть все платформы.
electronjs может покрыть десктоп.
Если пишешь на react, то с некоторыми особенностями можно тоже все платформы покрыть.
Можно даже сделать проще написать pwa приложение и оно будет работать на всех платформах.
Вариантов сделать одно и тоже сейчас очень много. Но лучше использовать тот, который не зависит от одного вендора.
А зачем?)
kotlin multiplatform - это только про ui.
WebAssembly намного шире. Возможно использовать библиотеку для криптографии или обработку видео. И можно это писать на разных языках. Плюс это стандарт. Он поддерживается и развивается несколькими браузерами, а котлин зависит только от jetbrains.
Давайте разбираться:)
Если мы говорим об эффективновности кода, то за нее отвечает среда запуска WebAssembly (в данном случае это браузер) и компилятор, с помощью которого код был скомпилирован в WebAssembly).
Если мы говорим о жизненном цикле (выделени и освобожении памяти) при написании кода, то тут ничего не меняется, если вы пишите на
Rust.Если мы говорим об его контроле памяти во время то тут в дело вступает WebAssembly. Благодаря устройству ее WebAssembly может эффективно читать и писать только в выделенную ему память. Это позволяет единственному web-приложению использовать множество
независимых библиотек (использующих WebAssembly) которые могут иметь
отдельные и полностью изолированные друг от друга диапазоны памяти. Подробнее тут.
Если мы говорим об управлению стеком. То особенность формата WebAssembly как раз в том, что этот формат стековый. Внутри рантайма, который запускает и исполняет WebAssembly стек свой и управление и выделение памятью происходит отдельно для JS кода со сборкой мусора и для WebAssembly.
Круто, что ты заметил такой глубокий нюанс:)
После твоего комментария так и чешутся руки поправить текст
На счет emscripten и его библиотек, и опционального использования сильно не углублялся. Спасибо что подсветил.
На сколько я помню в Yew тоже можно от него оказаться. Но у меня были сложности с встраиванием его как микрофронтенд. Поэтому решил не заморачиваться.
Да, я тут именно это и имел ввиду. Скорее опирался на новые веяния фронтеда. Если кто-то пишет про Worker’ы сразу указывает, что он у отдельном потоке исполняется и вызываться с JS с помощью механизма сообщений.
Да, я тут не стал добавлять про использование Worker’ах. Я имел ввиду то, что он конкурирует с исполняется в одном потеке с JavaScript, если ничего с ним не делать.
Полностью с тобой согласен. Ты более подробно раскрыл:)
Что имеется ввиду под сложным кейсом (для всех он разный) ?
Могу привести личный пример. Я неболшой дробдаун, по скорости особых просадок незаметил, единственный момент может вырасти время первой загрузки модуля, даже если он ассинхронный. Но это все решается кэшированием и прогоном через компилятор в более строгом режиме.
Нужно понимать, я использовал такоей пример не для того, чтобы показать какой WebAssembly быстрый. А скорее, что он на нем можно решать не только задачи связанные со сложными алгоритмами, но и верстать UI. К тому же, Rust-имеет более надежную систему типов чем TypeScript, что может помочь в обнаружении ошибок.
Тут нужно понимать, что это непродашнреади решение. Тут нет заморочек с кэшированием модулей, сжатием файлов и сокрашения размера бандра (Особенно для wasm-модуля).
Размеры бандлов:
shell = вендоры (~1Mb uncompressed) + код (~55Kb uncompressed)
react_counter = вендоры (~140Kb uncompessed) + код (~70Kb uncompressed)
yew_counter = wasm (~2.4Mb uncompressed = 600Kb compressed) + обвязка (130Кb uncompressed)
Ниже приведу примеры, что я имел ввиду
Без индентификатора
С идентификатором
С идентификатором и повторным запуском
Проблему с перетиранием предыдущего сообщения можно решить путем проверки выбраны ли ревьюеры и выходить из функции.
Напиши мне в личку, обсудим
Да, мы тоже такое сделали. И перенесли бота из пайплайна в мессенджер.
Как раз на днях решал эту проблему. Добавил в общие настройки проекта, список ревьюеров, которых нужно пропускать. Файлик хранить
не удобноне хочется, придется создавать новую ветку и подливать ее в мастер, а так перед отпуском добавил ревьюера в исключение и все ок :)Если у вас есть возможность интегрироваться со своей внутренней системой, которая вам может предоставить данные об отпуске сотрудника, можно использовать ее для фильтрации ревьюеров :)
Ответил выше:)
У нас self-hosted. У danger-js есть дока по подключения бота для self-hosted gitlab. https://danger.systems/js/usage/gitlab.html