Дайджест за 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, в котором уже договорились о том, как все должно работать, но теперь пишут тест-кейсы и валидируют, что это предложение действительно рабочее (если я правильно понял).

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

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

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

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

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

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 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

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

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

Дайджест за 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-проекте.

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

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

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

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

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

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

stricli

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

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

#development #javascript #typescript #bloomberg #cli

What in Zod's name?

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

https://zod.fyi/

#development #javascript #zod #validation

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

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