С минуты на минуту начнется совместный контент с Siberiacancode. Где мы проревьювим его код на Vue и поговорим о различных путях решений проблем во фронтенде.
https://youtube.com/live/_z9ZEoluOFQ

твич https://www.twitch.tv/siberiacancode

Поделюсь небольшой радостью
Мой доклад прошел на Holy.js начинаем к нему готовиться.

ПС. в комменты кинул видео с прошлого доклада на UfaDevConf для тех кто еще не видел

И еще раз уж начал о новостях. Вчера поучаствовал в новом для себя деле.
Участвовал в роли спикера на съемках курса по Vue.js
И это прям... супер тяжело :D
почти 6 часов записывали буквально 5 небольших уроков.
Если честно, вышло прям совсем плохо- у меня. Но я и шел туда с целью получить этот болзненный опыт и поднять кач-во контента.
Хотя вряд ли я смогу перед видосами или стримами пол часа делать мейкап (да гриммировали прям по жесткому :D)

Подготовка этого курса как текстовой версии так и видео съела прилично нервов и времени.
Зато узнал много нового и, думаю, смогу в скором времени реализовать его и для вас.

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

У меня дико неоднозначные ощущения от 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> = X extends void ? true : false

type test1 = isVoid<undefined>
//   ^? true
type test2 = isVoid<null>
//   ^? false
type test3 = isVoid<never>
//   ^? never

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

type isVoidFunction<X> = 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<typeof useEffect>[0]
//    ^? () => void | Destructor

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

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

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

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

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

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

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

Ладно, таких тонкостей о появлении React я не знал 😀

Появление React ребята из Facebook часто объясняют примерно вот так:

В далеком 2013 году в Facebook Chat часто появлялись фантомные сообщения: уведомление приходило, иконка загоралась, а самого сообщения не было.

Это было вызвано ужасным императивным кодом, а чтобы это починить и был придуман React.

У меня всегда были вопросы к этому объяснению. А вчера Adam Wolff причастный к разработке добавил деталей:

Да, React, был действительно создан для решения проблемы фантомных уведомлений, но эту проблему он в результате не решил, потому что проблема на самом деле была в кривых настройках DNS где-то в Индии, и когда DNS починили проблема ушла.

https://twitter.com/dmwlff/status/1762885255030259854?s=20

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

Надеюсь, что интересно будет всем

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

Что я заметил (сам дизайн разбирать не буду):
1) Отношение между Current / LTS кнопками загрузки
- раньше было на главном экране только 2 равнозначные кнопки: скачать LTS / скачать Current
- теперь кнопка лишь у LTS версии, а вот "Current" уехала скромненько в ссылочку под кнопкой (я ее даже не сразу заметил)

Чем это интересно? Ну как минимум, что у ноды изначально необычное использование semver-а
по факту имеем, что четные мажоры - это stable версии
нечетные мажоры - это unstable версии (хотя, конечно, они не называют его так, но он по сути им и является)
те основная доля новых фичей приходится на нечетные мажоры (например сейчас это node 21), а к четному релизу они стремятся исправить как можно больше багов.
Подробнее можно почитать о релизном цикле node.js тут и тут

И вот решили большинство пользователей огородить от потенциальных проблем таким интересным способом, предлагая явно лишь LTS версии. Я с ними полностью согласен

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

3) Страница загрузок
- Больше не пугает новичков страшной таблицей в которой нужно сделать выбор, а сделали интерактивный селектор
- Добавили готовые скрипты установки для инструментов NVM / Docker etc

4) Контент
Контент между сайтами одинаковый. Но добавили несколько фишек:
- навигация справа по контенту
- ссылочка на страничку в гитхабе (мастхев, если делаете доку, то лучше всегда такое добавлять)
- в конце статьи Prev / Next ссылки

5) Документация
А вот сама документация пока осталось прежней, но она ссылается на старый сайт, так что может и его тоже обновят

PS. Что по стеку?
Можно почитать тут
Кратко: остался прежним (Next + tailwind + radix ui)
переезд на Next был пошаговым более года назад, до этого момента они сидели на metalsmith

"ЯЛЮБЛЮJS"

я уже 10+ лет углубленно погружаюсь в дебри языка JS. Но все равно каждый раз находится что-то что меня поражает.
В этот раз речь пойдет о кое чем затертом до дыр: this. И если вы думаете, что вас им не удивить, то либо вы наивны, либо мне остается вам позавидовать.

Возьмем очень простой пример:

const a = []
function b() { a.push(this) }
b.call(4)
b.call(4)

console.log(a[0] === a[1])

Что мы увидим в результате?

Дам вам некоторое время на подумать, а потом дам объяснение

PS. задача без особого подвоха. Никакие стандартные методы не патчились. Прототипы не изменялись и без прочих уловок

#js

Ответ:
Как мы видим, большинство запутались с ответом. Прям ровненько 50/50 разделились
И это не просто так, ибо поведение хоть и без особого подвоха, но 1 особенность в JS есть которая может повлиять на все происходящее: это strict mode.

Да, strict mode это вам не только "больше нельзя перезаписать arguments у функций и this по-умолчанию undefined". Там список изменений прям неплохой и неплохо бы его изучить.
Что же сейчас должно зацепить наш взгляд? А вот этот пункт, который нам уже частично знаком (сделал для удобства ленивых сразу с переводом)

Если this оценивается в strict mode, то значение this не преобразуется в объект. Значение this, равное undefined или null, не преобразуется в глобальный объект, а примитивные значения не преобразуются в объекты-обертки. Значение this, переданное через вызов функции (включая вызовы с использованием Function.prototype.apply и Function.prototype.call), не преобразует переданное значение this к объекту (10.2.1.2, 20.2.3.1, 20.2.3.3).

Те мы все знаем первую часть про то что мы не берем глобальный объект по-умолчанию, а вот то что меняется поведение для других примитивов - большинство не знает. Те в strict mode у this может быть значение `4` / `"string"` / `Symbol` и тп, а вот без него там окажутся результаты выражений `"new Number(4) / new String("string") / (ага, а вот для Symbol так не прокатит, у него нет вызова через new :D)"`. Вот и получается, что не зная в каком режиме запущен код, то вы не знаете какой будет результат у выражения. Забавно, что это реально приводило к багам на проде(например, такая проблема всплывала у автора эффектора @ZeroBias). На всякий случай напомню, что в некторых случаях strict mode включается автоматически: внутри es-модулей, классов и тд

Еще занимательный момент вытекающий из пунктов выше, что 'use strict' должен быть внешний. Те
```
function a() { return this }
function b() { 'strict mode'; return this }
```
разницы никакой не несет в этом плане

Очередная жутко холливарная тема то и дело поднимающаяся в кругах JS-еров.
Многопоточность и JS. И если все еще нет однозначного ответа, то значит в чем-то есть подвох. А он вполне себе есть... терминология.

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

Проблема: понятие многопоточности. Вообще если погуглить многопоточность, то это будет свойствами системы/программы и тд. На язык как-то прямым образом это не ложится. Значит, что это косвенный параметр для языка. В случае JS он обеспечивается чем-то внешним: Host-средой. Именно она определяет это свойство.

Идем дальше. Если посмотрим спецификацию ecma. То там будут упоминаться потоки... но в контексте другого термина Agent(агент). Что это за фрукт такой? Если упрощенно, то по факту это примитив для описания процессов исполнения. И там прям же написано, что агенты не обязаны владеть своим потоком. Вполне возможны сценарии, когда все агенты запущены в рамках 1 потока. Далее, вся спека строится как раз от идеи оперирования агентами.

И вот тут и начинается проблема. Спека нас привязывает к понятию агента и именно им мы должны оперировать. Что уже сказать можно точно: агенты дают нам возможность распараллелить исполнение. Но верно ли говорить, что параллелизм = многопоточность? Решайте сами

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

Рассмотрим это на примере Blink-а. У нас есть вот такой замечательный документ. В нем описание архитектуры и внутренней имплементации воркеров (и даже таскаться по исходникам не надо). И там есть очень крутой параграф: Process and Thread Model. В нем расписан механизм реализации различных типов воркеров (можете полистать до таблички). И там прям четкое разделение: In-process/Out-of-process. Причем используется сочетание "may", те опять же поведение может меняться в некоторых случаях. Часть воркеров могут быть запущены в отдельном процессе(Service Worker/Shared Worker), часть в текущем процессе (Dedicated Worker), а другие вообще в текущем потоке отрисовки(Isolated Worker). Кстати, не поленитесь прочитать главу целиком, там весьма хорошо поясняются различия между этими механизмами и даже есть схема как они работают в браузере.

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

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

От себя: мне просто не хочется привязывать к языку понятия потока как механизма параллелизма, только как потока исполнения. Если язык чешется: назову многоагентовым, остальное лишь создает поводы для холливаров без однозначных ответов.

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

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

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

Давайте возьмем самый простой пример, который только может быть для описания реактивного состояния.

a = 2
b = 5
c = a + b

что мы здесь видим? у нас есть состояние заданное 3мя ячейками: a/b/c. Если это императивный код, то изменение a/b не повлечет за собой обновление с. А вот для реактивной парадигмы если оказывается, что с перестал быть равен а + b. Если это произошло, то по сути мы нарушили заданные правила. Такая система не является реактивной

С другой стороны, если мы напишем что-то такое, чтобы обновить с:

a = 10
systemActualize()

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

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

Это все о реактивном состоянии. Однако, важны и реактивные процессы, которые указывают как одни действия влекут за собой какие-то последствия. Они чуть сложнее. Проще всего их представить на знакомых большинству Event emitter-ах/Event Bus-ах. Те есть некоторая сущность на которую можно подписываться множеству слушателей, и ее можно триггерить. Только чаще всего подписываются не на какое-то событие, а вот прям на сам эффект триггера. Концепция простая, но невероятно мощная если вокруг нее накрутить сверху побольше "мясца". Те такая система будет реактивной, так как она будет автоматически преобразовывать "раздражители" в последствия. Важно, что реактивная система себя показывает в "реальном времени", те это не просто вызов функции. А как создание организма, которое будет реагировать на раздражители. Оставлю как основной пример такого подхода: Rx

Значит ли что если мы реализуем реактивное состояние, то исключаем реактивность процессов. Нет. Но чаще всего библиотеки сосредотачиваются на чем-то одном, а второй элемент оставляют побочным. Например, в Rx удобно описывать процессы, но вот работа с состояниями вызывает затруднения (а особенно, если мы хотим, чтобы код оставался производительным). Обратный пример это реактивная система Vue: в ней легко описывать данные и их соотношения, но вот процессы приходится писать весьма в императивном стиле, реактивные процессы задаются только для прослушивания изменений в данных. Однако, некоторые системы стараются быть одинаково удобны и для данных и для процессов. Такими примерами могут быть Reatom и Effector. (Если вам известны другие такие системы буду рад дополнить). Есть случаи, когда фреймворки просто оставляют 1 систему для данных, другую для процессов (например Angular).

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

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

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

Сегодня расскажу про небольшой лайфхак. О котором просто несправедливо мало людей знают/применяют.

Часто полноценная реализация стилизации в браузере это неоптимальный выбор:
1) Вы не фронтендер и трогать CSS это последнее, что вам хочется делать(и я вас прекрасно пониманию), а накидать что-то на страничке надо
2) Вам нет смысла тратить на это много времени (напр в песочнице, при разработке PoC версий и тд)
3) Ставить полноценную библиотеку компонентов слишком запарно и не стоит того
4) да, даже накидывать подключать классы tailwind / bootstrap слишком муторно

А что-то +- адекватное все равно хочется (так как дефолтные стили браузера ну уж слишком никакие)

Какое решение? classless библиотеки стилей.
Происходит в них ровно то что написано: не пишите никаких классов для стилизации, только семантические теги. Да, просто пишите верстку, а библиотека сама делает все красивенько по мере возможности.

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

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

Моим же фаворитом является PicoCSS (демка),
Если же вам привычен вид бутстрапа то обрабтите внимание на Holiday.css

PS. Если вы любите песочницы, то скорее всего вам будет полезно куда-то сохранить все равно минимальный пресет-стартер.
Можете сделать это в закладки / заметку / сниппет
Напр, для Vue playground вы можете подключить его так
В случае Vite и плейграундах основанных на нем быстрее всего закидывать в index.html


Будьте продуктивны и тратьте меньше времени на ненужные задачи!

Раз уже закинул инфу про ленивые стили, то теперь расскажу про вторую ультимативную фишку для скорости и простоты разработки: https://icones.js.org

На данный момент это поисковик по самой крупной на данный момент OpenSource базе иконок (их более 200 000).
Заходим, выбираем нужный пресет, натыкиваем опций и копируем/сохраняем как нам нравится

Бонусы:
- глобальный поиск по названию / сету
- копирование через кучу возможных форматов (не хватает только формата для Android, так что это шанс сделать шаг в OpenSource)
- установка цвета и стиля иконки
- сбор иконок в бандл нужного формата (в том числе и в иконочный шрифт)

Можно пойти и серьезным путем встроив интеграцию себе прямо в сборщик благодаря unplugin-icons (советую отдельно разобраться с этим инструментом, так как он в целом предоставляет очень мощные опции для работы с иконками в проекте)
Тогда можно вообще не запариваться и писать вот такой код

import IconAccessibility from '~icons/carbon/accessibility'
import IconAccountBox from '~icons/mdi/account-box'

function App() {
  return (
    <div>
      <IconAccessibility />
      <IconAccountBox style={{ fontSize: '2em', color: 'red' }} />
    </div>
  )
}

Уже не раз спасало, когда какому-то пету нужны иконки, а искать в очередной раз в гугле нет желания

Итак, уж не знаю в честь чего такой символизм, но в этот день нам всем вне зависимости от пола сделали большой подарок: Rolldown вышел в публичный доступ (репозиторий / сайт)!

Пояснения для тех кто не в теме:
На данный момент vite один из лучших, если не самый лучший, выбор сборщика для проектов в мире JS/TS. Однако он не был лишен заложенных архитектурных проблем:
- относительно медленный продакшен билд
- неконсистентная дев и прод сборка (так как сборщик для дев и прод сборки отличаются)
- проблемы с чрезмерной загрузкой ESM модулей по сети
- неприятные проблемы для SSR
- ограниченный контроль над разбиением на чанки
- отсутствует Module Federation из коробки (вариация кастомная для vite все-таки существует)

И вот Rolldown это решение призванное устранить часть этих проблем.
1) Оно будет написано на Rust, что даст решению высокую производительность
2) Оно заменит и esbuild и Rollup 1 собой
3) заменить собой часть внешнего туллинга в перспективе
4) Это НЕ ЗАМЕНА Vite, а замена для сердца Vite (esbuild + rollup -> rolldown)

Это будет означать новый рассвет для vite. Однако, решение пока находится в разработке. Но у него уже есть дорожная карта развития с которой можно ознакомиться
Из важного:
- Планируется полная совемстимость с Rollup
- Поддержка системы плагинов, в том числе на JS
- Тесная интеграция с oxc (интересно что покажет этот дует, учитывая что oxc стремится к полной самодостаточности)

Пока нигде не нашел каких-то обещаний по датам до полноценного выпуска и тем более до внедрения в Vite, но раз он вышел в OpenSource, то это становится лишь вопросом времени (моя ставка, что к концу года точно будут эксперементальные сборки vite с подкапотмным rolldown-ом)

PS. С праздником всех для кого сегодня это праздник 🥳🎉

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

Существует и другой вектор получения прибыли: платные курсы и Vue вполне активно этот вектор развивает взаимодействуя с порталами vueschool и vuemastery.
Однако чтобы не вынуждать работяг тратить только свои кровные (ну и завлечь новых клиентов, конечно), несколько раз в году они делают акцию "бесплатные выходные". В это время все курсы доступны совершенно бесплатно. Их достаточно много и они хорошо покрывают всю экосистему целиком (там и Nuxt и Pinia и работа с firebase/vite/vitest и тд и тп так что даже опытные вьюшники найдут чем поживиться).

Вот 23-24 марта будет проводиться этот ивент вновь от vueschool.
Что нужно?
1) Регистрируемся на событие (если не успеете к началу, то ничего страшного, присоединиться во время ивента тоже можно)
2) Ждем указанных дат
3) Уходим в запой просмотра различных курсиков

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

Если вы искали достойные курсы по Vue или ждали момента, когда начать его изучить, то вот оно самое время

Вот слежу я за последними тенденциями в мире JS. И не может не складываться ощущение, что курс весьма интересный наметился.

И вот мое мнение: если вы планируете погружаться в мир JS на уровень туллинга серьезно, то учите Rust. Я не собираюсь заниматься рекламой языка, ибо суть вообще не в этом. Тенденции уже достаточно много лет, что инструменты на JS для JS достаточно забагованные и медленные. И если первое решить системно сложновато. То второе поддается решением используя туллинга на компилируемом языке. Да JS может быть быстрым, но все больше и больше это не "good enough" в некоторых сценариях. И вот было 2 основных фаворита: Golang и Rust. Первый хорошо вписался в ряды фронтов/фуллстаков благодаря своей простоте и дружелюбности (сервера поднимать на гошке к своим фронтам не менее приятно). Но вот все равно инструменты все больше и больше кочуют в сторону Rust.

Главное: на Rust уже формируется полноценная экосистема для создания инструментов на Rust для JS. Примером служит как раз Rolldown, который показал, что oxc может стать прекрасным основанием для ваших инструментов. Я четко уверен, что тенденция будет развиваться как минимум ближайшие лет 5.

Поэтому если вы присматриваете себе какой-то дополнительный язык окромя JS(если вы JS-разработчик да и не только), то Rust будет замечательным вложением
Из плюсов: ниша все еще достаточно просторная, так что если вы хотите прогреметь в OpenSource, то Rust+JS позволят вам этого добиться при желании

Для тех кто заинтересовался оставлю чуточку информации: лучший способ изучение Rust это замечательный rustbook (ru). А на сайте можно ознакомиться с другими книгами для различных задач в Rust.

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