#подкаст

Разбираемся, кто, зачем и как обновляет JS.

Присоединяйтесь к обсуждению пропозалов — уже через час!

Новый выпуск «Тяжелого утра» в 11:00:
— на YouTube
— в VK Видео

Хочу похвалить команду Lynx(если вы как-то пропустили новость, то это "Убийцы" ReactNative/NativeScript), ведь кроме документации они еще реализовали целую спеку! Я почитал ее и написана она весьма хорошо, как минимум обильное описание каждого термина есть, а это уже много стоит. Хорошо приправлена ссылками на отдельные части, язык более чем понятный и сама спека не такая уж и длинная. Алгоритмы в нем описаны весьма интересно, через под-заголовки и описание действия в них(стейджи), прям алгоритмов как в спеке ES или HTML там нет.

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

PS. готовлю еще один пост про Lynx на vue-канале относительно текущих дел со Vue + Lynx

TS СТАЛ BLAZING FAST

Пока все в экстазе носятся с ускорение TS в 10 раз, я призываю вас подумать о выборе golang. Да, авторы объяснили свой выбор и я полностью уважаю его с технической и менеджерской точки зрения (минимизация расходов, скорость перехода, уменьшение кол-ва потенциальных проблем и тд). И в целом перф круто, все дела! Но я немного попробую посмотреть негативную сторону, чтобы уравновесить настроения.

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

Я не просто так зачеркнул BLAZING в заголовке. Думаю все догадались о чем пойдет речь: почему не Rust. И я не хочу сейчас обсуждать что из них круче. Будем обсуждать это исключительно с точки зрения влияния на экосистему.

1. Экосистема туллинга на языках
Rust уже состоялся как основной язык для туллинга в мире JS. Я уже писал об этом в старом посте. И количество этого туллинга с момента поста только росло. А почему это важно? Так как таким образом было бы гораздо проще делать интеграции с уже кучей туллинга написанного на Rust, возможно даже появилось бы какое-то переиспользование. Относительно gonalg: битву за туллинг он проиграл во многом по причине ниже. С другой стороны если не брать экосистему туллинга, а JS/TS разработчиков. То full-stack связка с go очень даже популярна и возможно сподвигнет появлению большего количества контрибьютеров

2. Производительность в WASM.
Да, перф Go в WASM это тема отдельного обсуждения. По ссылке вы найдете еще ссылки на другие обсуждения и так можете погружаться в тему сколько хотите. Но факт есть факт - go не самый производительный в контексте WASM. А зачем нам это? Плейграунды, web-container-ы и прочие ситуации когда у нас все гоняется в браузере не супер редки. Другая сторона: вполне возможно это станет мотивацией наконец-то довести перф Go в WASM до должного уровня или Microsoft инвестирует в инструмент который сможет это реализовать лучше(например в tinygo или другую альтернативу). Потыкать WASM GO (НЕОФИЦИАЛЬНАЯ ВЕРСИЯ) можно тут [исходники] (там выводится скорость компиляции в браузере)

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

В остальном же радуемся и ждем TypeScript 7 (версия с которой Go версия станет основной).

👀 а вот этого я не ожидал 👀

Если что это все еще старая спека 2019 года. С тех пор она больше не обновлялась

Но вот что запланировал он с ней делать мне крайне любопытно.

Boshen - автор экосистемы oxc. Так что любопытно вдвойне, может нам и удастся увидеть кое-что дельное

The pit of Failure (or Success)

Часто при проектировании API кроме того что нам важно думать не только о фичах и возможностях которые он дает, но и какой импакт этот API несет при использовании. И тут есть 2 противоположных концепта: Falling Into The Pit of Success/Failure или при переводе Упасть В Яму Успеха/Неудачи.

Какие же ключевые принципы разработки за этим скрываются? Если сократить и упростить, то выйдет: Делай так чтобы правильно было использовать легко, а неправильно сложно. Те наша задача мотивировать людей и поощрять правильное использование API и делать так, чтобы некорректное использование всем видом кричало, что тут дела обстоят не так (fall into the pit of success). Обратный пример, когда API словно подталкивает использовать себя грязно, а использовать корректно больше похоже на тернистый путь или полосу испытаний (Я думаю каждый сталкивался с таким ощущением)

Давайте возьмем пару примеров из API и рассмотрим их:
React:

<div dangerouslySetInnerHTML={{ __html: "Hello" }} />

И тут нам интересно API dangerouslySetInnerHTML, видите что оно делает? Да, оно всем своим видом кричит, что вы делаете что-то опасное и нехорошее, а громоздкость с { __html: "Hello" } дополняет картинку. В добавок вам еще будет сложнее точно сходу вспомнить правильное написание и вы пойдете в документацию, где вам еще раз дадут понять: "скорее всего ты делаешь что-то не то". Это прекрасный пример того, как с помощью API вам не дают применить нечто потенциально опасное.

И вот сегодня я увидел обратный пример из мира Svelte:

let double = $derived(count*2);
double = 3.14;

Это сегодняшний анонс долгожданной фичи, чтобы вычислимые значения могли быть временно изменены. Крутая же фича? В целом да, ее запрашивали и ждали, а без нее приходилось использовать костыли. И вроде как надо радоваться? Нам же дали возможность и маловероятно, что оно что-то сломает... Но вот тут как раз всплывает тема того к чему мы подталкиваем дизайном нашего API.

В реактивной системе необходимость делать writable вычислимые поля достаточно редка. Кроме того нам дали возможность делать только прямую запись, а не условный сеттер который бы позволил сделать two way connection, нет, это не тот случай! Те мы можем просто лезть в кэш вычислимого свойства и подменять его до изменения значения. Ну надо же людям эту фичу, в чем проблема? А в том, что в 99% случаев эта фича не нужна, а вот все 100% $derived полей стали вместо read-only теперь writable. И никакой вас TypeScript не спасет от записи в него случайно (например, при рефакторинге) и вы больше видя перед собой $derived не можете быть уверены записывают что-то в него или нет, эта информация лежит где-то в другом месте компонента и пока вы не прочтете код компонента полностью вы больше не можете быть в этом уверены.

Таким образом эта возможность не подталкивает к правильному использованию сигналов, делает так что допускать случайные ошибки стало проще и при этом осталось относительно скудным по возможностям (как и написал это не дает возможность делать two way connection). С другой стороны мы покрыли возможность 1% от случаев. Вот это пример, когда мы видим собой pit of failure, да нас не мотивируют прямым образом использовать этот функционал неправильно, но "заборчик" рядом с ямой куда-то унесли.

Как этого можно было избежать?
Использовать отдельный нейминг

let double = $writableDerived(count*2);
double = 3.14;

Или использовать отдельный параметр

let double = $derived(count*2, { writable: true }); // или любая другая явная модификация
double = 3.14;

Или на худой конец если мы хотим оставить магию в нашем мире, то создать явное API

let double = $derived(count*2);
$modifyDerivedCache(double, 3.14); // мы сделали неудобное, но однозначное API

Это все еще лучше, чем выкинуть забор и дать неявное по смыслу API.

Не думайте что это "написать плохо на чем угодно можно" /"вопрос прямых рук". НЕТ! Вы, как автор API, должны формировать у людей прямые руки, а кривые выпрямлять. Пожалуйста, прикидывайте в голове эти сценарии: "мотивирую ли я делать что-то плохое" и "поощряю ли я правильное использование". Спасибо...

Дождался. Доклад по Шестеренкам реактивности Vue наконец-то вышел. В нем были разобраны базовые механизмы на которых основана работа реактивности во Vue.

- Ссылка на презентацию
- Ссылка на карту реактивности

И так полезный сопровождающий материал:
- Chibivue [Ru]
- Курс от Michael Thiessen

Когда речь заходит о изучении TypeScript в голову сразу приходит Matt Pocock. Настоящий маг TypeScript-а и автор лучших статей по этому языку. И вот он выкатил нам новый подарок: Total TypeScript Essentials.

Это книга по всему TypeScript который нужен разработчику, да она не охватывает все таинства языка, но базу дает очень хорошую. Книга совершенно бесплатная и при быстром обзоре мне показалась очень хорошо структурированной и наполненной. Вполне возможно, что на данный момент это наиболее актуальная и лучшая книга для изучения TypeScript (так как книга была выложена лишь недавно, то прочесть полностью ее я не успел, чтобы это утверждать однозначно).

В целом появление таких ресурсов всегда радует. А если содержания книги вам покажется мало, то однозначно рекомендую ознакомиться с его статьями и youtube каналом, где разбираются уже более узкие темы подробно

#ts #материалы

С минуты на минуту (в 19:00мск) приму участие в Frontend-свояке от SiberiaCanCode (большое спасибо за приглашение Диме!). Думаю будет много веселых вопросов и неожиданных тупняков. В целом приглашаю весело провести с нами время!

Площадки: twitch, youtube

С минуты на минуту будем заполнять The State Of HTML 2025 и обсуждать текущее положение веба.

Ожидается огромный поток информации на выпуск :D

#подкаст

Заполняем State of HTML 2025 в новом выпуске «Тяжелого утра» — завтра, 2 августа в 11:00 по Москве.

Подключайтесь к нам на удобной платформе:

— Twitch
— YouTube
— VK Видео