Dev News от Максима Соснова

SVG Coding Examples: Useful Recipes For Writing Vectors By Hand

Огромный гайд по рисованию SVG в JS на Smashing Magazine.

Начинается все с основ: что за поле используется в SVG, как управлять его размером, что с единицами измерения. Затем гайд переходит в варианты создания простых svg примитивов (линии, квадраты, окружности, овалы) в JS, затем переходит к более сложным техникам (полигоны, паттерны).

С одной стороны, достаточно простая по смыслу статья (ну, признаемся честно - рисовать SVG из базовых примитивов - это не рокет сайнс), с другой стороны - это крутая вводная статья по SVG.

https://www.smashingmagazine.com/2024/09/svg-coding-examples-recipes-writing-vectors-by-hand/

#development #svg #recommended

Unleash JavaScript's Potential with Functional Programming

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

Объяснение начинается с определений - что такое примитив, что такое композируемая сущность, что такое функция и из чего она состоит и тд и тп. Заканчивается все применением каррирования.

Контент скорее полезен для джунов, позволяя им мягко погрузиться в основу композиции функций. Если вы отличаете каррирование от частичного применения и знаете что такое монады - смело скипайте - ваш текущий уровень понимания ФП выше, чем тот, который дает статья.


https://janhesters.com/blog/unleash-javascripts-potential-with-functional-programming

#development #javascript #functionalProgramming

Дайджест за 2024-10-14 - 2024-10-18

Bundling - Past, Present, and Future
Давненько в канале не было видео-контента. В основном, потому что я сам не люблю видео контент, больше читаю. Но вот есть неплохой видел на английском от создателя Parcel про историю бандлинга в вебе.

Неплохо рассказывается история бандлинга и модульности в JS-экосистеме от AMD модулей и до современных тулов и проблем

Nodejs dev - fastify book
Есть среди подписчиков чел, который делает свои сайты-документашки по популярным инструментам. Они уже попадали в канал. В этот раз появился сайт-документашка по fastify.

Гайды - моё уважение, очень подробные, объясняют все шаг за шагом. Если вы хотите изучить fastify или изредка пишете на нем, и вам иногда нужна дока - сохраняйте в закладки.

Деконструкция монолита: Максимально производительный подход к проектированию программ
Перевод статьи о том, как shopify переходил от монолита к модульному монолиту. Shopify был огромным монолитом на Ruby on Rails, в который на протяжении более десяти лет вносили изменения свыше тысячи разработчиков. В какой-то момент команда осознала, что текущее решение необходимо декомпозировать

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

⭐️Canon TDD
Статья от Кента Бека (автора TDD) про TDD. Основная проблема TDD в том, что его неправильно понимают и применяют. Кент Бек в очередной раз рассказывает, как правильно применять каноничный TDD.

В целом, TDD действительно трактуется достаточно широко. Кто-то понимает это как "тесты перед разработкой", кто-то использует для описания процесса, где просто пишутся тесты. Сам по себе термин TDD не самый удачный, т.к. по смыслу под него подходит очень много вариаций процесса разработки. Кент Бек, если мне не изменяет память, где-то уже писал что это не самое удачное название, но зато оно достаточно понятное и позволило практике закрепиться и стать популярной

Улучшение производительности рендеринга с помощью CSS content-visibility
Перевод небольшой статьи от автора emoji-picker-element (компонент для выбора эмодзи) про увеличение производительности рендера этого компонента. Каждый эмодзи состоит из двух элементов - button и img. Достаточно простая верстка. Однако, пользователи компонента пожаловались на медленную работу компонента. Оказалось, что у них более 19 тысяч эмодзи в селекте, из-за чего браузер "подвисает" на пару секунд

Для картинок уже использовался loading=lazy, поэтому такой долгий рендер не был связан с загрузкой почти 20 тысяч картинок. Можно было бы добавить виртуализированный список, но это усложняет решение и делает компонент хуже с точки зрения доступности (хотя, конечно, сложно назвать список из 20к элементов доступным в принципе)

——————————————

Спасибо что читаете, ставите реакции и отмечаетесь в комментариях. Если вы хотите помочь каналу - расскажите о нем своим коллегам или друзьям. Также оставляйте фидбек по формату, материалу и чему-угодно еще 🙂

Улучшение производительности рендеринга с помощью CSS content-visibility

Перевод небольшой статьи от автора emoji-picker-element (компонент для выбора эмодзи) про увеличение производительности рендера этого компонента. Каждый эмодзи состоит из двух элементов - button и img. Достаточно простая верстка. Однако, пользователи компонента пожаловались на медленную работу компонента. Оказалось, что у них более 19 тысяч эмодзи в селекте, из-за чего браузер "подвисает" на пару секунд

Для картинок уже использовался loading=lazy, поэтому такой долгий рендер не был связан с загрузкой почти 20 тысяч картинок. Можно было бы добавить виртуализированный список, но это усложняет решение и делает компонент хуже с точки зрения доступности (хотя, конечно, сложно назвать список из 20к элементов доступным в принципе)

Первым делом автор использовал css content-visibility. Это новый фукционал CSS, который позволяет "скрыть" элементы с точки зрения вёрстки и рисования. При этом контент все еще будет доступен в дереве доступности и по нему можно делать поиск по страницу (ctrl+F). Единственное что нужно - уметь предрасчитать размер скрываемых элементов.

После применения content-visibility, прирост в производительности составил 15% - заметно, но не то что ожидалось. Дальнейшее погружение в перформанс показало, что не смотря на loading="lazy", картинки все еще как-то обрабатываются браузером. Следующее решение: заменить img на background-image, но только если элемент с эмодзи появился на экране. Для этого используется IntersectionObserver. Данная техника позволила ускорится на 40%

Автор на этом остановился - он получил достаточно хорошее ускорение. Однако, это не масштабируемое решение (для списка из 200к элементов загрузка будет заметной). В идеале следовало бы использовать виртуализацию списка, но это усложняет компонент, поэтому пока остается так. Стоит заметить, что использование content-visibility и IntersectionObserver относительно "бесплатное" (делается за час времени), но дает огромное ускорение.

https://habr.com/ru/articles/846842/

#development #css #performance

Canon TDD

Статья от Кента Бека (автора TDD) про TDD. Основная проблема TDD в том, что его неправильно понимают и применяют. Кент Бек в очередной раз рассказывает, как правильно применять каноничный TDD.

В целом, TDD действительно трактуется достаточно широко. Кто-то понимает это как "тесты перед разработкой", кто-то использует для описания процесса, где просто пишутся тесты. Сам по себе термин TDD не самый удачный, т.к. по смыслу под него подходит очень много вариаций процесса разработки. Кент Бек, если мне не изменяет память, где-то уже писал что это не самое удачное название, но зато оно достаточно понятное и позволило практике закрепиться и стать популярной

В этой статье Кент Бек снова рассказывает о каноничном TDD, которое он описывал в своих книжках

TDD помогает разработчику изменить систему так что:
- Все что работало, продолжает работать
- Новое поведение работает как ожидается
- Система готова к применению новых изменений
- Разработчик и его коллеги уверены в верности предыдущих высказываний

Шаги по реализации TDD:

1) Список тестов. Первый шаг - описать список всех ожидаемых вариаций нового поведения. При этом не следует думать о том, как это будет работать технически (ОК думать о том, что состояние заказа изменится, но не ОК думать о том, в какие поля БД будут записаны данные).
2) Выберите тест из списка тестов и напишите его. Один тест. Полноценный тест с фазами подготовки, запуска и проверки. Типичные ошибки: писать тесты без проверок; писать сразу кучу тестов.
3) Сделайте так, чтобы тест прошел. Типичные ошибки: удалять проверки; копировать вычисленные значения в проверки; делать рефакторинг в этой фазе (умная мысль на запомнить - "Make it run, then make it right"). Если во время реализации вы понимаете, что нужен еще 1 тест - запишите его в список тестов из списка 1. После того как тест прошел, вычеркните его из списка тестов (он реализован)
4) Опциональный рефакторинг. Типичные ошибки: слишком глубокий рефакторинг, который не требуется сейчас; Слишком раннее создание абстракций
5) Если список те стов еще не пуст, перейдите к пункту 2.

В статье также есть крутая визуализация этого алгоритма.

https://tidyfirst.substack.com/p/canon-tdd

#development #TDD #kentBeck #recommended

Деконструкция монолита: Максимально производительный подход к проектированию программ

Перевод статьи о том, как shopify переходил от монолита к модульному монолиту. Shopify был огромным монолитом на Ruby on Rails, в который на протяжении более десяти лет вносили изменения свыше тысячи разработчиков. В какой-то момент команда осознала, что текущее решение необходимо декомпозировать

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

Однако монолит не лишен и проблем. Начиная с определенного размера монолиты становится тяжело развертывать и поддерживать инфраструктурно. Также, из-за отсутствия четких границ между кодом внутри монолита, небольшие изменения, которые кажутся изолированными, могут сломать что-то в месте, где изменений не ожидается. Фронтенд-специфичная аналогия: поправил шапку сайта, сломалась форма оплаты. Из-за отсутствия явных границ разработчикам нужно держать в голове большой скоуп знаний, тестировать это также сложно.

У shopify стоял выбор между микросервисами и модульным монолитом. Микросервисы являются стандартом в индустрии, но они также несут в себе кучу сложностей. Поэтому команда shopify решила оставить преимущества монолита (простота деплоя и поддержки инфраструктуры), но решить недостатки добавлением модульности

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

Т.к. shopify достаточно большой, то нельзя просто взять и единомоментно переехать на новую структуру системы. Для этого был разработан план плавной миграции на новую архитектуру

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

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

https://habr.com/ru/companies/piter/articles/844572/

#development #monolith #microservices #modularMonolith

Nodejs dev - fastify book

Есть среди подписчиков чел, который делает свои сайты-документашки по популярным инструментам. Они уже попадали в канал. В этот раз появился сайт-документашка по fastify.

Гайды - моё уважение, очень подробные, объясняют все шаг за шагом. Если вы хотите изучить fastify или изредка пишете на нем, и вам иногда нужна дока - сохраняйте в закладки.

https://nodejsdev.ru/frameworks/fastify.3.book/

#development #javascript #nodejs #fastify

Bundling - Past, Present, and Future

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

Неплохо рассказывается история бандлинга и модульности в JS-экосистеме от AMD модулей и до современных тулов и проблем

https://www.youtube.com/watch?v=JUS6EPMbk0U

#development #javascript #bundlers #youtube #video

Дайджест за 2024-10-07 - 2024-10-11

ts-blank-space
Bloomberg заопенсорсили свой компилятор TS в JS. Это, конечно, сложно назвать компилятором - он очень быстро удаляет весь синтаксис TS и оставляет только нативный синтаксис JS.

Сам инструмент максимально простой: парсит AST, находит токены, связанные с TS и заменяет их на пробелы (поэтому blank-space в названии).

stricli
Еще 1 инструммент от Blooomberg. На этот раз - инструмент для создания cli. Основные фичи: поддержка typescript, отсутствие депенденсей, умеет и в ESM и в commonjs, умеет в автокомплит из шела, умеет в код сплиттинг и инъекцию зависимостей

What in Zod's name?
Есть библиотека для валидации по схеме - Zod. Она достаточно популярна, но ошибки валидации от нее сложно воспринимать. Для упрощения разбора ошибок появился zod.fyi - вы вставляете в него текст ошибки, а он выдает вам человекопонятное описание, что же случилось. В целом, наверное, можно закидывать ошибку и в chatGPT.


ESLint now officially supports linting of JSON and Markdown
Eslint продолжает развиваться. На этот раз представили поддержку линтинга json и markdown.

С одной стороны, линтить JSON и markdown не очень то интересно. С другой стороны есть 2 плюса: 1) можно использовать 1 инструмент для линтинга не только кода, но и json и доки на markdown; 2) сделали полноценную поддержку других языков

Announcing VoidZero - Next Generation Toolchain for JavaScript
Evan You (создатель vue, vite и кучи других инструментов) основал компанию, задача которой - создать тулчейн нового поколения для JS. Компания называется VoidZero. В целом, примерно те же цели что и у Rome, но доверия к Evan You намного больше - человек ультра продуктивен и делает действительно крутые инструменты.


——————————————

Спасибо что читаете, ставите реакции и отмечаетесь в комментариях. Если вы хотите помочь каналу - расскажите о нем своим коллегам или друзьям. Также оставляйте фидбек по формату, материалу и чему-угодно еще 🙂

Announcing VoidZero - Next Generation Toolchain for JavaScript

Evan You (создатель vue, vite и кучи других инструментов) основал компанию, задача которой - создать тулчейн нового поколения для JS. Компания называется VoidZero. В целом, примерно те же цели что и у Rome, но доверия к Evan You намного больше - человек ультра продуктивен и делает действительно крутые инструменты.

Что уже было разработано командой Evan You
- Vite, который стал уже основным сборщиком для многих мета-фреймворков
- Самый быстрый JavaScript парсер oxc-parser, в 3 раза быстрее чем SWC
- Самый быстрый Node.js резолвер зависимостей oxc-resolver, в 28x раз быстрее чем enhanced-resolve
- Самый быстрый TS/JSX трансформер oxc-transform, в 4 раза быстрее чем SWC. Не видел его, кстати, в бенчмарке от Блумберга, где они сравнивали свой ts-blank-page
- Самый быстрый линтер oxlint, в 50–100 раз быстрее чем ESLint
- Самый фичастый (в оригинале the most feature-complete) тест-раннер для веб приложений - vitest
- Самый быстрый бандлер Rolldown. Быстрее чем esbuild и другие бандлеры, написанные на Rust

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

https://voidzero.dev/posts/announcing-voidzero-inc

#development #javascript #EvanYou

ESLint now officially supports linting of JSON and Markdown

Eslint продолжает развиваться. На этот раз представили поддержку линтинга json и markdown.

С одной стороны, линтить JSON и markdown не очень то интересно. С другой стороны есть 2 плюса: 1) можно использовать 1 инструмент для линтинга не только кода, но и json и доки на markdown; 2) сделали полноценную поддержку других языков

Получается, теперь можно писать плагины на eslint для линтинга других языков. Это позволит сообществу сделать плагины для линтинга css, html, всяких svelte и прочих форматов прямо внутри eslint. Что звучит круто

Подключение новых плагинов выглядит вот так

import json from "@eslint/json";

export default [
    {
        plugins: {
            json,
        },
    },

    // lint JSON files
    {
        files: ["**/*.json"],
        language: "json/json",
        rules: {
            "json/no-duplicate-keys": "error",
        },
    },
];

https://eslint.org/blog/2024/10/eslint-json-markdown-support/

#development #javascript #eslint #markdown #JSON

What in Zod's name?

Есть библиотека для валидации по схеме - Zod. Она достаточно популярна, но ошибки валидации от нее сложно воспринимать. Для упрощения разбора ошибок появился zod.fyi - вы вставляете в него текст ошибки, а он выдает вам человекопонятное описание, что же случилось. В целом, наверное, можно закидывать ошибку и в chatGPT.

https://zod.fyi/

#development #javascript #zod #validation

stricli

Еще 1 инструммент от Blooomberg. На этот раз - инструмент для создания cli. Основные фичи: поддержка typescript, отсутствие депенденсей, умеет и в ESM и в commonjs, умеет в автокомплит из шела, умеет в код сплиттинг и инъекцию зависимостей

https://bloomberg.github.io/stricli/

#development #javascript #typescript #bloomberg #cli

ts-blank-space

Bloomberg заопенсорсили свой компилятор TS в JS. Это, конечно, сложно назвать компилятором - он очень быстро удаляет весь синтаксис TS и оставляет только нативный синтаксис JS.

Сам инструмент максимально простой: парсит AST, находит токены, связанные с TS и заменяет их на пробелы (поэтому blank-space в названии).

Зачем это вообще нужно.

Во первых, тул не проводит никакой тайп-чек, да и сам алгоритм простой, что делает его очень быстрым.

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

Оригинальный код

class Cat<T> {
  public whiskers: number;
  public tail: T;

  constructor(count: number, tail: T) {
    this.whiskers = count;
    this.tail = tail;
  }
}

throw Error();

Код, скомпилированный TS в esnext

class Cat {
    whiskers;
    tail;
    constructor(count, tail) {
        this.whiskers = count;
        this.tail = tail;
    }
}
throw Error();

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

ts-blank-space компилирует код в такой вариант

class Cat    {
         whiskers        ;
         tail   ;

  constructor(count        , tail   ) {
    this.whiskers = count;
    this.tail = tail;
  }
}

throw Error();

Как видите, вся специфика TS была заменена на пробелы, все значимые токены остались на своих местах. Это позволяет упростить дебаг: stacktrace ошибок всегда указывает на ту же строчку и колонку, на которой стоит конструкция в оригинальном коде; также упрощается сбор сорс-мапов. Если код меняется, то сорсмапы, грубо говорят, содержат мапинг вида "вот была строчка 10 колонка 11, теперь она строчка 7, колона 8". С использованием ts-blank-space сорсмапы описываются 1 строчкой //# sourceURL=cat.ts

Простота инструмента позволяет ему быть быстрым: по бенчмаркам блумберга, если не учитывать работу с AST для сорс-мапов, то ts-blank-space уступает лишь esbuild и @swc/core. Если же учитывать мапинг сорс-мапов, то ts-blank-space является самым быстрым тулом

Простота инструмента также и ограничивает его. Поддерживается на весь синтаксис TS:
- не поддерживаются неймспейсы (declare namespace поддерживается)
- не поддерживается специфика commonJS
- енамы (declare enum поддерживается)
- Свойства класса, объявляемые в конструкторе constructor(public prop) {}

В общем, интересный тул. Для каких-то простых проектов можно спокойно использовать.

https://bloomberg.github.io/ts-blank-space/

#development #javascript #typescript #bloomberg #compiler

Сегодня и завтра я на Frontendconf 2024. Завтра буду рассказывать свой доклад "релизим без стресса" про то, как применять лучшие инженерные практики и быть уверенными, что релиз пойдёт гладко.

Если вы на frontendconf 2024, приходите слушать.
Если вы не на конференции - новости пойдут в канал либо с пятницы, либо со следующей недели.

А ещё скоро появится публичная ссылка моего выступления с codefest про парное программирование, также скину в канал.

Дайджест за 2024-09-16 - 2024-09-20


——————————————————

Сейчас я активно готовлюсь к выступлению на FrontendConf. Поэтому могут быть задержки в публикации ссылок (пока некогда читать). В частности, сегодня будет только дайджест :С

——————————————————

How I Created a 3.78MB Docker Image for a JavaScript Service
Чем бы ты не занимался, всегда найдется азиат, который сделает это круче.

Так произошло и с докер-образами для JS-сервисов. Чела не устраивало, что все текущие образы весят 50+ МБ, вне зависимости от рантайма, и тогда он сделал свой докер-образ, который весит 3.7МБ.

Exploring Goja: A Golang JavaScript Runtime
Вот было у вас такое, что вы пишете на golang, и вам не хватает простого человеческого javascript? Теперь ваша боль решена - Goja - js рантайм для Golang

Если без шуток, челу необходимо было запускать JS в рамках Golang приложения. Конкретного кейса автора я не понял, но в целом могу выдумать несколько интересных: запуск JS-кода в контролируемом рантайме (для спортивного программирования например), описание сложных правил в UI на JS, а исполнение правил - на сервере на golang.

⭐️How to Use React Compiler – A Complete Guide
Огромная статья, рассказывающая про то, как работает React Compiler. Статья рассказывает, из чего состоит React Compiler как внутри себя, так и через какие инструменты он подключается в проект.

Также в статье показывается на простом кейсе, как React compiler упрощает работу разработчика на практике.

Multithreading in Node.js: Using Atomics for Safe Shared Memory Operations
Статья про многопоточность в nodejs и про atomics API.

Основная проблема мульти-поточности, это race-conditions.

Mutation-testing our JavaScript SDKs
Статья от Sentry, про применение мутационного тестирования в Sentry. Если коротко, мутационное тестирование - это когда инструмент меняет немного ваш код (создает мутанта) и ожидает, что тесты отловят это изменение. Мутанты при этом создаются тысячами, поэтому этот процесс весьма ресурсо-затратен. Однако и результаты всегда однозначны - если мутант выжил, значит вы что-то не протестировали. По сути мутационное тестирование оценивает качество ваших тестов, а не вашего кода. Есть и минусы - не всегда мы хотим писать столько тестов, сколько нужно для набора 100% скора (например, как часто вы в своих тестах проверяете, что вам реально в catch прилетел instanceof Error, а не какой-то кастомный клас?)

Статья рассказывает, как в Sentry решили начать запускать мутационные тесты и следить за скорингом, пытаясь его улучшать и отключая "ненужные" алгоритмы мутации кода. В целом статья не дает каких-то конкретных выводов по этой практике, но рассказывает как настроить и запустить мутационные тесты в своем JS-проекте.

——————————————

Спасибо что читаете, ставите реакции и отмечаетесь в комментариях. Если вы хотите помочь каналу - расскажите о нем своим коллегам или друзьям. Также оставляйте фидбек по формату, материалу и чему-угодно еще 🙂

Mutation-testing our JavaScript SDKs

Статья от Sentry, про применение мутационного тестирования в Sentry. Если коротко, мутационное тестирование - это когда инструмент меняет немного ваш код (создает мутанта) и ожидает, что тесты отловят это изменение. Мутанты при этом создаются тысячами, поэтому этот процесс весьма ресурсо-затратен. Однако и результаты всегда однозначны - если мутант выжил, значит вы что-то не протестировали. По сути мутационное тестирование оценивает качество ваших тестов, а не вашего кода. Есть и минусы - не всегда мы хотим писать столько тестов, сколько нужно для набора 100% скора (например, как часто вы в своих тестах проверяете, что вам реально в catch прилетел instanceof Error, а не какой-то кастомный клас?)

Статья рассказывает, как в Sentry решили начать запускать мутационные тесты и следить за скорингом, пытаясь его улучшать и отключая "ненужные" алгоритмы мутации кода. В целом статья не дает каких-то конкретных выводов по этой практике, но рассказывает как настроить и запустить мутационные тесты в своем JS-проекте.

Ожидаем продолжения, где ребята поделятся результатами трекинга скора мутационного тестирования.

https://sentry.engineering/blog/js-mutation-testing-our-sdks

#development #javascript #testing #mutationTesting #sentry

Multithreading in Node.js: Using Atomics for Safe Shared Memory Operations

Статья про многопоточность в nodejs и про atomics API.

Основная проблема мульти-поточности, это race-conditions.

Для визуализации проблемы можно взять следующий пример. У нас есть приложение, которое запускает 2 воркера и передает им одни и те же данные

Код приложения и воркера

import { Worker, isMainThread, workerData, threadId } from 'node:worker_threads';

// код приложика
if (isMainThread) { 
  const buffer = new SharedArrayBuffer(1);
  new Worker(import.meta.filename, { workerData: buffer });
  new Worker(import.meta.filename, { workerData: buffer });
} else {
// код воркера
  const typedArray = new Int8Array(workerData);
  typedArray[0] = threadId;
  console.dir({ threadId, value: typedArray[0] });
}

Воркеры пишут id своего треда в общие данные и делают console.log этих общих данных. Т.к. код синхронный, то в целом у меня, как у обычного человека, редко пишущего многопоточные приложики, есть ожидание что в console.log всегда будет выводится id текущего треда

Однако практика показывает, что это не так

# 1 type of results
{ threadId: 1, value: 2 }
{ threadId: 2: value: 2 }

# 2 type of results
{ threadId: 1, value: 1 }
{ threadId: 2: value: 1 }

# 3 type of results
{ threadId: 1, value: 1 }
{ threadId: 2: value: 2 }

ОС может передать процессорное время в другой тред после того, как тред записал данные в массив, но до того, как тред вывел свои данные в консоль

Проблема стара как мир и я помню, как мы в универе на изучении C++ изучали всякие схемы для эксклюзивного доступа к памяти (семафоры, мьютексы).

В JS для эксклюзивного и безопасного доступа к шареной памяти используется atomics. В данном кейсе автор разбирает использование store и load для блокирующего доступа к памяти, что не до конца решается кейс, но уже делает лучше.

const typedArray = new Int8Array(workerData);
Atomics.store(typedArray, 0, threadId);
const value = Atomics.load(typedArray, 0);
console.dir({ threadId, value });

Более сложные решения автор опишет в будущих статьях. Штош, ждем в будущих дайджестах

https://pavel-romanov.com/multithreading-in-nodejs-using-atomics-for-safe-shared-memory-operations

#development #javascript #nodejs #multiThreading #atomics

How to Use React Compiler – A Complete Guide

Огромная статья, рассказывающая про то, как работает React Compiler. Статья рассказывает, из чего состоит React Compiler как внутри себя, так и через какие инструменты он подключается в проект.

Также в статье показывается на простом кейсе, как React compiler упрощает работу разработчика на практике.

Статья не очень глубока с технической точки зрения, но очень хорошо верхнеуровнево объясняет, что такое этот React Compiler и как он работает с практической точки зрения - объясняется, что происходит с кодом, который я пишу, и что мне необходимо было бы сделать самому для достижения того же результата

https://www.freecodecamp.org/news/react-compiler-complete-guide-react-19/

#development #javascript #react #reactCompiler #recommended

Exploring Goja: A Golang JavaScript Runtime

Вот было у вас такое, что вы пишете на golang, и вам не хватает простого человеческого javascript? Теперь ваша боль решена - Goja - js рантайм для Golang

Если без шуток, челу необходимо было запускать JS в рамках Golang приложения. Конкретного кейса автора я не понял, но в целом могу выдумать несколько интересных: запуск JS-кода в контролируемом рантайме (для спортивного программирования например), описание сложных правил в UI на JS, а исполнение правил - на сервере на golang.

Автор смотрел в сторону разных вариантов запуска JS в рамках Golang, но остановился на Goja. Основное преимущество Goja - это бесшовная связка структур в Golang со структурами JS.

В целом, если у вас на сервере крутится golang и вам надоело дублировать какую-то логику в нескольких местах, можете предложить в команде использовать Goja, чтобы реализовывать общую логику на JS и использовать ее в golang. Ну или у вас могут быть еще какие-то кейсы для использования такой библиотеки

На последок, закину сниппет кода, который использует Goja

package main

import (
 "fmt"

 "github.com/dop251/goja"
)

func main() {
 vm := goja.New()

 // Passing an array of integers from 1 to 100
 values := []int{}
 for i := 1; i <= 100; i++ {
  values = append(values, i)
 }

 // Define the JavaScript code to filter even values
 script := `
  values.filter((x) => {
   return x % 2 === 0;
  })
  `

 // Set the array in the JavaScript runtime
 vm.Set("values", values)

 // Run the script
 result, err := vm.RunString(script)
 if err != nil {
  panic(err)
 }

 // Convert the result back to a Go slice of empty interfaces
 filteredValues := result.Export().([]interface{})

 fmt.Println(filteredValues)
 // Outputs: [2 4 6 8 10 12 14 16 18 20 22 24 26 28 30 32 34 36 38 40 42 44 46 48 50 52 54 56 58 60 62 64 66 68 70 72 74 76 78 80 82 84 86 88 90 92 94 96 98 100]

 first := filteredValues[0].(int64)
 fmt.Println(first)
}

https://jtarchie.com/posts/2024-08-30-exploring-goja-a-golang-javascript-runtime

#development #javascript #runtime

How I Created a 3.78MB Docker Image for a JavaScript Service

Чем бы ты не занимался, всегда найдется азиат, который сделает это круче.

Так произошло и с докер-образами для JS-сервисов. Чела не устраивало, что все текущие образы весят 50+ МБ, вне зависимости от рантайма, и тогда он сделал свой докер-образ, который весит 3.7МБ.

Чтобы сделать такой худой образ, автор использует LLRT как рантайм. Это рантайм, который развивает AWS, если я правильно помню. Создан поверх движка QuickJS.

Т.к. llrt весит так мало не просто так (а потому что многое там упрощено и многого там просто нет), то пришлось немножко адаптировать свое приложение. Например, переписать часть, связанную с http сервером.

Итоги:
- Докер образ стал весить меньше
- Приложение быстрее стартует
- Приложение медленее работает
- Автор в целом рекомендует оставаться на nodejs для большинства кейсов.

https://shenzilong.cn/record/How%20I%20Created%20a%203.78MB%20Docker%20Image%20for%20a%20JavaScript%20Service

#development #javascript #docker

Дайджест за 2024-09-09 - 2024-09-13

⭐️Особенности Effector, которые почему-то никто не обсуждает: опыт ВКонтакте спустя год использования
На Codefest команда ВК рассказывала, как они решили перейти на effector и почему пришлось откатываться. Мне лично доклад сильно понравился, потому что он, по своему смыслу, двух-уровневый: на первом уровне - критика effector, на втором уровне - как выбирать инструменты (отдельно кекнул прям на докладе, что решили выбирать стейт менеджер на основе голосования)

Записи докладов с Codefest еще не обнародовали, но команда VK выпустила статью на ту же тему. Статья уже стала источником небольшой драмы в сообществе (например, можно почитать кучу постов у sergeysova и немножко у artalog).

An SSR Performance Showdown
Немного странный бенчмарк производительности серверного рендеринга разных библиотек. Задача простая: отрисовать спираль из 2398 дивов. В сравнении участвовали fastify-html (простая либка для рендера html из fastify), react, preact, vue, solidjs, svelte.

В явных лидерах (>1000 RPS): fastify-html и vue, далее с небольшим отставанием (>900 RPS) идут svelte и solidjs, завершают рейтинг preact (717 RPS) и react (572 RPS).

В комментах отписаличь, почему бенчмарк - фигня

Announcing Vue 3.5
Анонсирован Vue 3.5. Давно не следил за vue, хотя продолжительно время писал на нём. И вот решил посмотреть что там нового в vue 3.5.

Я, конечно, давно уже не слежу за тем, насколько Vue быстрее или медленнее других библиотек и фреймворков. Но в моей памяти - он считается достаточно быстрым (поправьте в коментах, если это уже давно не так). Тем не менее, в 3.5 уменьшили в 2 раза потребление памяти системой реактивности, а трекинг огромных вложенных массивов ускорился в 10 раз в определенных кейсах

В комментах разные уточнения к посту и перформансу

OpenAI is shockingly good at unminifying code
Небольшая статья, показывающая интересный юзкейс для нейронок. Чувак увидел прикольную ASCII-анимацию на сайте, и захотел узнать как она работает. Как это часто бывает на сайтах - из исходников есть только минифицированный код на React в сорсах страницы.

Его можно было бы и реверснуть ручками (там небольшой фрагмент кода), но чел воспользовался мощью chatGPT, который правильно разобрал алгоритм и затем почти правильно написал читаемую имплементацию на typescript.

Inside ECMAScript: JavaScript Standard Gets an Extra Stage
Комитет стандартизации Ecmascript добавил еще 1 Stage для предложений по улучшению языка. Между 2 и 3 этапом добавился stage 2.7.

Почему он понадобился: часто большие предложения, попадавшие на Stage 3, разворачивались обратно на Stage 2 т.к. оказывалось, что у предложения есть существенные недостатки, которые не были выявлены ранее. Это означает, что вся работа, сделанная в stage 3, была сделана зря. Чтобы минимизировать подобные кейсы, решили добавить шаг 2.7, в котором уже договорились о том, как все должно работать, но теперь пишут тест-кейсы и валидируют, что это предложение действительно рабочее (если я правильно понял).

——————————————

Также короткий пост о том как я посетил конфу в Томске

——————————————

Спасибо что читаете, ставите реакции и отмечаетесь в комментариях. Если вы хотите помочь каналу - расскажите о нем своим коллегам или друзьям. Также оставляйте фидбек по формату, материалу и чему-угодно еще 🙂

Обычно я не рассказываю как прошла очередная конфа, но про город ИТ не могу не поделиться.
В прошлом году фронтенд трек проходил в ночном клубе и это было супер-атмосферно: томный свет, на заднем фоне был, есть танцпол, липкий пол, кожаные диваны. В этом году площадку взяли ровно противоположную - филармонию. Я уж думал буду как ферзь выступать на крутой сцене. Но все оказалось ещё круче - утренний фронтенд трек проходил в шатре на улице (а сентябрь в Томске не прям тёплый, утра холодно было). Рассказал доклад про парное программирование, вроде людям зашло) позадавали вопросов и рассказали своих кейсов. На стенде сибура выиграл мемного кота.

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