Standard Schema - A common interface for TypeScript validation libraries

Внезапно (для меня по крайней мере), но авторы популярных пакетов для валидаций собрались и стандартизировали схемы для валидации данных в TS. На сайте описывается состав спеки и библиотеки и фреймворки, которые уже её поддерживают.

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

https://standardschema.dev

#development #javascript #typescript #schema

Миграция на строгий TypeScript: наш путь и собственное решение

Статья от Selectel про миграцию на строгий TS. Проблема, рассматриваемая в статье, стара как строгий режим TS: проект писался изначально не на TS, решено было его перевозить на TS на нестрогий режим т.к. ни у кого нет столько времени, чтобы переписать весь проект на строгие типы

В идеале хотелось бы, чтобы часть файлов (новый код и тот код, который уже был написан в строгом режиме) всегда проверялись в строгом режиме, а старый код проверялись в нестрогом режиме. В IDE это решается просто - TS поддерживает иерархию tsconfig в проекте, что позволяет вручную размечать, какой файл как следует проверять. Однако для CI такого простого решения нет

Одно из рассматриваемых решений - подключить плагин для TS. В сообществе есть 2 таких решения и оба в selectel не понравились: нужны кастомные настройки tsconfig и встраивание в сборку

Поэтому команда Selectel решила написать ~~свой велосипед~~ свое решение этой проблемы. Так на свет появилась библиотека @selectel/ts-check. Она умеет запускаться из кли и, если я правильно понял, повторяет логику того, как работает проверка в IDE. Также ребята сразу сделали поддержку code quality report в gitlab, поэтому ошибки @selectel/ts-check отображаются сразу в МР.

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

https://habr.com/ru/companies/selectel/articles/879980/

#development #javascript #typescript #strictMode #habr

Обзор на книгу "Рискуя собственной шкурой" от Насима Талеба

Насим Талеб - человек, давший миру очень популярные книги "Черный лебедь" и "Антихрупкость". Я их не читал, но мне рекомендовали прочесть "Рискуя собственной шкруой", что я и проделал на новогодних каникулах.

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

Есть несколько основных идей в книге
- Для взвешенных решений необходимо "ставить шкуру на кон", т.е. рисковать чем-то. Тот, кто не рискует, не может принимать хороших решений.
- Диктатура меньшинства. Если есть какое-то непримиримое меньшинство (3-4% от общества), которое равномерно распределено по обществу, которое хочет протолкнуть какое-то решение, а большинство готово подстроится - то решение меньшинства будет принято
- Эффект Линди: Чем дольше что-то существует, тем дольше оно будет существовать дальше.

Это общие идеи, которые можно применить к очень многим аспектам жизни общества.

Например, можно рассмотреть эти идеи с точки зрения нашей любимой айтишечки

Те, кто не "ставит шкуру на кон", не могут принимать взвешенных решений. Если человек что-то предлагает, но при этом он сам ничем не рискует, а рискует кто-то другой, то мы не можем полагаться на то, что человек предлагает хорошее решение. Наверняка вы на работе сталкивались с "экспертами" из других команд или отделов, которые не являются частью вашей команды, но дают вам советы про то, как надо работать. Иногда эти советы по делу, иногда нет. Но есть общая закономерность - люди, дающие советы из других команд и отделов ничем не рискуют, а вот вы, применяя эти советы, рискуете. Поэтому решение о применение совета должно быть у вас, а не у внешних экспертов. Иначе эксперты могут принимать решения, за которые будете расплачиваться вы. Типичный пример в IT - спускаемые "сверху" стандарты процессов или изменения.

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

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

Диктатура меньшинства устанавливается только тогда, когда большинство готово подстроиться. Если среди большинства есть непримеримые к изменениям меньшинства люди, то меньшинство не сможет внедрить это изменение. Скажем, вряд ли у вас в команде получится внедрить правило минимум 4-х апрувов на код ревью - кто-то точно будет против (ну, я надеюсь на это)

Эффект Линди следует следующей логике: если что-то смогло прожить 100 дней, значит оно достаточно живучее, чтобы прожить еще 100 дней. Если что-то прожило 1000 дней, значит оно достаточно живучее, чтобы прожить еще 1000 дней. В общем, можно сказать с большой уверенностью, что React проживет еще 11 лет :)

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

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



#note #book

Дайджест за 2025-02-10 - 2025-02-14

Docxtemplater
Docxtemplater - библиотека на JS, которая позволяет генерировать docx, pptx, xlsx документы на основе шаблонов.

Выглядит интересно, особенно если вам достаточно на коленке генерировать документы по шаблону. Из минусов: базовая версия библиотеки бесплатная, а вот все дополнительные плюшки (например, вставка HTML) - платная.

The modern way to write JavaScript servers
Достаточно интересная статья, которая показывает возможности для упрощения в кодовой базе и в DX при прямом использовании Request и Response вместо node:http

node:http - механизм для поднятия веб-сервера на ноде и он достаточно хорошо работает. Многие фреймворки очень сильно завязаны на node:http не только на уровне, где должна быть связь с сетью, но и внутри бизнес-логики. Вместо этого автор предлагает использовать стандартизированные в Web Request и Response

Standard Schema - A common interface for TypeScript validation libraries
Внезапно (для меня по крайней мере), но авторы популярных пакетов для валидаций собрались и стандартизировали схемы для валидации данных в TS. На сайте описывается состав спеки и библиотеки и фреймворки, которые уже её поддерживают.

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

Миграция на строгий TypeScript: наш путь и собственное решение
Статья от Selectel про миграцию на строгий TS. Проблема, рассматриваемая в статье, стара как строгий режим TS: проект писался изначально не на TS, решено было его перевозить на TS на нестрогий режим т.к. ни у кого нет столько времени, чтобы переписать весь проект на строгие типы

В идеале хотелось бы, чтобы часть файлов (новый код и тот код, который уже был написан в строгом режиме) всегда проверялись в строгом режиме, а старый код проверялись в нестрогом режиме. В IDE это решается просто - TS поддерживает иерархию tsconfig в проекте, что позволяет вручную размечать, какой файл как следует проверять. Однако для CI такого простого решения нет

Обзор на книгу "Рискуя собственной шкурой" от Насима Талеба
Насим Талеб - человек, давший миру очень популярные книги "Черный лебедь" и "Антихрупкость". Я их не читал, но мне рекомендовали прочесть "Рискуя собственной шкруой", что я и проделал на новогодних каникулах.

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

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

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

Обзор на книгу "Чистый дизайн. Практика эмпирического проектирования ПО" от Кента Бек

Кент Бек - автор XP и TDD, один из создателей Agile Manifesto, снова ворвался в публицистику и выпустил новую короткую книгу. Книга короткая и, по ощущениям, состоит из кучи собранных вместе блог-постов.

Книга в целом о том, как делать "очистку" - это новый термин, проще описать его как "простой рефакторинг". Разница между очисткой и рефакторингом как между прибрать пыль и сделать генеральную уборку. Книга поделена на 3 части: список простых очисток, как проводить очистку, когда проводить очистку

Первая часть супер простая и очень похожа на чистый код: описывается плохой паттерн, его проблемы, и как провести небольшой рефакторинг, улучшающий код. Каждая глава буквально 2-4 страницы.

Вторая часть и третья части уже намного интереснее.

В частности, в книге есть интересная идея, что изменения можно поделить на структурные (рефакторинги, которые ничего не меняют в поведении системы) и изменения поведения. К ним нужно по-разному относиться и их следует отделять друг от друга.

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

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

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

Простое (на мой взгляд) определение связности и зацепления из книги:
> Отдельный фрагмент кода понять легче, если он представляет единое целое и имеет единый смысл ... Это связность. Кроме того, понять происходящее в контексте отношений с другими частями кода проще, если эти отношения немногочисленны, относительно слабы или сильно ограничены. Это сцепление. Сцепление и связность ... означают ... то, как ваш мозг воспринимает сложные системы.

Книга очень короткая. Я прочел буквально за 3 вечера. Сам формат мне понравился - вместо того, чтобы читать талмуд на 400+ страниц про все подряд, есть супер короткая книга, которая покрывает небольшую тему, раскрывает её с разных сторон (хотя в этой книге некоторые идеи раскрыты не очень глубоко), и эту тему можно впитать в себя буквально за рабочую неделю.

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



#note #book

Introducing Fusion - write PHP inside Vue and React components

Мы достигли технологической сингулярности: теперь можно писать php внутри vue или react внутри php! Создатель Laravel (фреймворк для php) сделал инструмент, который позволяет в Laravel писать vue и react файлы, внутри которых будет использоваться php.

Это не просто рендер vue-шаблонов с использованием php, это и вызов php-методов из браузерного кода, и синхронизация стейта на вебе и на беке. ИМХО, неплохая тема, особенно веб-для разработчиков на проекте с laravel.

Сниппет кода на странице с примером включает только отображение:

<!-- app.vue -->
<php>
    $user = prop(Auth::user()->email);
</php>
 
<template>
    <div>{{ user }}</div>
</template>

https://laravel-news.com/introducing-fusion

#development #javascript #php #vue

Tutorial: publishing ESM-based npm packages with TypeScript

Туториал по публикации ESM-пакетов с поддержкой TS, которые работают и в браузере и в ноде. Туториал разбирает все - от структуры файлов и конфигов, до настройки тулов. Есть, конечно, небольшой минус - гайд немного предвзят по некоторым моментам

Основной полезный контент - это настройка ESM-модулей, которая делается теперь проще, благодаря поддержке ESM различным тулингом, через объявление поля exports в package.json, вместо описания 4-х разных полей ранее.

Настройка экспорта зависит от ответов на несколько вопросов:
- Собираемся ли мы экспортировать все через под-директории (import someThing from "package-name/sub/index") или из рута (import someThing from "package-name")
- Собираемся ли мы указывать расширение для файлов для экспортов под-директорий?

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

Автор туториала не говорит о том, как лучше, но для себя он вывел следующие правила:
- Большинство его пакетов не имеют под-дпиректорий
- Если пакет - это коллекция модулей, то они экспортируются с расширением
- Если пакет - это вариация нескольких версий пакета (синхронное и асинхронное АПИ например), то они экспортируются без расширения

// Bare export
".": "./dist/src/main.js",

// Subpaths with extensions
"./util/errors.js": "./dist/src/util/errors.js", // single file
"./util/*": "./dist/src/util/*", // subtree

// Extensionless subpaths
"./util/errors": "./dist/src/util/errors.js", // single file
"./util/*": "./dist/src/util/*.js", // subtree

Также в статье настраивается:
- mocha
- tsc
- typedoc
- publint
- knip
- madge
- и куча других тулов

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

https://2ality.com/2025/02/typescript-esm-packages.html

#development #typescript #npm

Read-only accessibility in TypeScript

Пост, разбирающий все аспекты создания readonly свойств и объектов в TS: от свойств объекта, до readonly Set и Map.

Я знал про readonly (и даже иногда использовал), но я не знал что в TS есть Readonly вариации массива, tuple, Set и Map. В статье показывается как они работают и какие есть особенности их работы.

Для меня самым шоком оказалось, что объект Readonly объект можно кинуть аргументом в функцию, которая принимает не Readonly объект, а значит может его поменять. При этом для массива, Set и других Readonly типов все работает корректно - я не могу кинуть Readonly версию типа в функцию, которая ожидает не-readonly версию.

https://2ality.com/2025/02/typescript-readonly.html

#development #typescript #readonly

Beej's Guide to Git

Огромный гайд по git'у. Кажется в этом гайде покрыто вообще все, при этом все описано достаточно компактно и разобраны основные кейсы работы с git'ом, которые нужные разработчику.

Читать я бы такое не стал, но ссылку бы сохранил, чтобы открывать периодически интересующие темы. Для джунов вообще хорошо. В первый раз столкнулся с тем что надо сделать форк? Сначала прочти в туториале про форки и работу с ремоутами, а потом приступай к работе.

https://beej.us/guide/bggit/html/split/

#development #git #tutorial

Дайджест за 2025-02-17 - 2025-02-21

Обзор на книгу "Чистый дизайн. Практика эмпирического проектирования ПО" от Кента Бек
Кент Бек - автор XP и TDD, один из создателей Agile Manifesto, снова ворвался в публицистику и выпустил новую короткую книгу. Книга короткая и, по ощущениям, состоит из кучи собранных вместе блог-постов.

Книга в целом о том, как делать "очистку" - это новый термин, проще описать его как "простой рефакторинг". Разница между очисткой и рефакторингом как между прибрать пыль и сделать генеральную уборку. Книга поделена на 3 части: список простых очисток, как проводить очистку, когда проводить очистку

Introducing Fusion - write PHP inside Vue and React components
Мы достигли технологической сингулярности: теперь можно писать php внутри vue или react внутри php! Чел из сообщества Laravel (фреймворк для php) сделал инструмент, который позволяет в Laravel писать vue и react файлы, внутри которых будет использоваться php.

Это не просто рендер vue-шаблонов с использованием php, это и вызов php-методов из браузерного кода, и синхронизация стейта на вебе и на беке. ИМХО, неплохая тема, особенно веб-для разработчиков на проекте с laravel.

Tutorial: publishing ESM-based npm packages with TypeScript
Туториал по публикации ESM-пакетов с поддержкой TS, которые работают и в браузере и в ноде. Туториал разбирает все - от структуры файлов и конфигов, до настройки тулов. Есть, конечно, небольшой минус - гайд немного предвзят по некоторым моментам

Основной полезный контент - это настройка ESM-модулей, которая делается теперь проще, благодаря поддержке ESM различным тулингом, через объявление поля exports в package.json, вместо описания 4-х разных полей ранее.

Read-only accessibility in TypeScript
Пост, разбирающий все аспекты создания readonly свойств и объектов в TS: от свойств объекта, до readonly Set и Map.

Я знал про readonly (и даже иногда использовал), но я не знал что в TS есть Readonly вариации массива, tuple, Set и Map. В статье показывается как они работают и какие есть особенности их работы.

Beej's Guide to Git
Огромный гайд по git'у. Кажется в этом гайде покрыто вообще все, при этом все описано достаточно компактно и разобраны основные кейсы работы с git'ом, которые нужные разработчику.

Читать я бы такое не стал, но ссылку бы сохранил, чтобы открывать периодически интересующие темы. Для джунов вообще хорошо. В первый раз столкнулся с тем что надо сделать форк? Сначала прочти в туториале про форки и работу с ремоутами, а потом приступай к работе.

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

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

Style-observer: JS to observe CSS property changes, for reals

В вебе относительно давно есть разные Observer'ы, с некоторыми из которых, кажется, столкнулся каждый - Mutation Observer и Intersection Observer. Но чего нам не хватает - это Style Observer. Статья от Lea verou про то, как сообщество решало задачу "реагировать на изменения в стилях" и как Lea Verou и другие неравнодушные люди сделали Style Observer

Первые решения этой задачи появились еще в 2018 году и было реализованы на полинге - JS код периодически запрашивал стили и реагировал на их изменения. Затем были сделаны решения, которые работали на основе селекторов и transitionstart. Затем в какой-то момент появился transition-behavior: allow-discrete, который позволяет делать более общие решения. На его основе и построен style-observer

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

https://lea.verou.me/blog/2025/style-observer/
https://observe.style

#development #css #leaVerou

Move on to ESM-only

Пора перестать делать пакеты с поддержкой CJS и работать только в ESM. Автор статьи 3 года назад писал гайд, как делать пакет с поддержкой ESM & CJS, но теперь считает, что сообщество и тулинг за эти 3 года ушли далеко вперед и от поддержки CJS можно отказываться.

Изначально весь движ к ESM-only пакетам делался снизу-вверх - некоторые библиотеки (типа execa) переехали на ESM-only и, таким образом, заставляли двигаться всю экосистему. Это достаточно крутой мув, но, по мнению автора, он оказался менее эффективен, чем поддержка ESM у тулинга и фреймворков.

Почему стоит переезжать на ESM-only и не стоит оставаться на CJS & ESM?
- Не смотря на то, что Nodejs позволяет импортировать CJS в ESM, экспорты CJS сделаны по-другому, из-за его возникает необходимость делать двойную работу. Автор не погружается глубоко в проблематику, но указывает, например, на необходимость генерировать 2 файла с типами
- Зависимости, которые поставляются как ESM и как CJS в код приложения, могут конфликтовать друг с другом. Также это большая проблема для пакетов-синглотонов
- Размер пакетов, которые поддерживают CJS & ESM, увеличиваются (т.к. им нужно держать 2 версии кода)

Где следует уже использовать ESM-only^
- Новые пакеты
- Пакеты, которые должны работать в браузере
- CLI
- Node.js пакеты, таргетирующиеся на новые версии ноды


https://antfu.me/posts/move-on-to-esm-only

#development #javascript #esmodules

The Popover API is now Baseline Newly available

Popover - это база. Теперь официально. Popover - это стандартизированное API для реализации всплывающих окон в браузере. Вообще Popover реализовали в Firefox еще в апреле 2024 года, но реализация оказалась проблемной для iOS и iPadOS - нельзя было закрыть Popover ~~без уважения~~ кликнув по свободному месту. Поэтому пришлось ждать свежего релиза сафари, чтобы сказать, что Popover - это база

Что это значит для нас: можно считать что Popover прекрасно работает с января 2025. Когда значительная часть пользователей перейдёт на браузеры с версией выше, чем выпущенные в январе 2025 года, можно будет использовать Popover по полной.

https://web.dev/blog/popover-baseline

#development #javascript #popover

How to refactor code with GitHub Copilot

Github развивают свой Copilot и выпускают хорошие статьи по работе с ним. В данном статье рассказывается, как Copilot может помочь в рефакторинге.

Статья делится на несколько частей: что такое рефакоринг => как его начать => как сделать мелкий рефакторинг => как набросать план рефакторинга

Рефакторинг - изменение кода без изменения поведения. По сути, изменение структуры кода. Самые популярные примеры: упрощение условий, вынесение общей логики, декомпозиция функций

Перед тем как начать рефакторинг, нужно убедиться, что мы изменениями не поменяем поведение. Но для этого это поведение необходимо понять. Хорошо, когда код хорошо написан и есть комментарии - в этом случае легко погрузиться в то, как работает код. Но бывает так, что понять поведение очень сложно. Тут то на помощь и может придти Copilot - он проанализирует код и расскажет, что он делает и почему

Дальше можно перейти к простым рефакторингам. В статье предлагается очень наивный подход - просто закинуть промпт "сделай красиво"

- How would you improve this?
- Improve the variable names in this function.
- #file:pageInit.js, #file:socketConnector.js Offer suggestions to simplify this code.

Но как стартовая точка - сойдет. Вместе с Copilot можно идти в более сложные рефакторинги, когда вы накидываете контекст, а Copilot предагает решения.

Все кто использовали Copilot и ChatGPT уже, скорее всего, пробовали подход "сделай красиво". Однако команда Copilot рекомендует идти дальше и составлять план рефакторинга вместе с Copilot. Эта фича есть в Copilot Workspace и она выглядит достаточно неплохо. В чем суть: вместо того, чтобы просить Copilot сделать код красивее, можно скормить ему контекст (что делаем, зачем, какие цели, какие файлы) и попросить составить план рефакторинга. Этот план можно затем полировать вместе с Copilot, а затем уже проводить рефакторинг по плану. В целом, похоже на обычный здоровый процесс рефакторинга - перед тем как делать что-то сложное, лучше обсудить с коллегой план.

Также в статье приводится реальный кейс рефакторинга вместе с Copilot из команды Github

https://github.blog/ai-and-ml/github-copilot/how-to-refactor-code-with-github-copilot/

#development #javascript #ai #copilot #refactor #github

We Replaced Our React Frontend with Go and WebAssembly

Чуваки из Dagger переписали React на Go. Внимание, не повторять в домашних условиях. Команда Dagger столкнулась со сложностью - у них был интерфейс в вебе и интерфейс в терминале и необходимо было все UI-фичи дублировать в двух разных кодовых базах (собственно React и Go). Решение простое: переписать один из двух UI на ~~typescript~~ Go.

Выбор достаточно храбный, но обоснованный. Команда имеет широкую экспертизу в Go и слабую в web-e, поэтому принято решение попробовать переехать полностью на Go. Статья рассказывает о проблемах, с которыми столкнулась команда и что из этого вышло.

Ребята взяли Go-App - это тулинг для написания PWA-приложиков на go, с применением WASM.

Какие нюансы вскрылись при написании Go приложения для веба:
- Нужно было очень аккуратно оптимизировать потребление памяти. В проекте есть кейсы, когда требуется отрисовывать более 200 тысяч строчек логов, что может привести к развалу приложения.
- Go WASM оказался неповоротливым в обработке огромных объемов JSON, из-за чего пришлось менять архитектуру решения.
- WASM файл получился большим - 32 МБ. Даже после сжатия brotli он остается 4.6 МБ
- Думали, что будет сложно писать UI-компоненты, но оказалось что это не так
- Научились использовать npm библиотеки из Go-кода
- По сравнению с React, прямая работа с UI позволяет лучше оптимизировать код. Можно сделать много разных решений, замерить и выбрать лучшее.
- Дебаг средствами Go - удобен
- За бесплатно получили PWA приложение (в целом, могли и раньше воткнуть конечно)

Следует ли вам проделывать такое? Скорее всего нет. У Dagger специфичный юзкейс:
- Делают непростой UI. Далеко не каждому продукту нужно выводить сотни тысяч элементов на странице
- Команда из сильных go-разработчиков
- Требование синхронизации двух интерфейсов

Я же отмечу, что Go-разработчики не перестают меня удивлять путями, которые они выбирают. Кейс же очень интересный.

https://dagger.io/blog/replaced-react-with-go

#development #javascript #golang #wasm

Дайджест за 2025-02-24 - 2025-02-28

Style-observer: JS to observe CSS property changes, for reals
В вебе относительно давно есть разные Observer'ы, с некоторыми из которых, кажется, столкнулся каждый - Mutation Observer и Intersection Observer. Но чего нам не хватает - это Style Observer. Статья от Lea verou про то, как сообщество решало задачу "реагировать на изменения в стилях" и как Lea Verou и другие неравнодушные люди сделали Style Observer

Первые решения этой задачи появились еще в 2018 году и было реализованы на полинге - JS код периодически запрашивал стили и реагировал на их изменения. Затем были сделаны решения, которые работали на основе селекторов и transitionstart. Затем в какой-то момент появился transition-behavior: allow-discrete, который позволяет делать более общие решения. На его основе и построен style-observer

Move on to ESM-only
Пора перестать делать пакеты с поддержкой CJS и работать только в ESM. Автор статьи 3 года назад писал гайд, как делать пакет с поддержкой ESM & CJS, но теперь считает, что сообщество и тулинг за эти 3 года ушли далеко вперед и от поддержки CJS можно отказываться.

Изначально весь движ к ESM-only пакетам делался снизу-вверх - некоторые библиотеки (типа execa) переехали на ESM-only и, таким образом, заставляли двигаться всю экосистему. Это достаточно крутой мув, но, по мнению автора, он оказался менее эффективен, чем поддержка ESM у тулинга и фреймворков.

The Popover API is now Baseline Newly available
Popover - это база. Теперь официально. Popover - это стандартизированное API для реализации всплывающих окон в браузере. Вообще Popover реализовали в Firefox еще в апреле 2024 года, но реализация оказалась проблемной для iOS и iPadOS - нельзя было закрыть Popover без уважения кликнув по свободному месту. Поэтому пришлось ждать свежего релиза сафари, чтобы сказать, что Popover - это база

Что это значит для нас: можно считать что Popover прекрасно работает с января 2025. Когда значительная часть пользователей перейдёт на браузеры с версией выше, чем выпущенные в январе 2025 года, можно будет использовать Popover по полной.

How to refactor code with GitHub Copilot
Github развивают свой Copilot и выпускают хорошие статьи по работе с ним. В данном статье рассказывается, как Copilot может помочь в рефакторинге.

Статья делится на несколько частей: что такое рефакоринг => как его начать => как сделать мелкий рефакторинг => как набросать план рефакторинга

We Replaced Our React Frontend with Go and WebAssembly
Чуваки из Dagger переписали React на Go. Внимание, не повторять в домашних условиях. Команда Dagger столкнулась со сложностью - у них был интерфейс в вебе и интерфейс в терминале и необходимо было все UI-фичи дублировать в двух разных кодовых базах (собственно React и Go). Решение простое: переписать один из двух UI на typescript Go.

Выбор достаточно храбный, но обоснованный. Команда имеет широкую экспертизу в Go и слабую в web-e, поэтому принято решение попробовать переехать полностью на Go. Статья рассказывает о проблемах, с которыми столкнулась команда и что из этого вышло.

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

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

Introducing RushDB: Zero-Config Instant Database for Modern Apps & AI Era

Ссылка от подписчика про разрабатываемый им продукт - RushDB. RushDB - это база данных, которую легко развернуть и начать использовать. Основная фишка - это то что БД забирает на себя организацию данных - нормализацию, лейблинг, организацию связей между сущностями. И это очень подходит для AI-решений - вы закидываете данные, БД сама все структурирует, а структуру и связи уже может использовать AI

Также все сделано для того, чтобы работа с БД была простой: есть SDK на typescript и python, можно селф-хостить, можно хостить в клауде, есть гарантии транзакций, возможность работать ничего не настраивая.

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

https://rushdb.com/blog/rushdb-the-zero-config-database-for-modern-apps-and-ai-solutions

#development #javascript #database #ai

The TypeScript Agent Framework

Mastra - фреймворк на Typescript для создания ИИ-агентов. Выглядит достаточно хорошо - поддерживает много разного: кастомные тулы, воркфлоу (и контроль их исполнения), RAG, память.

Тут еще не было постов про ИИ-агентов, поэтому небольшая вводная. LLM сами по себе могут лишь предсказывать, какой текст должен следовать за предыдущим. Это достаточно прикольный инструмент, но чтобы что-то сделать нужно а) дать им какие-то данные; б) вести с ними диалог в каком-то фреймворке (дать данные, попросить проанализировать, дать дополнительные данные, снова что-то попросить). ИИ-агенты как раз позволяют закрыть полный флоу работы с LLM - добавляются инструменты (tools), которые позволяют достать какие-то данные, и добавляются воркфлоу или сценарии, которые ведут LLM.

Например, вы хотите сделать код ревью своего МР-а. Как это делается с LLM - создается чат, дается контекст, кидается много файлов и на каждый просится фидбек. Как это делается с ИИ-агентом - вы строите агента, который умеет ходить в апи gitlab или github (и другие апи) для получения данных, в агенте настраиваете воркфлоу как делаются код-ревью. А дальше заходите в чат с ИИ-агентом и говорите "сделай код ревью моего последнего МР-а", а дальше ИИ-агент сам пройдется по всем инструментам и сценариям и сделает для вас код ревью

Возвращаемся к статье. Mastra - фреймворк для описания ИИ-агентов. Я прямо сейчас играюсь с LangChain.js для создания агента, но, видимо, попробую теперь и Mastra.

https://mastra.ai

#development #javascript #ai #aiAgents

Deno 2.2: OpenTelemetry, Lint Plugins, node:sqlite

Вышел Deno 2.2. Заехали прикольные фичи: поддержка из коробки sqlite и OpenTelemtry, улучшения линтера, поддержка QUIC (http3), улучшение совместимости с Nodejs API, а также различные работы по перформансу.

Я бы хотел отдельно выделить поддержку Open Telemetry в Deno. Open Telemetry - это крайне важна штука, для обеспечения observability ваших систем. Open Telemetry - это набор соглашений о том, как следует логировать операции в IT-системах. Обычно OT встраивается в фреймворки, либо вы сами подключаете ОТ и инструментируете свой код. Deno же сам инструментирует основные методы (console.log, fetch, Deno.serve), а все что надо инструментировать сверх - остается на вас.

Также в Deno встроен Open Telemetry Exporter - вам достаточно запустить Deno с режимом OT и указать ендпоинт экспорта OT вашего Deno-приложения и телеметрия польется в вашу целевую систему, где вы можете отслеживать все действия юзера.



https://deno.com/blog/v2.2

#development #javascript #deno #releaseNotes

Bundling Dependencies

Статья разбирает, стоит или не стоит бандлить зависимости в свои библиотеки.

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

Зачем может понадобится бандлить зависимости:
- Если у вас зависимости в CommonJS, а делаете решение для браузеров. В этом случае вам проще забандлить эту зависимость
- Вы зависите от очень большого пакета, но используете лишь малую часть. В этом случае можно забандлить малую часть, чтобы не заставлять всех юзеров тянуть огромную зависимость
- Внутренние зависимости. Например, у вас моно-репо и куча мелких пакетов-утилок. Проще их забандлить, чем заставлять юзеров тянуть десятки внутренних мини-пакетов
- Если есть цель быть dependency free или zero dependency

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

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

Примеры библиотек, которые пребандлятся:
- Vite - инструмент для сборки, который не используется напрямую в продакшне. Все зависимости пребандлятся, чтобы предоставить удобный опыт использования. Однако, теряется возможность обновлять зависимости Vite на стороне приложений. В будущем Vite планирует перестать бандлить все зависимости
- Storybook также бандлит свои зависимости. Причем, бандлинг начался относительно недавно и значительно улучшил свои перформанс метрики из-за этого, поэтому вряд ли Storybook прекратит бандлить свои зависимости

https://e18e.dev/blog/bundling-dependencies.html

#development #javascript #bundle