Ну может просто Inverify будет излишним во Vue3?

Суть инверсии управления (Inversion Of Control, IoC) заключается в том, что класс передает контроль (читай: ответственность) за создание зависимых экземпляров, которые нужны классу, контейнеру, который вместо этого предоставит им эти экземпляры. Одной из реализаций инверсии управления в применении к управлению зависимостями является внедрение зависимостей (Dependency Injection, DI). Inverify реализует инверсию управления и, из того, что я видел и трогал, изредка использовался с Vue2 через Class API (который реализуется сторонними библиотеками). Там использование подобного подхода оправдано тем, что с инкапсуляцией частей логики, шарингом кода и менеджментом состояний все непросто, так как нехватает адекватных механизмов для этого. Эти проблемы в свое время привели к старту разработки принципиально нового фреймворка под названием... Vue3) В процессе рассматривали Class API и Composition API, Composition API победил и вошел в релиз, а Option API достался нам по историческим причинам (ну нельзя так просто взять и заявить, что половину опыта разработчикам стоит выкинуть в мусорное ведро).

Итак, у нас есть Vue3 и Composition API. Без классов. Только setup-функция и useЧтоТоТам кусочки логики. Что мы имеем с этого? Мы можем вынести определенную часть логики в use-функцию. Внутри use-функции может происходить что угодно - мы импортируем только результат в виде ref-ов и функций (назовем их actions-функции). То есть use-функция отвечает за создание зависимых экземпляров, которые нужны компоненту, то есть выполняет функцию DI. Также use-функция может использовать другие use-функции. Все это значительно расширяет возможности декомпозиции, повторного использования кода, и уменьшает зацепление, для чего Inverify и предназначается. Пожалуй, единственный кейс, который мне с ходу удалось придумать для использования Inverify с Vue3 - это когда мы знаем, что будем использовать нашу логику в различных приложениях и средах с различными библиотеками рендеринга (Vue3, React, и т.п.). Но для каждого приложения в отдельности это будет дороже, поэтому стоит дважды подумать, стоит ли игра свеч и нет ли более простых путей.

Что касается стейт-менеджмента, то Composition API тут тоже самодостаточен, когда приложение небольшое и рендерится на клиенте. Достаточно использовать замыкание и глобальный стейт готов. Pinia помогает с SSR и отображением состояния в дев-тулзах, библиотека удобна для более крупных проектов. При написании сторов внутри все пишется точно так же, как если бы использовался голый Composition API, да и в приложении используется практически так же (за исключением использования нескольких встроенных методов). Поэтому простенькое MVP-приложение очень просто перевести со сторов на use-функциях на использование Pinia. Vuex сейчас смысла особого использовать не вижу, теряется удобство и консистентность использования.

В разговоре о DI нельзя также не упомянуть https://vuejs.org/guide/components/provide-inject.html. Его можно использовать при разработке декларативных библиотек компонентов, но это такая штука, которая может неочевидно выстрелить в ногу, использовать следует с осторожностью.

Итого, на мой взгляд, использование Inverify с Vue3 избыточно и усложняет написание кода. Грамотное использование Composition API, Pinia (при необходимости), декларирование интерфейсов (если используется TS) и соблюдение принципа инверсии зависимостей решает все эти проблемы.

Изучать JS глубоко и всерьез надо, как и другие языки и технологии. Когда встречаешь вакансию на джуна с "JS + React/Angular + PHP + Django + Mysql и многое другое" - просто закрывай вкладку, они сами не знают, чего хотят)

То, что найти работу без опыта нельзя - это не совсем так. Сложно, но можно. На что у себя в компании смотрим, когда приходят кандидаты во фронтенд: концептуальное знание языка и программирования в целом (своими словами, ну забыл какое-то определение - и фиг с ним, главное, чтобы хотя бы на пальцах рассказал), навыки работы c HTML/CSS/JS и особенно - навыки командной работы, знание Git на достаточном для повседневных задач уровне. Где взять навыки командной работы, если у тебя нет команды? Нужно самому стать командой) Вести пэт-проекты так, как будто на проекте кроме тебя еще два десятка человек, выполнять разные роли. Следить за тем, что и как коммитишь в репозиторий. Если пользовался каким-нибудь трекером - это плюс. Если работал хотя бы с одним фреймворком - тоже плюс. Если можешь показать пэт-проекты, где ты что-то действительно сделал, пусть небольшое, но решающее какую-то задачу - еще один плюс. Бывает, что эти плюсы перебивают опыт работы 5+ лет (хотя там вообще тяжелый случай был))) Потому что опыт - дело наживное, но далеко не каждый обладает способностью обучаться достаточно быстро и непрерывно, набирать это самый опыт и использовать.

Сейчас для многих компаний непростой период, не самое удачное время для поиска работы. Но можно пока прокачивать свои скилы, делать CV, что-то там выкладывать на гитхаб. Попробовать поиграть в "команду" с самим собой. Откликаться на вакансии, пытаться пройти собес. Вот как о тебе узнать, если ты себя не показываешь? Не "открыл hh... и закрыл", а целенаправленно и методично занимаешься поиском. Если откажут в 9 местах - это ок, бывает. В 10-ом могут и взять.

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