Всем привет.
Сегодняшний стрим по истории фронтенда перенес на завтра.

Причина крайне простая. Сегодня просто пообщаемся и позадаем вопросы.
А я хоть вспомню каково это быть стриммером. Дружно все настроим и проверим, чтобы завтрашний доклад прошел на ура

Итого основной контент завтра.
А сегодня общаемся, делюсь новостями и поясняю за разработку
https://www.twitch.tv/izede

Такс, косякнул с стримами на прошлой неделе. Виноват перед вами.

Были некоторые обстоятельства рабочие и семейные. Но план по контенту не отменяется
Сейчас и в субботу совместный стрим c siberiacancode

В воскресение (4 августа) будет стрим с перезапуском по истории фронтенда
А во вторник (7ого) будет стрим посвященный разбору V8

Раз уж забегался я по конфам в последнее время, то хотел бы и подсказать классную ссылку с IT-мероприятиями Networkly Google Calendar,
Тут IT-ивенты всех категорий по РФ. Если вам нужны ивенты по категориям, то тут лучше идти на главный сайт.

Для других стран скорее всего есть свои календари и будет круто если вы ими поделитесь.
Но из международных приличных пока нашел только dev.events.

Но для чего вообще эти мероприятия? У каждого будет свой ответ. Для меня это главным образом
1) Мотивация довести реализацию до конца чтобы с ней выступить
2) Способ расшарить знания на публику
3) Способ вживую пообщаться с невероятным количеством очень крутых ребят
4) Ну и конечно же: хорошо провести время

Мои субъективные советы по конфам:
1) Если у докладов есть запись, то посмотреть ее вы сможете и дома. Если есть в планах занятия поинтереснее на конфе, займитесь ими
2) Составьте маршрут посещения докладов и знакомств с людьми заранее, так проще будет перемещаться и находить время на какие-то активности
3) Очень большая часть знаний и живого общения происходит именно на afterparty в неформальной обстановке, советую приберегать на него силы

PS. уже на этой неделе и следующей проведу серию стримов по различным темам. Так что можете накидывать идей

Angular. Все еще показывает результаты угасающей звезды. Популярность по данному опросу падает, но вот с точки удовлетворенности поддерживается на 1 уровне. Возможно в 2024ом будет некоторое смещение в сторону большего количество положительных впечатлений о нем. Все-таки с начала года команда Angular подарила много чего: обновила полностью сайт документации и логотип, активно внедряет новые фичи, Люди узнают о Analog.js. Так что будем ждать нового опроса.

Vue. Крайне любопытные результаты, но вполне предсказуемые. Итак, мы можем видеть что в 22-ом график у Vue был очень даже грустный. Резко скануло вниз и кол-во использований и удволетворенность. Причина же тут крайне простая: Миграция Vue2 -> Vue3 это та еще боль. Куча людей разочаровалось в фреймворке. Однако время идет и народ все-таки начал получать плюсы от всех изменений Vue3. Количество адептов значительно возросло, фреймворк окреп и готов к серьезным вызовам. Это и можно видеть на графике с скачком и по кол-ву использований и по кол-ву положительных отзывов. Жду и в новом году от него положительной динамики, так как в инфопространстве наблюдаю лишь большое кол-во положительных отзывов о нем. Но ложка дегтя есть: после обновления TS5 вначале год колбасило багами WebStorm, а в 2023 после обновление Volar до v2 и пользователей VSC. И вот тут порой звучат отзывы крайне разочаровывающие. Будет любопытно посмотреть как же это скажется.

Svelte. Ну у него все хорошо. Потихоньку набирает жирку в виде использований, слегка подрастерял в "уровне счастья", но этот показатель достаточно велик, чтобы пока на это внимания не обращать. На момент конца 2023, насколько я помню. руны только только были анонсированы, поэтому влияние предстоящего Svelte5 в опросе маловероятно. А вот в новом году очень будет любопытно посмотреть. Общее настроение от изменений Svelte5 можно описать как: неоднозначное. Что-то улучшили, что-то испортили. Запаха react от Svelte сильно возросло (возможно это связано с тем, что в прошлом году Рич Харрис, создатель Svelte, был нанят компанией Vercel, чьим главным продуктом является Next.js, aka главный способ использования React на данный момент).

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

Отдельно отмечу здесь Astro, хоть это и не Frontend-фреймворк. Народ с него просто тащится. Шикарные результаты и темпы развития. Пожелаем удачи. Крайне рекомендую с ним всем ознакомиться.

Что же касается общего впечатления по Frontend-фреймворкам то он начиная с 2018-ого показывает нисходящий тренд. Удивляться тоже нечему: народ все рвется на сервер к SSR/SSG/ISR и тп, а это резко увлечивает сложность разработке в конечном итоге. Фреймворки сильно усложняются. Народ плохо поспевает за "новомодными трендами". А главный локомотив фронтенд-фреймворков выдает очень спорные решения, что еще больше повышает градус недовольства. Ожидаю в новом году еще большего снижения этого показателя.

Кратко об инструментах тестирования: есть Jest, а есть Vitest. И у того и у того все замечательно. Для E2E все шикарно у playwright. Еще у нас есть Storybook проблема которого: отсутствие хоть каких-то конкурентов.

Отдельно отмечу, что в опросе прекрасно себя показал pnpm. Вполне заслуженно. Быстрый, простой. А что еще надо для счастья? Если ищете замену yarn/npm, то это самое оно и для монореп тоже неплохо подходит.

И так. спустя более чем полгода мы все-таки получили результаты от State Of JS 2023(я уже и не ждал). Все задержалось из-за того что организатор опроса выгорел и попросил помощи других людей с анализом собранных данных. Может поэтому в некоторых местах пугающие цифры по объемам данных которые "не учли". Чуть позже поймете о чем я.

Проведу небольшие итоги от себя:

1) Народ считает самой главной проблемой в JS:
1.1) Отсутствие статической типизации из коробки. Причем лидирует этот пункт с большим отрывом (33% vs 9% у второго места). Оно же лидирует в списке "фичей которых не хватает"
1.2) борьбу между CommonJS и ES Modules
1.3) Болезненность работы с датами
2.3) 84% ответов не смогли определить куда-то в конкретное место. Число зашкаливающее

2) Народ считает самой главной проблемой при работе с браузерами:
2.1) Поддержка браузерами. Достаточно спорный пункт на мой взгляд. Вспомнить что было лет 15 и даже 10 лет назад, то сейчас кроссбраузерность гораздо меньшая проблема. Возможно этот пункт стоит скорее считать как "скорость поддержки". Те, люди видят классные фичи, а потом понимают, что N лет все равно не смогут ими воспользоваться. Вот это уже действительно несколько огорчает. Процент отметивших этот пункт 32%, что тоже ЗНАЧИТЕЛЬНО выше второго места с 6%
2.2) Safari. Когда я проходил опрос этого пункта не было, но это не помешало ему забраться на второе место... Думаю этого достаточно, чтобы понять всю радость программистов от этого "инструмента".
2.3) 76% ответов не смогли определить куда-то в конкретное место. Это что-то перебор. Думаю, что потеряли большое кол-во информации

Далее переходим к самому интересному разделу: библиотеки
Тут можно написать 1 слово: Vite. Vite буквально рвет все топы. Из 6 "наград" опроса Vite взял 3. При этом еще в 1 отстав всего на 2% процента от... Vitest, который тоже замечательно показал себя заняв топ тир среди инструментов тестирования. А вот Webpack четко летит на дно по показателю удовлетворенности. 48% респондентов отметило его как "использовал его, впечатления неприятные". Я могу его назвать самым быстропадающим с точки зрения впечатлений о нем. Забавный момент, что на приложенном графике. То где сейчас находится Vite, это то где в 2017ом был Webpack. Так что, возможно, лет через 6 Vite может ждать такая же судьба.
Что касается других сборщиков, то SWC и esbuild также попали в топ тир. А вот строчки аутсайдеров занял Parcel и Webpack.

Теперь идем к тому чего я больше всего ждал: Frontend Frameworks. И тут ситуация любопытная. Разберемся с каждым фреймворком по отдельности. При этом я оставлю предупреждение:
Опросы всегда штука специфичная и может давать ошибки в зависимости от захваченных групп опрашиваемых. Обычно люди проходящие опросы более заинтересованы в разработке, чем люди их игнорирующие. При этом люди проходящие опросы тоже чаще являются early adopters(люди берущие на вооружения или пробующие что-то малопопулярное/свежевышедшее). Поэтому стараемся учитывать эту погрешность и не принимать результаты опроса близко к сердцу. Конец предупреждения.

React. Мягко говоря cдает позиции относительно опроса. При этом он не падает в популярности (а даже растет), но вот процент недовольных им очень быстро растет. (это можно увидеть на том же графике с "кометами"). И черная полоса пошла с 2019. Я это связываю с подниманием головы других решений: Vue3, Svelte/Solid. Народ буквально увидел, что можно решать проблемы иначе. Далее команда реакта начала жить своей жизнью, время от времени повергая в шок программистов своими новыми фичами, которые приходилось откатывать после волны справдливого хейта. Опрос был сделан в декабре 2023, так что в 2024 интересно увидеть динамику после выхода React 19, все большего доминирование Next и нового React Compiler-а. Но сколько не ругай реакт, а с точки зрения популярности он все еще только растет. А вот Next.js прям очень сильно скакнул вниз по "уровню счастья". Сомнительные решения и app router, думаю, приложили к этому свою руку.

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

С последнего поста народу тут явно поприбавилось. Welcome!
Поэтому кратенько о себе:
Я - Чернов Денис. Работаю в Спортмастер-е на Vue-хе. Влюблен в кодинг уже 13+ лет
Увлекаюсь IT-шкой в широком смысле. Внимательно слежу за всеми колебаниями в области фронтенда.

Что можно увидеть на канале:
1) Новости которые показались мне наиболее интересными. Обязательно с разборами и кучей ссылок на источники
2) Интересные моменты из Frontend-разработки и не только
3) Отчеты и доп материал по моим докладам.

Говорю я о всех фреймворках, но особой любовью тут пользуется именно Vue.
Что впрочем и стало причиной моего последнего доклада на Vue Msk.
Это стал заключительным выступлением в моем первом "спикерском сезоне". За пол года 3 конфы и 1 митап (все доклады разные, но один модификация более старого)

Выступление было на тему подкапотной реактивности во Vue.
Итого презентация: преза, исходник (напоминаю, что управление стрелками или мышкой в нижнем левом углу)
Видео с выступления: youtube

Материал для дальнейшего изучения:
1) chibi vue - буквально лучшего руководства не найти в духе с 0 до своего мини-Vue. Позволяет хорошо прочувствовать работу под капотом
2) rfc effectscope - хорошо разбирается тема с effectScope
3) watch with @vue/reactivity - в докладе я говорю про отсутствие watch/watchEffect внутри @vue/reactivity. В статье Энтони разбирает подкапотную работу реактивности во Vue и как все-таки вернуть watch
4) reactivue - шуточный (или нет) способ объединить "лучшее" по мнению Энтони между react и vue. Как раз способ запустить @vue/reactivity внутри react.
5) vue-lit - PoC как запустить реактивность vue внутри lit-html
6) исходники @vue/reactivity, Но внутри @vue/runtime-core тоже хватает интересностей (scheduler, apiWatcher/apiComputed)

sdju.github.io

The Progressive Path

To close or not to close

Забавная дискуссия(на самом деле самый настоящий холливар) выдалась в одном ишьюсе в репозитории Svelte.

Кратко: Рич Харрис(создатель Svelte) только сейчас обнаружил, что

```

Hello
```

Это не

```

Hello
```

А

```

```

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

Вначале разберемся с ситуацией в HTML:
HTML - не имеет понятия self-closing element. Вместо этого есть void elements: br / hr / input и тп. Так же есть допущение для внешних элементов: svg/mathml, которые реализованы на основе XML. В стандарте XML self-closing tags называются empty-element tags(элементы у которых нет контента). В остальных случаях HTML просто... игнорирует завершающий /, но с 1 исключением

```

тоже самое
не верно (Svelte и этот тест провалил)
```

JSX(React. Solid etc...) - поддерживает self-closing tags
Angular - только с 16-ой версии начал их поддерживать для своих компонентов, в остальном все как HTML. Кстати, там тоже была бойня, хоть и поменьше
Lit - все согласно HTML. Кстати, согласно спеке даже custom elements не могут быть самозакрывающимися. Один человек недовольный отказом, даже сделал расширение добавлющее этот функционал
Ember - официально поддерживает self-closing tags, как часть расширения HTML
Vue - тут все сложнее.
1) Если используется рантайм компиляция шаблонов из HTML, то работают правила HTML и все работает согласно спеке
2) Если происходит этап билда шаблонов, например со сборщиком, то self-closing tags доступны.
При этом в vue eslint можно четко разграничить желаемое поведение. Но и это было не всегда и сам Эван был против self-closing tags, но с появлением vue-loader все-таки поддержали данный функционал.

Как мы видим единого мнения в сообществе вообще нет. На одной чаше удобство, на другой плашка "соответствует HTML5"и куча различных трейдоффов.

А что считаете вы, как должны поступать фреймворки?

GitHub

Svelte parses HTML all wrong · Issue #11052 · sveltejs/svelte

Describe the bug I'm a little shaken up. For as long as I've been programming, I thought that this... <div /> ...was shorthand for this: <div></div> It turns out it's ...

Вообще не секрет, что Vue единственный популярный фронтенд-фреймворк за которым не стоит ни одна корпорация и Vue очень гордится этим (на самом деле Solid.js тоже может в эту категорию попасть, но ему нужно подрасти по популярности). Что же это значит? Что…

Так проблема имеется. Но как ее решить? Может использовать undefined вместо явного void? Тоже не выход,
- так как функции () => void не являются расширениями к () => undefined
- так еще и всегда придется четко прописывать типы

const someFixed = (cb: () => (undefined | number)) => {} someFixed(() => undefined) // все окей someFixed(() => {}) // ERROR! void несовместим с undefined

Мне пока не пришло в голову как можно красиво это обойти, да и у команды React видимо тоже. И нет, мы не первые сделали это открытие. Есть вот такой пропозал в TS.

В нем данная тема рассматривается достаточно подробно. Кто осилил "лонгрид" спасибо. Буду рад услышать чужие мысли. Ну и спасибо тем, кто подталкивал меня к верным рассуждениям в моем импульсе(отдельное спасибо @cevek) :D

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

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

Обычно я не пишу сюда технический материал. Но почему бы и не попробовать.

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

На TS взвалили непосильную задачу: решить проблемы с типизацией TS для повышения DX.
А у JS хватает своих приколов: неопределённый тип у this. Почти что угодно может стать чем угодно. Расширение прототипов и тд…

Поэтому у TS крайне сложная модель системы типов которая то и дело дает сбои.

Сегодня я бы подсветил проблему у типа void. Что же он означает?
Что функция ничего не возвращает? Мммм не совсем. Это значит, что результат функции должен игнорироваться.
Те результат функции не должен ни на что влиять.

Делаем пару простых пассов с типами:

```
function foo(test: boolean): void {
if (test) {
// можем делать пустой возврат
return
}
// можем явно возвращать undefined
return undefined
}

function bar(test: boolean): void {
if (test) {
// (ОШИБКА!) другие falsy значения не прокатят
return false
}
// (ОШИБКА!) другие falsy значения не прокатят
return null
}
```

Пока вроде все хорошо. Но значит ли что void подобен undefined?
Продолжаем следить за руками

function baz(test: number): void { if (test === 0) { // результатом функции которая возвращает void может быть вызов функции возвращающий void return (function(): void {})() } else if (test === 1) { // результатом функции которая возвращает void может быть вызов функции возвращающий undefined return (function(): undefined {})() } else if (test === 2) { // (ОШИБКА!) а вот другие функции не пустит return (function(): number { return 5 })() } }

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

```
function qux(cb: () => void) {
    return cb()
}

// все хорошо
qux(function(): void {})

// и все еще все хорошо
qux(function(): undefined {})

// стоп что? Ошибки нет
qux(function(): number { return 5 })
```

Вот тут уже начинаются странности. И тут уже начинаются расхождения void с undefined. Те мы можем передать как аргумент функции которые возвращают что угодно (да даже never)

// все окей, вызывай функцию qux(function(): never { throw 5 })

Что же это значит? Да то что любой тип может расширять void? Да нет

```
type isVoid = X extends void ? true : false

type test1 = isVoid
//   ^? true
type test2 = isVoid
//   ^? false
type test3 = isVoid
//   ^? never
```

Вроде не расширяется. Возвращаемся к нашим функциям и смотрим как расширяются void функции

```
type isVoidFunction = X extends () => void ? true : false

type test4 = isVoidFunction<() => undefined>
//   ^? true

type test5 = isVoidFunction<() => null>
//   ^? true

type test6 = isVoidFunction<() => never>
//   ^? true
```

Вот оно как... Но это лишь подводка к главному примеру: void и сложение типов. void по своей сути говорит, что "игнорируй возвращаемое событие". Но если мы его смешиваем с другим значением, то TS закрывает руки и говорит "ну делай что хочешь"

```
const some = (cb: () => (void | number)) => {
    const value = cb() // void | number

// отсекаем void
    if (value) {
        value
        //^? number
    }
}

// ожидаем функцию которой все равно что вернет (например для мемоизации)
const example = (cb: () => void) => {
    return cb
}

// и ломаем рантайм к чертям, ибо TS пофиг
// он считает что () => 'hello' это расширение для () => void
// а вот JS пойдет по пути number
// так как 'hello' пройдет проверку на if (value)
some(example(() => 'hello'))
```

Вам кажется что тут пассы такие синтетические? Далеко ходить не нужно. union-ы с void вполне используются в коде React-а для useEffect

```
type Arg = Parameters[0]
//    ^? () => void | Destructor

// Нет проблем. вот вам async коллбек для useEffect
// Конечно он не будет работать как надо, но TS доволен
useEffect(example(async () => {}), [])
```