cmyser21 июн в 16:30

Что брать на новый проект: валидный дефолт (React) или гринфилд ($mol)

6 мин

12K

$mol * ReactJS * VueJS * Angular * Веб-разработка *

Мнение

Комментарии 52

NZT 21 июн в 18:01

Раз багов меньше, и времени на дебаг меньше. И сам дебаг проще: единый поток данных, без грязного состояния. В частности этих сложных багов как раз и меньше.

Абсолютно субъективное и ложное утверждение. Время на дебаг вообще не зависит от количества багов. То же относится и к сложности багов.

cmyser 21 июн в 18:23

как бы да, есть просто логические баги, которые можно долго выискивывать, особенно на стыке систем, но вот вот багов а-ля че то у нас экран не тот или поведение иногда после клика странное, вот такого меньше

cmyser 22 июн в 16:55

собственно, сегодня вот и пример нашелся
https://habr.com/ru/companies/tbank/articles/1048446/
такого бага, в моле не заложено архитектурно вообще

powerman 21 июн в 18:37

Главная проблема $mol в его авторе, точнее в его стиле коммуникации, отпугивающем большинство потенциальных новых пользователей. А у текущей статьи - в слишком высоком уровне абстракции, она не про конкретно $mol, а про любой новый фреймворк. Про особенности $mol там одна картинка про закрытые на уровне архитектуры баги, но вот как раз эту тему статья и не раскрывает.

cmyser 21 июн в 18:38

точно, надо бы ссылку в статью добавить
тут https://habr.com/ru/articles/1044684/ разбор как раз

в статью тоже добавил, спасибо

Kenya-West 21 июн в 18:51

Понятно, что статья про выбор $mol, но я просто выбрал бы, к чему душа лежит ближе - Angular. Возможно, в составе с Analog. Давно уже мета-фреймворки появились: Vue + NUXT, React + Next, Angular + Analog. У Svelte что-то даже было...

А $mol... Если есть llms.txt или годный скилл для невронок, то почему бы и нет? У меня куча идей для проектов, я не против попробовать что-то новое, благо этот фреймворк уже больше 10 лет присутствует на Хабре. Сегодня у меня хорошее настроение, можно и на $mol его потратить!

cmyser 21 июн в 20:12

оооо! здорово! если какие вопросы будут пиши к нам в @giper_dev
подумаем над мета фреймворком для мола!

а скил, вот он ! npx skills add b-on-g/mol_skill --all -g

900k 21 июн в 20:33

А $mol позиционируется как enterprise framework или что-то нишевое?

cmyser 21 июн в 22:01

для всех https://mol.hyoo.ru/#!section=docs/=j0mafl_shvwnd
для мелких задач в принципе и так всё что угодно подходит, для больших уже нужно что то грамотное под капотом
наверное больше как enterprise тогда всё же

artptr86 21 июн в 21:53

Дима: «может, дело в том, что DSL плохой и неудобный?»
DSL это грамотное техническое решение: пишешь меньше кода, получаешь больше. JSX тоже когда-то был таким решением, просто, очевидно, не лучшим.

Здесь вы уходите от ответа. Вас не спрашивают, хорошо или плохо было использовать DSL. Вас спрашивают: мог ли $mol быть успешнее, если бы его DSL был другим.

Дима: «выбранная Карловским стратегия продвижения… однозначно свидетельствует о том, что все проблемы… решены не будут никогда».
Да, нужен маркетолог, который бы помог это продвигать.

А что, если маркетолог предложит вам поменять какую-либо из концепций? Например, минимально предложит перейти от синтаксически значимых отступов (как в CoffeeScript, HAML, Pug) к более привычному синтаксису на основе разделителей (как в TypeScript). Насколько сильным будет сопротивление вашего комьюнити? А если это с большой вероятностью увеличит заинтересованность разработчиков?

cmyser 21 июн в 22:15

мог ли $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 с заинтересованностью подскочит

мы вот сейчас как раз заняты переписыванием сборщика, может там что то и сделаем ( или хотя бы сделаем возможность, для гибкой подмены )

artptr86 22 июн в 02:22

Так какую же выгоду дают синтаксически значимые отступы?

cmyser 22 июн в 05:33

ровно такую же, как и в python

Скобочки бы усложнили чтение

artptr86 22 июн в 10:46

Почему-то в си-подобных языках, в том числе и в базовых фронтенд-языках JavaScript, TypeScript, используется именно скобочный синтаксис, тогда как тренд на синтаксические отступы не прижился. Мне кажется, что вашим стараниям по продвижению фреймворка мешает ваша же оголтелая субъективщина. Тем более, как я уже упоминал когда-то в комментариях, в обосновании преимуществ формата tree была логическая ошибка сведения к частному: «Если какое-то решение эффективно в общем случае, значит оно эффективно и в частном», что, разумеется, неверно.

Тем более, сравнение DSL идёт только с уже существующими решениями, хотя можно было бы рассмотреть какие-то гибридные или аналогичные решения типа языка шаблонов Angular или Vue, либо что-то типа описания интерфейсов Jetpack / Swift.

Вся странность вынесена в первые пять минут (view.tree, $-неймспейс, MAM), а выгоды накапливаются месяцами. Профиль «затраты сейчас, выигрыш потом» — худший для adoption; у React ровно обратный.

Но это как раз сильно мешает продвижению, потому что мало кто хочет тратить столько усилий на понимание формата для фреймворка, преимуществ работы с которым они ещё не поняли. Большинство разработчиков хотят словить хайп, а вы их в каких-то китайских письменах заставляете разбираться. Так у вас популярности никогда не будет.

cmyser 22 июн в 16:53

«Если какое-то решение эффективно в общем случае, значит оно эффективно и в частном»,

в каком общем случае view.tree эффективен, а в каком частном - нет ?
сравнения есть тут https://github.com/hyoo-ru/mam_mol/wiki/View-Formats

это как раз сильно мешает продвижению

да, так и есть. но изменять его - только портить, что с "{}" что с чем то другим, сейчас максимально компактно получается, портить не хочется

возможно тут есть какое то решение
поддержать "вторую" версию view.tree с другим синтаксисом но с полной обратной совместимостью , например , надо подумать

залетай к нам в @giper_dev , подумаем вместе, может что и сделаем

artptr86 22 июн в 17:02

в каком общем случае view.tree эффективен, а в каком частном - нет ?

Нет. В качестве наиболее эффективного формата для структурированных документов был провозглашён tree, а затем на его основе был построен view.tree, который якобы настолько же эффективен в частном случае — шаблоны компонентов.

что с "{}" что с чем то другим, сейчас максимально компактно получается, портить не хочется

Людям не нужна максимальная компактность, иногда некоторая избыточность, наоборот, помогает. Формат tree же не рассчитан как таковой на человека, а скорее на лёгкое написание однопроходного парсера.

залетай к нам в @giper_dev , подумаем вместе, может что и сделаем

Хабр — не место для дискуссий?

cmyser 22 июн в 17:10

можно и тут, но в догосрок было бы здорово в чатике

теперь понял, надо думать, тут я , если честно не могу грамотный ответ дать

@nin-jin помоги ответить плиз

от нейронки вот такой ответик

artptr86 22 июн в 17:14

Ты предлагаешь спорить с нейронкой, которая даже первую мысль не поняла?

cmyser 22 июн в 17:17

нет, не предлагаю

nin-jin 23 июн в 08:48

Формат tree появился в процессе проектирования языка view.tree. Это разные уровни абстракции, не сравнимые между собой.

OstapIbragimovich 23 июн в 06:16

Странно слышать, про то, что тренд на синтаксические отступы не прижился. Python так и не собирается умирать, как и yaml конфиги, которые каждый день читают и пишут сотни админов и devops'ов. То, что популярность js/ts взлетела до небес, а первые языки использовали разделители по техническим причинам - потому что так проще анализировать код и компилировать - не значит, что синтаксис с отступами чем-то плох. Наоборот, он более человеко-читаемый, создает меньшую когнитивную нагрузку на человека.

cmyser 23 июн в 06:19

❤️❤️❤️

artptr86 23 июн в 06:47

Речь как бы про фронтенд, а в среде фронтендеров тренд этот не прижился.

OstapIbragimovich 23 июн в 06:54

Вспомните, что когда ваш фронтэнд летит по пайплайну на прод, где-то сидят и тихонечко молятся devops'ы...

artptr86 23 июн в 07:00

Молятся как бы их кучка сконкатенированных ямлов не рухнула на проде из-за Норвегии?

cmyser 23 июн в 07:21

да кстати в ямл есть проблемы
описаны тут https://habr.com/ru/articles/503240/

OstapIbragimovich 23 июн в 08:39

Главная проблема популярных фреймворков для фронтэнда - это тяжелый легаси, который годами трансформируется и ничем не лучше любого легаси в крупном энтерпрайзе. Это большие неповоротливые машины, как в "Хрониках хищных городов", которые все время куда-то движутся и модернизируются на ходу, причем мало кто помнит с чего все начиналось и почему здесь сделано так, а не по-другому. Так же очень похожа на "хищные города" традиция собирать приложения из npm-мусора, часто вопреки здравому смыслу используя зависимость вместо 2х строк кода. JS по сути своей такой же тяжелый энтерпрайз легаси, который был разработан за 10 дней под веселым названием Mocha и был встроен в Netscape Navigator, и с тех пор так никто и не решился выпилить его из браузеров несмотря на кучу альтернатив.

OstapIbragimovich 23 июн в 09:29

Я читал статью про tree и не в восторге. Если расставлять по удобочитаемости, то я поставил бы tree ближе к концу, куда-то между yaml и сырым json. А XML (и как частный случай HTML), несмотря на продуманность, можно изуродвать атрибутами так, что первый взгляд на документ будет вызывать желание немедленно его закрыть. Кажется еще лет 15 назад мудрые разрабы всякого возвышенного софта для предприятий решили, что XML - не для людей язык, а для приложений и нечего его пытаться читать глазами. Tree прост и понятен, как абстрактный конь в вакууме - “вот вакуум, вот конь и … с конем как хотите”. Но по факту иногда простота хуже воровства. TOML - попытка немного улушить разбиение больших конфигов на секции без использования комментариев, чего не хватает, например, в yaml, поэтому я его не презираю, тем более что он стал стандартом в не которых областях.

cmyser 23 июн в 10:10

а какой формат нравится вам ?

OstapIbragimovich 23 июн в 08:27

Скорее, чтобы ресурсов хватило на новые фичи и пайплайн не сломался из-за новых зависимостей.

artptr86 23 июн в 08:32

Это не входит в область ответственности devops.

OstapIbragimovich 23 июн в 08:57

А что еще не входит в зону ответственности DevOps и в чью тогда зону ответственности входит следить, чтобы пайпланы запускались, а новые вересии деплоились куда надо?

artptr86 23 июн в 09:00

Если пайплайн внезапно сломался из-за новой фичи или зависимости — виноват фронтендер.

OstapIbragimovich 23 июн в 09:22

Если это было так, девопсы бы 99% своего времени пили смузи с пивом и рассуждали о высоких материяах... К сожалению, в жизни не все так просто, особенно в гетерогенных средах, которых в энтерпрайзе и госструктурах ну очень много, и приходится что-то докручивать ручками... Но если вы работаете с китами типа Амазона, Гугля или Микрософт, то да, тут всегда виноват фронтэндер и фиг вы чего докажете им...

artptr86 23 июн в 09:27

Значит виноваты архитекторы и менеджеры, которые довели продукт до такого состояния. Не зря стараются разделить компоненты, чтобы они собирались (и, в идеале, доставлялись) независимо друг от друга.

OstapIbragimovich 23 июн в 09:34

Советую вам когда-нибудь подойти к архитектору или менеджеру и прилюдно объявить ему что он виноват в чем-то. Будет интересно почитать, как будут развиваться события... Хотя это бессмысленно. О проблеме узнают и дергаться начнут сначала все равно девопсы, которым сообщат дежурные админы, которых возможно к моменту инцидента уже взбодрит поддержка и только потом все это дойдет до разрабов, которые, кончено, первыми получат по шапке, и может быть история дойдет и до архитектора/менеджера, если последствия окажутся реально серьезными.

artptr86 23 июн в 09:45

Советую вам когда-нибудь подойти к архитектору или менеджеру и прилюдно объявить ему что он виноват в чем-то. Будет интересно почитать, как будут развиваться события...

И как это отменяет их степень вины?

О проблеме узнают и дергаться начнут сначала все равно девопсы, которым сообщат дежурные админы, которых возможно к моменту инцидента уже взбодрит поддержка и только потом все это дойдет до разрабов, которые, кончено, первыми получат по шапке, и может быть история дойдет и до архитектора/менеджера, если последствия окажутся реально серьезными.

Ну то есть проблема не только на техническом, но и на организационном уровне. Но если это гос или крупный энтерпрайз — ничего удивительного.

И мы же обсуждали, что проблема была в пайплайне? Но если он упал, то до прода ничего дойти не должно. А если он собрал приложение криво, то где тесты, которые должны просигналить о проблеме раньше, чем произойдёт доставка?

cmyser 23 июн в 07:17

дело привычки, мне кажется
да и законом не запрещено "прижится" ;)

Amigun 23 июн в 09:32

Почему-то в си-подобных языках, в том числе и в базовых фронтенд-языках JavaScript, TypeScript, используется именно скобочный синтаксис

И почему же?

вашим стараниям по продвижению фреймворка мешает ваша же оголтелая субъективщина

А ваша?

Но это как раз сильно мешает продвижению, потому что мало кто хочет тратить столько усилий на понимание формата для фреймворка, преимуществ работы с которым они ещё не поняли. Большинство разработчиков хотят словить хайп, а вы их в каких-то китайских письменах заставляете разбираться. Так у вас популярности никогда не будет.

Лучше быть непопулярными, чем прогибаться под привычки других, осообенно под привычки, которые не дают ничего полезного, а часто и наоборот вредят.

Если разработчик не в состоянии уделить немного времени, чтобы разобраться в простейшем синтаксисе, то, ну, что сказать, хех, пусть пишет себе дальше на реакте, рано ему еще в $mol, не дорос.

artptr86 23 июн в 10:11

Лучше быть непопулярными, чем прогибаться под привычки других, осообенно под привычки, которые не дают ничего полезного, а часто и наоборот вредят.

Так вам никто не запрещает писать на чём вы хотите. Но это же вы приходите к остальным со своей истинной верой.

Если разработчик не в состоянии уделить немного времени, чтобы разобраться в простейшем синтаксисе, то, ну, что сказать, хех, пусть пишет себе дальше на реакте, рано ему еще в $mol, не дорос.

Вы бы, наверное, тоже отказались, если бы вам навязывали писать на PHP вместо Python, хотя оба Тьюринг-полные языки.

cmyser 23 июн в 10:30

Так вам никто не запрещает писать на чём вы хотите. Но это же вы приходите к остальным со своей истинной верой.

вот да, этот подход неправильный, и часто вызывает хейт а не потребность разобраться

с другой стороны, а как другие пиарятся ? тоже ведь за счет преимуществ

сложно это всё

Amigun 23 июн в 10:36

Вы бы, наверное, тоже отказались, если бы вам навязывали писать на PHP вместо Python, хотя оба Тьюринг-полные языки.

~~учитывая вектор развития Python, не грех и на PHP посмотреть…~~. Если бы мне показали что-нибудь лучше, чем мой привычный инструмент, привели примеры проблем моего основного инструмента и как их решает “навязываемый” инструмент, то не вижу причин не попробовать, вдруг и правда лучше? Как минимум - расширить кругозор, а в хорошем случае - посмотреть какие есть хорошие решения и попробовать применить их у себя, не обязательно переходить на новый инструмент, особенно если для тебя важно наличие вакансий, а их нет.

Надо лишь отбросить принципиальность и, в контексте $mol, предвзятое отношение к автору. По вашему или чьему-либо еще мнению он может быть токсиком вселенского масштаба, но это не влияет на технические характеристики его фреймворка.

vorant 22 июн в 06:21

Обожаю читать статьи про этот фреймворк. Читать статьи нет смысла, а вот в комментариях мне всегда весело)

cmyser 22 июн в 06:23

Рад уже этому!)

FranzSPb 22 июн в 07:48

Кирилл, прекрати тратить свое драгоценное время на этот мертвый проект, он не взлетит. Синтаксис ужасный, вам никогда не преодолеть сопротивление разработчиков, это другой язык, никто не будет учить язык просто чтобы посмотреть что там Карловский навыдумывал, что бы ты ни писал про его удобство. Ваши все демонстрационные страницы выглядят ужасно, как будто дед на колентке напрограммировал. Ваша виртуализация не позволяет тянуть за скролл, вам пишут об этом в каждой статье, и в каждой статье вы (в лице Карловского) огрызаетесь, вместо того чтобы это исправить. $mol хороший пет-проект Карловского, Карловский талантлевый, если не гениальный, программист, но плохой продакт, кто-то наверняка подсмотрел или подсмотрит там что-то для своих нормальных фреймворков, но этот не взлетит

cmyser 22 июн в 08:05

Спасибо за критику, скрол да, нужно починить обязательно

По дизайну тоже согласен. Я например вот такую штуку сделал https://b-on-g.github.io/builderui/base=stone/theme=violet/chart=green/font_body=eb-garamond/font_head=dm-sans/radius=medium для создания различных дизайнов и быстрого использования у себя

Я считаю что у проекта очень очень много преимуществ, которые нужны индустрии, поэтому я и хочу вкладывать в это усилия и время