Comments 6
Читая очередную вашу статью меня посещают сильно смешанные впечатления.
Могу предположить, что коллеги рекомендовали вам перенести статьи в раздел «ненормальное программирование» во многом потому, что глядя на способы решения описанных вами проблем, в общем и целом может показаться, что не такие уж это и проблемы. Кроме того, применено достаточно практик, чуждых в мире веб-разработки, вплоть до именования ваших сущностей, что вкупе с текущим состоянием фреймворка кажется лишь созданием новых проблем, а не решением существующих, ведь решается их не так много, а взамен приносится целый фреймворк, навязывающий своё видение процесса, который кто-то должен включить в проект, сопровождать, нести за это ответственность, обучать команду и следить, чтобы очередное обновление ES/сборщиков/транспиляторов/etc не поломали шатко выстроенное взаимодействие модулей.
Безусловно, многие понимают, что веб и JS в частности имеет достаточно много кажущихся «зелёными» для многих популярных языков проблем. Конечно, изыскиваются способы их решения и действительно толковые начинания только приветствуются сообществом, и я хочу лишь искренне пожелать вам успехов в делах, как и терпения в работе с аудиторией, в частности, хабра. Здесь действительно много крутых специалистов, достаточно прошаренных в вебе и знающих не по наслышке обо всех имеющихся тут проблемах и, как это часто бывает, если какие-то начинания воспринимаются здесь в штыки, то это вовсе не потому, что начинания такие плохие, а потому, что у автора есть, конечно же, совершенно верное видение процесса и с мнением сообщества он считаться не намерен, в то же время продолжая насыпать релизов и статей. Вот и вся причина недопонимания.
Спасибо за своего рода поддержку. У меня действительно есть своё видение процесса создания PWA. И я использую сообщество Хабра для проверки этих идей "на излом". Вряд ли можно назвать "популяризацией" серию статей, где в комментах изложенное называют глупостью. Тем не менее, здесь действительно полно специалистов (и крутых, и начинающих) и их замечания дают пищу для размышлений, заставляя обращать внимание на ключевые моменты.
Например, я раньше не обращал внимания на роль main в npm-пакетах. А ведь это способ сокрытия "приватного" кода пакета и документирование "публичного". С подобной проблемой столкнулись в Magento 2 (когда код в отдельном composer-модуле разросся настолько, что нужно было как-то отделить публичную часть модуля от "внутренней кухни") - вынесли "публичный" код в пространство .../Api/.... Тем не менее, подобное сокрытие (что в Magento, что в nodejs) - это такое "джентльменское соглашение". Ничто не мешает "шулеру" (например, моему module loader'у) напрямую обратиться к "приватным" скриптам внутри пакета и поиметь выгоду. Хорошо это или плохо? Зависит от решаемой задачи и применяемых критериев оценки.
Что касается ответственности за риски - ну так риски есть всегда (и с React, Vue, Angular, ...) и ответственность за них тоже. У меня тоже есть риски - я вкладываю своё время в изучение особенностей работы PWA в расчёте на то, что разработчики браузеров продолжат развивать идеи Стива Джобса об использовании web-приложений в смартфонах, от которых Apple отказалась, а Google подхватил.
В отличие от многих других IT-специалистов я очень долго вникаю в языки и платформы. Это другие могут прочитать описание платформы и уже через пару дней лепить с её помощью приложения. Мне нужно пару лет практики, чтобы я мог более-менее уверенно сказать, что я программирую на каком-то языке или использую платформу. И если с языками попроще, то платформы (framework'и) появляются по дюжине на год - я просто не успеваю (и не только я - в Magento до сих пор knockout используется). Вот я и подумал, а запилю-ка я свой framework с DI и namespace'ами. Такой, где удобно будет именно мне. Потому что, что бизнесу, что пользователям - им же всё равно, на чём это сделано. Лишь бы работало, было удобно и денег приносило. И изменялось по-быстрому, если что.
По большей части со всем согласен. Для локального применения, если оно гладко внедрилось и успешно используется, безусловно, все средства хороши.
Мы в своё время несколько раз подходили к этому вопросу и в итоге каждый раз убеждались в том, что в родных es-импортах ничего страшного нет. Особенно это известно матёрым веб-разработчикам, которые годами, десятилетиями не могли получить на фронте нечто подобное) так что это в каком-то плане уже прорыв и, на мой взгляд, используется вполне приятно.
Свои решения оказывались либо громоздкими, тащущими много бойлерплейта, либо же содержащих массу сложных абстракций, что затрудняло посвящение в проект новых участников. В конечном итоге решили отказаться от этой затеи.
Сейчас используем в новом проекте Vue 3 с TypeScript. Впечатления только положительные. К вопросам импортов не относится, но делает, на мой скромный взгляд, куда более аккуратной и надежной типизацию в вашем проекте. В любой современной IDE вышеназванный стек отлично поддерживается, типизация прекрасно работает. В новом Vue сделали большой шаг к решению проблем более ранних версий по части вертикального обмена данных между компонентами, есть нативная поддержка TS. Багов мы не замечали.
Было бы интересно, я думаю, увидеть ваше видение решения поднятых вопросов в виде чего-то более близкого к принятым практикам в JS/TS и с минимальным количеством бойлерплейта и существенного усложнения/переделки новых и уже существующих кодовых баз. Кто знает, вдруг вам удастся придумать библиотеку, которую мы включим в следующий проект)
Это другие могут прочитать описание платформы и уже через пару дней лепить с её помощью приложения. Мне нужно пару лет практики, чтобы я мог более-менее уверенно сказать, что я программирую на каком-то языке или использую платформу.
P.S. Справедливости ради: пишу код чуть меньше 10 лет. Пробовал много разных языков и видел много разных людей. Видел людей, способных через пару дней «слепить» на чём-то новом, да и сам таким, вроде бы, являюсь, но чтобы можно было уверенно сказать, что «программирую» это разве что какие-то уникумы) на качественное освоение возможностей языка и окружения уходят месяцы, годы. Так что всё у вас с этим в порядке, вы просто обладаете здоровым уровнем самокритичности)
В TS однозначно лучше организованы подсказки типов в интерфейсах функций, чем это сделано в JS (их там вообще нет). Я полагаю, что положительные моменты из TS так и будут продолжать перетекать в JS. Возможно, перетекут и указания типов входных-выходных параметров (вряд ли как гарантия, скорее, как ожидание). Если добавят ожидание типов входных-выходных аргументов на уровне языка, то вот и база для того, чтобы рефлексия в JS стала более информативной. Этого уже хватит, чтобы появился DI, основанный на свойствах самого языка (и их рефлексии), а не на придуманных конструкциях типа проксированного spec'а. А если добавят в язык ещё и пространства имён (JS долгое время не предполагался быть языком для написания приложений с обширной кодовой базой - до появления npm в 2010-м так уж точно), то можно будет выкинуть Zend1-like наименования классов (в TS пространства имён есть).
Т.е., в JS появится "стандартный DI", принимаемый всем сообществом, а не поделки типа моей. Я самоуверенно предполагаю, что не будет являться большой проблемой перевести мой код с использования одного DI-контейнера на использование другого. Ведь в чём основная фишка DI'я? Код, которым оперирует контейнер, не должен ничего знать о самом контейнере. Это просто обычные es6-модули, который могут импортиться вручную. Или через мой DI. Или через любой другой DI. Нужно будет добавить трансляцию типов из одной "системы счисления" (Zend1-like) в другую (какая будет). Ну а если ничего такого не появится, то я так и буду пользоваться сам своими инструментами. Это просто такой способ организации кода в рамках отдельного проекта. Или группы проектов. Это не "универсальная отмычка", а спец. инструмент для выполнения определённой работы - создания PWA.
Ходят слухи, что container.get (т.е. сервис локация) — это антипаттерн, за который обычно по рукам бьют))) А красивый DI с блекджеком и автовайрингом в JS не запилить по той причине что это JS. Вот и не тащат контейнер во фронтэнд особо, да и реализаций нормальных нет.
Да, есть такие слухи. Я даже как-то эту мысль катал туда-сюда. Вы старайтесь не использовать container.get() вне composition root и уменьшите негативное влияние этого "антипаттерна" на ваше приложение. И останется только позитивное ;)
Мне не нужен "красивый DI", мне достаточно того, который у меня есть. Он не красив, но мне нужно, чтобы он работал - и он работает. Несмотря на то, что это JS.
@teqfw/vue