я ещё не видел ни одной архитектуры которая себя одинаково показывала бы хорошо и на маленьких масштабах
вот как раз в моле оно одинаково хорошо и для того и для другого
никогда бы не взял это на простенький сайт, выглядит до жути громоздко,
минимальный компонент можно в 1 строку записать для сайта нужен файл входной index.html это же немного совсем, тут скорее непривычно
а для крупного проекта в $mol критически много чего не хватает для удобной и быстрой разработки.
например ? мне хватает ;) например для такого https://bot.giper.dev/ ( тут экосистема продуктов )
на счёт компонентов - да, на бумаге прикольная фича, но уже давно появились какие-нибудь shadcn которые так же легко редактируются и переписываются под свои нужды в своём проекте, что закрывает почти все потребности
это далеко не тоже самое что компоненты в моле shadcn это копипаста - по сути легаси с первого дня разработки в моле же композиция по умолчанию, максимальная гибкость, которой нет больше нигде
$mol даже лучше подходит для enterprise, у него переиспользование кода возведено в абсолют, можно не только стили изменить, но и отображение и даже логику, максимально гибко
Поддерживаются фрактальные монополирепозитории, т.е удобно как пилить монолит так и микрофронты
Причем по умолчанию сделано что то типа lerna, только гораздо удобнее и практичнее - на обычных .git репозиториях, к примеру я могу просто по имени класса взять его к себе в приложение ( всё поменять ) взять его из другого репозитория, при этом не нужно писать ни одного импорта
Там очень много отличных технических решений основанных на техническом анализе проблем и всего фронтенда в частности. Это лучшее решение для такой "простой" и полностью изученной области как фронтенд
Сначала сложновато конечно изучить, но когда понимаешь что сделано и как и какие возможности это даёт просто не устаешь удивляться
Что значит архитектура лучше подходит проекту ? В $mol вся разница будет в количестве компонент, но получится даже гибче и переиспользуемее ( я могу использовать компоненты из других чужих репозиториев в своих проектах по имени, при этом менять не только стили, но и логику и то что компонент рендерит )
Вообще по расположению файлов есть отличная аналитика
Бред полнейший
Делайте нормальный бэк, и будет вам счастье и не надо будет никаких bff придумывать ненужных
вот как раз в моле оно одинаково хорошо и для того и для другого
минимальный компонент можно в 1 строку записать
для сайта нужен файл входной index.html
это же немного совсем, тут скорее непривычно
например ? мне хватает ;) например для такого https://bot.giper.dev/ ( тут экосистема продуктов )
это далеко не тоже самое что компоненты в моле
shadcn это копипаста - по сути легаси с первого дня разработки
в моле же композиция по умолчанию, максимальная гибкость, которой нет больше нигде
о них интересно написано тут
https://habr.com/ru/articles/341146/
и тут https://mol.hyoo.ru/#!section=docs/=cx1tyu_aduyqj
$mol даже лучше подходит для enterprise, у него переиспользование кода возведено в абсолют, можно не только стили изменить, но и отображение и даже логику, максимально гибко
Поддерживаются фрактальные монополирепозитории, т.е удобно как пилить монолит так и микрофронты
Причем по умолчанию сделано что то типа lerna, только гораздо удобнее и практичнее - на обычных .git репозиториях, к примеру я могу просто по имени класса взять его к себе в приложение ( всё поменять ) взять его из другого репозитория, при этом не нужно писать ни одного импорта
Там очень много отличных технических решений основанных на техническом анализе проблем и всего фронтенда в частности. Это лучшее решение для такой "простой" и полностью изученной области как фронтенд
Сначала сложновато конечно изучить, но когда понимаешь что сделано и как и какие возможности это даёт просто не устаешь удивляться
С изучением могу помочь, бесплатно конечно же
Звучит как шутка :)
А если серьезно, лучше всего все эти проблемы решены в $mol'e, крайне советую ознакомиться
https://mol.hyoo.ru/#!section=docs/=u3t8nj_4kinwo
Первые три комментария в ветке без хамства
Логи на проде ? Не знал что есть
Что значит архитектура лучше подходит проекту ? В $mol вся разница будет в количестве компонент, но получится даже гибче и переиспользуемее ( я могу использовать компоненты из других чужих репозиториев в своих проектах по имени, при этом менять не только стили, но и логику и то что компонент рендерит )
Вообще по расположению файлов есть отличная аналитика
https://mol.hyoo.ru/#!section=docs/=nekayw_7ibj8f
прикольно, очень много игр
Читая статью о другой технологии, ты не в гостях, что за бред...
Человек просто высказал мнение, а вы начали докапываться
Нет, кросспост
Дима придумал использовать эмодзи ещё до ллм)
Да и у него явный стиль читается
Уберите рекрутеров, пожалуйста
https://habr.com/ru/articles/1025378/
Они вам всю малину и портят
ага
свободы воли например точно нет
а ты докажи)
Ок
Вот это и плохо что у вас по разному
Мне вот очень нравится как в $mol придумали
Там название класса строго равно пути в файловой системе
Допустим прилетает инц с прода
Сломался компонент
$mol_bigtechcompany_srm_slider
И я сразу понимаю что он лежит по пути mol/bigtechcompany/srm/slider/ и в этой папке три файла
slider.view.ts ( логика )
slider.view.tree ( декларативное описание компонента без привязки к html )
slider.view.css.ts ( типизированные стили каскадные )
отличная статья!
"ии" воспроизводит то же самое поведение hr
и увеличивает стигматизацию
Как на этом можно зарабатывать когда есть куча мессенджеров где можно звонить бесплатно
Посмотрите как в $mol реализовано реактивное програмирование
Как раз решены описанные вами проблемы
И опять удобная фраза "не серебряная пуля"...
Хватит жрать кактус
https://habr.com/ru/articles/1018288/#silver-bullet
Пора уже проблемы реально решать