Хабр Курсы для фронтендеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Фронтенд доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 17
Раз багов меньше, и времени на дебаг меньше. И сам дебаг проще: единый поток данных, без грязного состояния. В частности этих сложных багов как раз и меньше.
Абсолютно субъективное и ложное утверждение. Время на дебаг вообще не зависит от количества багов. То же относится и к сложности багов.
Главная проблема $mol в его авторе, точнее в его стиле коммуникации, отпугивающем большинство потенциальных новых пользователей. А у текущей статьи - в слишком высоком уровне абстракции, она не про конкретно $mol, а про любой новый фреймворк. Про особенности $mol там одна картинка про закрытые на уровне архитектуры баги, но вот как раз эту тему статья и не раскрывает.
точно, надо бы ссылку в статью добавить
тут https://habr.com/ru/articles/1044684/ разбор как раз
в статью тоже добавил, спасибо
Понятно, что статья про выбор $mol, но я просто выбрал бы, к чему душа лежит ближе - Angular. Возможно, в составе с Analog. Давно уже мета-фреймворки появились: Vue + NUXT, React + Next, Angular + Analog. У Svelte что-то даже было...
А $mol... Если есть llms.txt или годный скилл для невронок, то почему бы и нет? У меня куча идей для проектов, я не против попробовать что-то новое, благо этот фреймворк уже больше 10 лет присутствует на Хабре. Сегодня у меня хорошее настроение, можно и на $mol его потратить!
оооо! здорово! если какие вопросы будут пиши к нам в @giper_dev
подумаем над мета фреймворком для мола!
а скил, вот он ! npx skills add b-on-g/mol_skill --all -g
А $mol позиционируется как enterprise framework или что-то нишевое?
для всех https://mol.hyoo.ru/#!section=docs/=j0mafl_shvwnd
для мелких задач в принципе и так всё что угодно подходит, для больших уже нужно что то грамотное под капотом
наверное больше как enterprise тогда всё же
Дима: «может, дело в том, что DSL плохой и неудобный?»
DSL это грамотное техническое решение: пишешь меньше кода, получаешь больше. JSX тоже когда-то был таким решением, просто, очевидно, не лучшим.
Здесь вы уходите от ответа. Вас не спрашивают, хорошо или плохо было использовать DSL. Вас спрашивают: мог ли $mol быть успешнее, если бы его DSL был другим.
Дима: «выбранная Карловским стратегия продвижения… однозначно свидетельствует о том, что все проблемы… решены не будут никогда».
Да, нужен маркетолог, который бы помог это продвигать.
А что, если маркетолог предложит вам поменять какую-либо из концепций? Например, минимально предложит перейти от синтаксически значимых отступов (как в CoffeeScript, HAML, Pug) к более привычному синтаксису на основе разделителей (как в TypeScript). Насколько сильным будет сопротивление вашего комьюнити? А если это с большой вероятностью увеличит заинтересованность разработчиков?
мог ли $mol быть успешнее, если бы его DSL был другим.
Врядли, дело далеко не только в dsl ( хоть и dsl я считаю хорошим решением )
вот тут разбор https://mol.hyoo.ru/#!section=docs/=gf3a0a_5koj1m
Изначально может показаться, что использовать более привычный синтаксис предпочтительнее. Однако, пытаясь впихнуть в него такие штуки, на которые он не был рассчитан, получается даже хуже, чем изобрести новый, заточенный на конкретную задачу, синтаксис, ибо старые привычки бесполезны и только мешают понять новые концепции, для которых старый синтаксис используется не по назначению, вызывая когнитивный диссонанс.Новый же, консистентный синтаксис, где нет ничего лишнего, но есть всё необходимое, не смотря на свою необычность, изучается куда быстрее даже с нуля, ведь он не тянет за собой атавизмы от прошлых этапов эволюции
к более привычному синтаксису на основе разделителей (как в TypeScript)
По типу такого ?
$bog_smalljs_app $mol_view {
{ section? \home }
sub /{
<= Top $bog_smalljs_top
Theme <= Theme $bog_theme_auto
theme_light \$mol_theme_calm_light
theme_dark \$mol_theme_calm_dark
themes /
\$mol_theme_calm_light
\$mol_theme_calm_dark
<= Body $mol_view
sub <= body_content /
}
plugins / {
<= Theme
}
Landing $bog_smalljs_landing
Docs $bog_smalljs_docs
Playground $bog_smalljs_playground
}Не думаю что есть смысл
все равно этот view.tree преобразуется в самый обычный js
т.е это просто более удобное представление js классов ( которые можно написать и руками, но никто этого не захочет ) плюсом он дает много преимуществ
Я вот для себя такую мысль выделил
Вся странность вынесена в первые пять минут (view.tree, $-неймспейс, MAM), а выгоды накапливаются месяцами. Профиль «затраты сейчас, выигрыш потом» — худший для adoption; у React ровно обратный.
Но стоит понять какие выгоды это даёт, и возвращаться назад к jsx уже не хочется
Сопротивления особого не будет, если сделать "второй вариант" написания view.tree при сохранении всех плюсов
Может быть и adoption с заинтересованностью подскочит
мы вот сейчас как раз заняты переписыванием сборщика, может там что то и сделаем ( или хотя бы сделаем возможность, для гибкой подмены )
Так какую же выгоду дают синтаксически значимые отступы?
ровно такую же, как и в python
Скобочки бы усложнили чтение
Почему-то в си-подобных языках, в том числе и в базовых фронтенд-языках JavaScript, TypeScript, используется именно скобочный синтаксис, тогда как тренд на синтаксические отступы не прижился. Мне кажется, что вашим стараниям по продвижению фреймворка мешает ваша же оголтелая субъективщина. Тем более, как я уже упоминал когда-то в комментариях, в обосновании преимуществ формата tree была логическая ошибка сведения к частному: «Если какое-то решение эффективно в общем случае, значит оно эффективно и в частном», что, разумеется, неверно.
Тем более, сравнение DSL идёт только с уже существующими решениями, хотя можно было бы рассмотреть какие-то гибридные или аналогичные решения типа языка шаблонов Angular или Vue, либо что-то типа описания интерфейсов Jetpack / Swift.
Вся странность вынесена в первые пять минут (view.tree, $-неймспейс, MAM), а выгоды накапливаются месяцами. Профиль «затраты сейчас, выигрыш потом» — худший для adoption; у React ровно обратный.
Но это как раз сильно мешает продвижению, потому что мало кто хочет тратить столько усилий на понимание формата для фреймворка, преимуществ работы с которым они ещё не поняли. Большинство разработчиков хотят словить хайп, а вы их в каких-то китайских письменах заставляете разбираться. Так у вас популярности никогда не будет.
Обожаю читать статьи про этот фреймворк. Читать статьи нет смысла, а вот в комментариях мне всегда весело)
Кирилл, прекрати тратить свое драгоценное время на этот мертвый проект, он не взлетит. Синтаксис ужасный, вам никогда не преодолеть сопротивление разработчиков, это другой язык, никто не будет учить язык просто чтобы посмотреть что там Карловский навыдумывал, что бы ты ни писал про его удобство. Ваши все демонстрационные страницы выглядят ужасно, как будто дед на колентке напрограммировал. Ваша виртуализация не позволяет тянуть за скролл, вам пишут об этом в каждой статье, и в каждой статье вы (в лице Карловского) огрызаетесь, вместо того чтобы это исправить. $mol хороший пет-проект Карловского, Карловский талантлевый, если не гениальный, программист, но плохой продакт, кто-то наверняка подсмотрел или подсмотрит там что-то для своих нормальных фреймворков, но этот не взлетит
Спасибо за критику, скрол да, нужно починить обязательно
По дизайну тоже согласен. Я например вот такую штуку сделал https://b-on-g.github.io/builderui/base=stone/theme=violet/chart=green/font_body=eb-garamond/font_head=dm-sans/radius=medium для создания различных дизайнов и быстрого использования у себя
Я считаю что у проекта очень очень много преимуществ, которые нужны индустрии, поэтому я и хочу вкладывать в это усилия и время
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Что брать на новый проект: валидный дефолт (React) или гринфилд ($mol)