Комментарии 21
Наконец-то появилась поддержка тайпскрипт. Помню много раз наталкивался на $mol и каждый раз меня отталкивал доморощенный синтаксис. Похоже пришло время опробовать и сделать что-то простенькое, а то на рынке фреймвёрков натуральный голод.
"синтаксис" всё-таки никуда не делся, но компоненты можно без него создавать на чистом ts. Правда тогда придется решать задачи вручную, которые решает view.tree. В нем нет ничего сложного, через одну статью он будет подробно разбираться. Сложность только в том, что он не похож ни на что, к чему мы уже привыкли, это как первый раз увидеть html. Он такой не просто так, т.к. проектировался под конкретные задачи.
Vintage в треде, я спокоен
Привет всем домотавшим (дочитавшим) до этого места. Я сдался на 40% статьи, зато я очень уважаю теперь тех, кто использует MAM
Почему был выбран сиподобный стиль названия методов фреймворка? Смотрится дико
Изначально snake_case был выбран только для написания FQN-имен, потому что знаки подчеркивания имеют наибольшую поддержку среди языков, а это нужно чтобы имена одной сущности везде писались одинаково (html, css, js/ts, ... ). Но когда к нему привыкаешь, начинает казаться, что он удобнее CamelCase, имхо. Вообщем теперь он используется везде, но кое-где еще можно найти CamelCase в коде который давно не трогали.
Статья очень большая, еле дочитал. В ходе прочтения складывается впечатление, что MAM революционно меняет систему работы с модулями, выкидывая традиционный import на свалку. Новая система очень напоминает систему работы с модулями в PHP (а именно PSR-4), которая является скорее костылём, чем намеренно созданной системой. Революционная смена подхода имеет недостатки (именно смена, а не новый подход):
Инструменты разработки не умеют работать с новой системой. Это, например, лишает IDE магии автокомплита и рефакторинга. Насколько я понимаю, есть плагин для VSCode, но это не единственная IDE, и в целом получается ситуация «по умолчанию не работает».
Новый подход контринтуитивен для разработчиков, что является препятствием для входа в проект. Насколько я понимаю, MAM не трудно освоить, но в некоторых проектах может быть недостаточно мотивации для этого, например, когда кто-то хочет помочь проекту с открытым исходным кодом.
Проект становится заложником MAM, потому что только он поддерживает новый подход.
Нужна очень большая причина, чтобы принять недостатки, описанные выше. Я не вижу такой в статье. Все описанные возможности можно реализовать с имеющейся системой модулей, встроенной в JavaScript. Не хватает описания юз-кейсов, в которых MAM делает жизнь проще (чем с обычным import и другими фреймворками). В целом статья выглядит как документация, то есть описание возможностей, а не решаемых проблем.
Из статьи не понятно, почему новички в JavaScript должны изучать и использовать систему модулей MAM, а не import/export, которую использует вся остальная экосистема.
Не понятно, зачем упоминается $mol. Про него было бы интересно почитать. Если MAM является необходимым условием для использования $mol, то он должен быть ну очень хорош, чтобы оправдать смену корневой парадигмы.
Я имею ввиду не обращение к свойствам объекта. Я имею ввиду автоматический импорт переменных по их имени. Например, если в этом примере:
Пример
"use strict";
class $my_foo {
get bar() {
return new $my_bar();
}
}
//my/foo/foo.ts
;
"use strict";
class $my_bar extends $my_foo {
}
//my/bar/bar.ts
;
"use strict";
console.log(new $my_foo().bar);
//my/app/app.tsЧто будет, если в IDE кликнуть на последний $my_foo, удерживая кнопку Cmd? Подсветит ли IDE ошибку TS, если я напишу new $my_foo().baz? Сделает ли это WebStorm? Jump to definition на GitHub, думаю, тоже не поддерживается.
Да, это документация, точнее обучалка, которая последовательно вводит в $mol. Первое с чем надо разобраться - MAM.
Наверно, я не правильно акцентировал внимание на FQN. Все таки избавление от импортов не самоцель, возможно в будущем они будут использоваться.
Плагин в VSCode нужен для подсветки синтаксиса tree языков. Автокомплит, рефакторинг работают с typescript кодом. (покрайней мере с VSCode проблем не должно быть, на другие редакторы пока нет ресурсов)
Я бы сказал не "контринтуитивен", а "не привычен". Не думаю, что нужно много времени чтобы разобраться и привыкнуть. Только дело в желании.
Большой проект и с webpack можеть быть сложно на что-нибудь другое перевести. Если подумать про переход с MAM, только нужно сгенерировать импорты/экспорты скриптом, все пути содержаться в FQN-именах.
MAM больше про стандартизацию, про искусственные ограничения, которые создают такие рамки, чтобы без усисилий получался хорошо огранизованный, переиспользуемый код. Противополжность этому - полная свобода, когда разработчик может сделать так, как ему захочется. И наверно $mol целиком этой темой пропитан, про ограничения упрощающие разработку.
Для примера, можно сравнить вынос части кода проекта в отдельный репозиторий, например с nx - система которая позволяет почти полную свободу внутри кода.
Туториал большой, я бы даже на несколько его разбил, но где ссылки на документацию?
Именно по MAM, документации нет, только статья MAM: сборка фронтенда без боли. Ссылаться пока некуда.
В $mol документация есть, у каждого модуля она своя, находится в файле readme.md в директории модуля. Пример. На сайте пока ее нет, и не у всех модулей она есть, которым нужна. Но в целом, все не так плохо с этим, особенно если учесть то, что у большинства модулей кода не много и он простой.
Молу не хватает не документации, а именно обучалки, которая последовательно знакомит со всем необходимым. Эта статья и есть первая часть этой обучалки, позже она будет на сайте мола.
Инструмент по идее должен облегчить работу программиста. А здесь сплошное усложеение. Скажите, в чём преимущество данного инструмента. Вот есть у меня vue к примеру. И я подобное реализую намного меньшими усилиями.
Вы рассказали о преимуществах, интересно какие есть компромиссы и ограничения.
Был-ли опыт миграции с Webpack и с какими особенностями приходилось сталкиваться? Может есть цифры, было бы интересно увидеть сравнение по времени сборки (холодной и инкрементальной если поддерживаете), размеры бандлов на выходе, объём необходимого рефакторинга существующего кода, особенности интеграции с другими инструментами (статические анализаторы кода, hot-reload, поддержка в популярных IDE).
Напомнило https://github.com/enb/enb, который Яндекс пиарил на всех конференциях много лет тому назад.
Цели рассказать о преимуществах не было, только немного теории в виде идей/концепций и побольше практики, чтобы тот у кого есть желание смог разобраться.
По сложностям, например MAM генерирует заранее заданные бандлы, если например разрабатывается расширение для браузера, могут быть сложности, т.к. там может быть несколько точек входа дляhtml , скриптов и т.п. Придется либо как-то внутри кода выкручиваться, либо расширять MAM.
Также MAM хоть и вырос вместе с $mol, и заточен под него и под веб, но можно разрабатывать бекенд на js, и в теории на других языках, но нужно делать поддержку.
Еще не разлизованы некоторые возможности, например используется безверсионированная схема, но у разработчика нет автообновления, т.е. репозитории и NPM-пакеты надо обновлять вручную. Но хотябы на CI при деплои скачиваются свежие версии.
Код NPM-пакетов, лучше собирать чем-нибудь заточенным под него, что умеет в тришейкинг, вырезание всяких process.env.NODE_ENV и т.п. Сейчас MAM-сборщик их собирает.
Еще не решенная проблема, с дублированием кода в NPM-пакетах. Если выложить несколько пакетов, у которых есть общий код, он будет продублирован в каждом. При использовании нескольких таких пакетов в NPM-приложении, будет увеличен его размер.
Код MAM разросся, сложно быстро въехать чтобы что-то поправить. Новая версия начата, но пока некому доделывать.
Миграцию веб-приложений с webpack врядли кто-то делал, но думаю для сколько-нибудь большого проекта это будет трудоемко. Надо удалять импорты/экспорты, имена переделывать на FQN, а после наверно еще придется рефакторить расположение файлов, т.к. имена не понравятся. Придется делать адаптеры для всех используемых в проекте NPM-пакетов, а также скорее всего придется кодовую базу обновлять под последние версии этих пакетов (если полноценно использовать verless).
Сравнений с другими сборщиками нет, думаю пока используется старая версия нет смысла делать. Инкрементальная сборка есть, там сборщик реактивный, в том плане что используется таже реактивная система из $mol. После обработки файл кешируется, при изменении файла - кеш сбрасывается и т.д.
В некоторой степени $mol/MAM - это развитие идей классического БЭМ стека.
можете расписать преимущества/недостатки $mol vs svelte kit?
особенно интересно сравнение размера/скорости, потому что оба фреймворка активно рекламируют себя именно малым размером и быстрой скоростью
Введение в $mol. Часть 1. Модульная система