Недавно под постом в канале MoscowJS разгорелся спор — со мной и организатором насчёт смола. Даже не столько насчёт смола, сколько в целом: стоит ли выбирать новые технологии или нет. Думаю, это касается не только смола, а любых новых фреймворков и библиотек.
Претензии вроде бы логичные:
Дима: «Никого не интересует, что туду-лист в смоле открывается на 120 мс быстрее. Никого не волнует, что бандл на 500 кб меньше. Это вообще рынку не интересно… никого не волнует, есть ли темы и интернационализация из коробки, бро».
И вроде бы можно согласиться. Но есть тут “лукавство”. Новые фреймворки и библиотеки выходят постоянно и каждый пытается что-то улучшить, упростить нам жизнь. Это не серебряная пуля, как любят говорить. Но за счёт чего достигается улучшение? За счёт того, что код переупакован в переиспользуемую форму.
Да и сам React был когда-то новым — его идеи, JSX тоже приняли не сразу.
Тут возникает парадокс. Чтобы технологию начали использовать в бизнесе, её сначала должны взять разработчики, должен появиться сетевой эффект, и какие-то небольшие тимлиды должны захотеть сделать новый проект на новой технологии. Отсюда и растёт стоимость онбординга.
Дима (что важно рынку): «сколько времени занимает онбординг».
Чем больше людей знают технологию, тем дешевле онбординг. Тут у нас выбор: опереться на уже готовых людей или вложить усилия в изучение нового. Сейчас эта цена кратно упала. Мало того что у нас и так нанимают разработчиков на Go с других языков, так ещё и выучить новый фреймворк стало кратно проще с появлением LLM. Пугать этим кого-то уже странно.
То есть онбординг не такой уж дорогой, особенно для специалиста с навыками. Поменять фреймворк несложно. Даже довольно просто.
Дима: «сколько людей на рынке смогут это поддерживать, если энтузиаст попадёт под автобус».
$mol сделан максимально простым, модульным, и собственно такие же приложения получаются на нём в любом случае. Для его изучения придётся смотреть готовые компоненты, и прелесть в том, что исходники всегда с тобой, ты работаешь буквально в одной папке вместе с ними. То есть если что-то интересно, нужно выполнить только [Go to Definition] и сразу перейти к настоящим исходникам.
Поддерживать же сможет практически любой. Для некоторых моментов конечно нужна более серьезная экспертиза, для таких как система реактивности, виртуализация, что-то глобальное короче. Но в целом несложно, да, разобраться можно будет.
А если что то не устраивает в компоненте можно поменять, как стили, так и шаблон, так и саму логику. А этого больше нигде нет.
Дима: «как быстро закрываются типовые задачи».
Тут $mol как раз выигрывает, всякая базовая шалупонь закрывается гораздо быстрее. Да, у вас может быть готовый UI-кит и его, скорее всего, всё равно придётся адаптировать, переносить на $mol. Но это с любым стеком: даже на Vue сколько всего переносят из React, в том числе то, что и не надо. То есть это одноразовая боль. А вот разработческие задачи на логику решаются быстрее, потому что нет типичных проблем неконсистентного состояния. И код читать проще, и писать тоже.
Дима: «сколько стоит заменить разработчика».
Тут так же, как и везде, а то и меньше. По сути нам нужен TS-разработчик, а не «специалист по конкретному фреймворку».
Дима: «сколько инцидентов было из-за „разрозненности информации, потому что её действительно много“».
У больших экосистем информации кратно больше и в ней проще запутаться. Даже LLM может посоветовать что-то непроверенное. Тут выигрывает новый стек: информации меньше, и она конкретнее.
Да и инцидентов меньше, потому что типовые баги закрыты на уровне архитектуры. Было конечно пару раз прям что “фреймворк сломался” из за обновления ts например, починили за полчаса. Versionless все же, но если вы крупная компания — ничего не мешает зафиксироваться на каком то коммите.
Дима: «сколько времени занимает дебаг сложного бага».
Раз багов меньше, и времени на дебаг меньше. И сам дебаг проще: единый поток данных, без грязного состояния. В частности этих сложных багов как раз и меньше.
Дима: «сколько внешних интеграций есть из коробки».
Берём пакет из NPM, как и везде.
Дима: «сколько внутренних платформенных инструментов придётся адаптировать».
Если это NPM-пакет, его не придётся как-то сильно адаптировать под $mol. Единственное исключение это UI-кит, про него я сказал выше. В идеале конечно когда у вас нечего адаптировать, как часто бывает у мелких и средних компаний.
Дима: «какова стоимость выхода из стека через 2–3 года».
Выходить смысла нет, конечно. Но если очень нужно — любое приложение или компонент можно экспортировать как веб-компонент. Не знаю, есть ли такое у других фреймворков, но в $mol так можно, и это очень просто.
Дима: «нет комьюнити, нет сильного тулинга, нет рынка разработчиков, нет зрелых интеграций».
Сообщество есть, тулинг тоже. Да, он не такой навороченный, но сильный тулинг тут и не особо нужен: архитектурно $mol проще, городить вокруг него обвес не приходится. Часть тулинга я написал сам:
LSP —
npm i -g view-tree-lsp@latest, плюс скаффолд приложения одной командой:npm create view-tree-lsp@latest bog/myapp -- --no-docker --no-tauri.tree-sitter-грамматика для view.tree.
Расширение для Zed на их основе — там работает go-to-definition, подсветка и прочие радости. Там 30k скачиваний, наверное боты качают всё подряд для тестов)
Расширения для VS Code (идут вместе с mam).
Дима: «показывай тогда успешный кейс внедрения смола в масштабе хотя бы 2–3 команд».
Чтобы внедрить успешно, нужно, чтобы кто-то со стороны бизнеса сначала попробовал $mol. Снова палка о двух концах.
Дима: «работу ты нормальную на смоле не найдёшь».
Вакансий немного, но они есть, просто не на hh.ru. Так что не надо в комментариях писать, что «на hh пусто»: писать надо в сообщество. И работа нормальная.
Дима: «любое публичное упоминание смола вызывает хейт. Если это не признак нулевой репутации, то я не знаю, что является».
Репутация это эфемерное понятие. Решение то хорошее. В целом сейчас я не вижу прям какого то хейта со стороны сообщества, а вот в нашу сторону вижу. Каждый камень бросит, а человек умер.
Дима: «выбранная Карловским стратегия продвижения… однозначно свидетельствует о том, что все проблемы… решены не будут никогда».
Да, нужен маркетолог, который бы помог это продвигать. Продвигать новое невероятно сложно. Без капитала, без большой медийности, без компании за спиной. Это требует вливания серьёзных денег. И легко со своей колокольни говорить, что мы делаем что-то не так. Но Vue и React популярны не потому, что решение хорошее, а потому что в продвижение вложили много денег.
Egor: «есть мнение, что российская копия ангуляра».
Дима: «может, дело в том, что DSL плохой и неудобный?»
DSL это грамотное техническое решение: пишешь меньше кода, получаешь больше. JSX тоже когда-то был таким решением, просто, очевидно, не лучшим.
Иван: «поищи про зустанд или там эффектор, мобикс мало кто сейчас котирует».
Zustand в разборе есть. Эффектор к нему можно добавить, но кардинально лучше он вряд ли будет.
Egor: «какую проблему решает ваша реализация реактивности?» «да нет проблемы реактивности».
Половина примеров в разборе завалила тесты: показывают невалидное состояние, грязное или просто неправильное. Причём это популярные фреймворки. И как после этого говорить, что проблемы не существует? Это всё равно что сказать, будто лучше сделать нельзя — хотя можно. Странное консервативное мышление. Даже не консервативное, а анти-моловское.
Проведу аналогию с финансовым рынком. React это базовый индексный фонд, как наш MOEX. Вкладываться можно, но внутри Газпром и ВК, которые стабильно убыточные. Чтобы обгонять такой индекс, достаточно просто не брать тот же Газпром. А $mol это скорее S&P 500: высокая доходность, стабильная на длинном горизонте.
Технические решения влияют на бизнес
Технические решения безусловно влияют на бизнес. Баги, которые надо чинить, в бюрократической машине бизнеса растягиваются на недели. А ведь часть этих багов просто заложена в фреймворк архитектурно. То есть мы берём фреймворк с зашитыми багами чтобы потом чинить их за свои деньги, за время дорогих разработчиков. Это максимально глупо.
В общем, нам нужно поднимать сетевой эффект. Хотелось бы рассчитывать на поддержку российского сообщества: наши решения не уступают мировым аналогам, а во многом их превосходят.
Я пробовал писать автору из SolidJS, в твиттере. Пока не ответил. Знаю, что он делает вторую версию своей реактивности: первую считал неудачной (её Дима разбирал на одном из стримов). Представляете? Если бы он узнал о $mol — мог бы сразу взять оттуда идеи, собрать SolidJS на базе $mol_wire. И никто бы не был против.
Bus factor сильно преувеличен. У меня ни разу в жизни не было такого, чтобы библиотеку не взяли из-за bus factor. Да, библиотека может закрыться, политики могут поменяться, но в разработке обычно всё стабильно. Берём тот же Redis для кэширования и живём спокойно. С приходом AI стало чуть хаотичнее, но в целом всё нормально.
Вывод
Короче, надо заходить на английский рынок: чтобы $mol признали сначала в мире, а потом уже в России и начали копировать и использовать. Я считаю так.
Потому что своё в россии мы продвигать не хотим, зато лучше возьмём какое-нибудь чужое распиаренное решение, пусть и похуже. Очень грустно от этого, господа.
Комментарии (49)
powerman
21.06.2026 18:01Главная проблема $mol в его авторе, точнее в его стиле коммуникации, отпугивающем большинство потенциальных новых пользователей. А у текущей статьи - в слишком высоком уровне абстракции, она не про конкретно $mol, а про любой новый фреймворк. Про особенности $mol там одна картинка про закрытые на уровне архитектуры баги, но вот как раз эту тему статья и не раскрывает.
cmyser Автор
21.06.2026 18:01точно, надо бы ссылку в статью добавить
тут https://habr.com/ru/articles/1044684/ разбор как раз
в статью тоже добавил, спасибо
Kenya-West
21.06.2026 18:01Понятно, что статья про выбор $mol, но я просто выбрал бы, к чему душа лежит ближе - Angular. Возможно, в составе с Analog. Давно уже мета-фреймворки появились: Vue + NUXT, React + Next, Angular + Analog. У Svelte что-то даже было...
А $mol... Если есть llms.txt или годный скилл для невронок, то почему бы и нет? У меня куча идей для проектов, я не против попробовать что-то новое, благо этот фреймворк уже больше 10 лет присутствует на Хабре. Сегодня у меня хорошее настроение, можно и на $mol его потратить!
cmyser Автор
21.06.2026 18:01оооо! здорово! если какие вопросы будут пиши к нам в @giper_dev
подумаем над мета фреймворком для мола!а скил, вот он ! npx skills add b-on-g/mol_skill --all -g
900k
21.06.2026 18:01А $mol позиционируется как enterprise framework или что-то нишевое?
cmyser Автор
21.06.2026 18:01для всех https://mol.hyoo.ru/#!section=docs/=j0mafl_shvwnd
для мелких задач в принципе и так всё что угодно подходит, для больших уже нужно что то грамотное под капотом
наверное больше как enterprise тогда всё же
artptr86
21.06.2026 18:01Дима: «может, дело в том, что DSL плохой и неудобный?»
DSL это грамотное техническое решение: пишешь меньше кода, получаешь больше. JSX тоже когда-то был таким решением, просто, очевидно, не лучшим.
Здесь вы уходите от ответа. Вас не спрашивают, хорошо или плохо было использовать DSL. Вас спрашивают: мог ли $mol быть успешнее, если бы его DSL был другим.
Дима: «выбранная Карловским стратегия продвижения… однозначно свидетельствует о том, что все проблемы… решены не будут никогда».
Да, нужен маркетолог, который бы помог это продвигать.
А что, если маркетолог предложит вам поменять какую-либо из концепций? Например, минимально предложит перейти от синтаксически значимых отступов (как в CoffeeScript, HAML, Pug) к более привычному синтаксису на основе разделителей (как в TypeScript). Насколько сильным будет сопротивление вашего комьюнити? А если это с большой вероятностью увеличит заинтересованность разработчиков?
cmyser Автор
21.06.2026 18:01мог ли $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
21.06.2026 18:01Так какую же выгоду дают синтаксически значимые отступы?
cmyser Автор
21.06.2026 18:01ровно такую же, как и в python
Скобочки бы усложнили чтение
artptr86
21.06.2026 18:01Почему-то в си-подобных языках, в том числе и в базовых фронтенд-языках JavaScript, TypeScript, используется именно скобочный синтаксис, тогда как тренд на синтаксические отступы не прижился. Мне кажется, что вашим стараниям по продвижению фреймворка мешает ваша же оголтелая субъективщина. Тем более, как я уже упоминал когда-то в комментариях, в обосновании преимуществ формата tree была логическая ошибка сведения к частному: «Если какое-то решение эффективно в общем случае, значит оно эффективно и в частном», что, разумеется, неверно.
Тем более, сравнение DSL идёт только с уже существующими решениями, хотя можно было бы рассмотреть какие-то гибридные или аналогичные решения типа языка шаблонов Angular или Vue, либо что-то типа описания интерфейсов Jetpack / Swift.
Вся странность вынесена в первые пять минут (view.tree, $-неймспейс, MAM), а выгоды накапливаются месяцами. Профиль «затраты сейчас, выигрыш потом» — худший для adoption; у React ровно обратный.
Но это как раз сильно мешает продвижению, потому что мало кто хочет тратить столько усилий на понимание формата для фреймворка, преимуществ работы с которым они ещё не поняли. Большинство разработчиков хотят словить хайп, а вы их в каких-то китайских письменах заставляете разбираться. Так у вас популярности никогда не будет.
cmyser Автор
21.06.2026 18:01«Если какое-то решение эффективно в общем случае, значит оно эффективно и в частном»,
в каком общем случае view.tree эффективен, а в каком частном - нет ?
сравнения есть тут https://github.com/hyoo-ru/mam_mol/wiki/View-Formatsэто как раз сильно мешает продвижению
да, так и есть. но изменять его - только портить, что с "{}" что с чем то другим, сейчас максимально компактно получается, портить не хочется
возможно тут есть какое то решение
поддержать "вторую" версию view.tree с другим синтаксисом но с полной обратной совместимостью , например , надо подумать
залетай к нам в @giper_dev , подумаем вместе, может что и сделаемartptr86
21.06.2026 18:01в каком общем случае view.tree эффективен, а в каком частном - нет ?
Нет. В качестве наиболее эффективного формата для структурированных документов был провозглашён tree, а затем на его основе был построен view.tree, который якобы настолько же эффективен в частном случае — шаблоны компонентов.
что с "{}" что с чем то другим, сейчас максимально компактно получается, портить не хочется
Людям не нужна максимальная компактность, иногда некоторая избыточность, наоборот, помогает. Формат tree же не рассчитан как таковой на человека, а скорее на лёгкое написание однопроходного парсера.
залетай к нам в @giper_dev , подумаем вместе, может что и сделаем
Хабр — не место для дискуссий?
cmyser Автор
21.06.2026 18:01можно и тут, но в догосрок было бы здорово в чатике
теперь понял, надо думать, тут я , если честно не могу грамотный ответ дать
@nin-jin помоги ответить плиз
от нейронки вот такой ответик
nin-jin
21.06.2026 18:01Формат tree появился в процессе проектирования языка view.tree. Это разные уровни абстракции, не сравнимые между собой.
OstapIbragimovich
21.06.2026 18:01Странно слышать, про то, что тренд на синтаксические отступы не прижился. Python так и не собирается умирать, как и yaml конфиги, которые каждый день читают и пишут сотни админов и devops'ов. То, что популярность js/ts взлетела до небес, а первые языки использовали разделители по техническим причинам - потому что так проще анализировать код и компилировать - не значит, что синтаксис с отступами чем-то плох. Наоборот, он более человеко-читаемый, создает меньшую когнитивную нагрузку на человека.
artptr86
21.06.2026 18:01Речь как бы про фронтенд, а в среде фронтендеров тренд этот не прижился.
OstapIbragimovich
21.06.2026 18:01Вспомните, что когда ваш фронтэнд летит по пайплайну на прод, где-то сидят и тихонечко молятся devops'ы...
artptr86
21.06.2026 18:01Молятся как бы их кучка сконкатенированных ямлов не рухнула на проде из-за Норвегии?
cmyser Автор
21.06.2026 18:01да кстати в ямл есть проблемы
описаны тут https://habr.com/ru/articles/503240/OstapIbragimovich
21.06.2026 18:01Главная проблема популярных фреймворков для фронтэнда - это тяжелый легаси, который годами трансформируется и ничем не лучше любого легаси в крупном энтерпрайзе. Это большие неповоротливые машины, как в "Хрониках хищных городов", которые все время куда-то движутся и модернизируются на ходу, причем мало кто помнит с чего все начиналось и почему здесь сделано так, а не по-другому. Так же очень похожа на "хищные города" традиция собирать приложения из npm-мусора, часто вопреки здравому смыслу используя зависимость вместо 2х строк кода. JS по сути своей такой же тяжелый энтерпрайз легаси, который был разработан за 10 дней под веселым названием Mocha и был встроен в Netscape Navigator, и с тех пор так никто и не решился выпилить его из браузеров несмотря на кучу альтернатив.
OstapIbragimovich
21.06.2026 18:01Я читал статью про tree и не в восторге. Если расставлять по удобочитаемости, то я поставил бы tree ближе к концу, куда-то между yaml и сырым json. А XML (и как частный случай HTML), несмотря на продуманность, можно изуродвать атрибутами так, что первый взгляд на документ будет вызывать желание немедленно его закрыть. Кажется еще лет 15 назад мудрые разрабы всякого возвышенного софта для предприятий решили, что XML - не для людей язык, а для приложений и нечего его пытаться читать глазами. Tree прост и понятен, как абстрактный конь в вакууме - “вот вакуум, вот конь и … с конем как хотите”. Но по факту иногда простота хуже воровства. TOML - попытка немного улушить разбиение больших конфигов на секции без использования комментариев, чего не хватает, например, в yaml, поэтому я его не презираю, тем более что он стал стандартом в не которых областях.
OstapIbragimovich
21.06.2026 18:01Скорее, чтобы ресурсов хватило на новые фичи и пайплайн не сломался из-за новых зависимостей.
OstapIbragimovich
21.06.2026 18:01А что еще не входит в зону ответственности DevOps и в чью тогда зону ответственности входит следить, чтобы пайпланы запускались, а новые вересии деплоились куда надо?
artptr86
21.06.2026 18:01Если пайплайн внезапно сломался из-за новой фичи или зависимости — виноват фронтендер.
OstapIbragimovich
21.06.2026 18:01Если это было так, девопсы бы 99% своего времени пили смузи с пивом и рассуждали о высоких материяах... К сожалению, в жизни не все так просто, особенно в гетерогенных средах, которых в энтерпрайзе и госструктурах ну очень много, и приходится что-то докручивать ручками... Но если вы работаете с китами типа Амазона, Гугля или Микрософт, то да, тут всегда виноват фронтэндер и фиг вы чего докажете им...
artptr86
21.06.2026 18:01Значит виноваты архитекторы и менеджеры, которые довели продукт до такого состояния. Не зря стараются разделить компоненты, чтобы они собирались (и, в идеале, доставлялись) независимо друг от друга.
OstapIbragimovich
21.06.2026 18:01Советую вам когда-нибудь подойти к архитектору или менеджеру и прилюдно объявить ему что он виноват в чем-то. Будет интересно почитать, как будут развиваться события... Хотя это бессмысленно. О проблеме узнают и дергаться начнут сначала все равно девопсы, которым сообщат дежурные админы, которых возможно к моменту инцидента уже взбодрит поддержка и только потом все это дойдет до разрабов, которые, кончено, первыми получат по шапке, и может быть история дойдет и до архитектора/менеджера, если последствия окажутся реально серьезными.
artptr86
21.06.2026 18:01Советую вам когда-нибудь подойти к архитектору или менеджеру и прилюдно объявить ему что он виноват в чем-то. Будет интересно почитать, как будут развиваться события...
И как это отменяет их степень вины?
О проблеме узнают и дергаться начнут сначала все равно девопсы, которым сообщат дежурные админы, которых возможно к моменту инцидента уже взбодрит поддержка и только потом все это дойдет до разрабов, которые, кончено, первыми получат по шапке, и может быть история дойдет и до архитектора/менеджера, если последствия окажутся реально серьезными.
Ну то есть проблема не только на техническом, но и на организационном уровне. Но если это гос или крупный энтерпрайз — ничего удивительного.
И мы же обсуждали, что проблема была в пайплайне? Но если он упал, то до прода ничего дойти не должно. А если он собрал приложение криво, то где тесты, которые должны просигналить о проблеме раньше, чем произойдёт доставка?
Amigun
21.06.2026 18:01Почему-то в си-подобных языках, в том числе и в базовых фронтенд-языках JavaScript, TypeScript, используется именно скобочный синтаксис
И почему же?
вашим стараниям по продвижению фреймворка мешает ваша же оголтелая субъективщина
А ваша?
Но это как раз сильно мешает продвижению, потому что мало кто хочет тратить столько усилий на понимание формата для фреймворка, преимуществ работы с которым они ещё не поняли. Большинство разработчиков хотят словить хайп, а вы их в каких-то китайских письменах заставляете разбираться. Так у вас популярности никогда не будет.
Лучше быть непопулярными, чем прогибаться под привычки других, осообенно под привычки, которые не дают ничего полезного, а часто и наоборот вредят.
Если разработчик не в состоянии уделить немного времени, чтобы разобраться в простейшем синтаксисе, то, ну, что сказать, хех, пусть пишет себе дальше на реакте, рано ему еще в $mol, не дорос.
artptr86
21.06.2026 18:01Лучше быть непопулярными, чем прогибаться под привычки других, осообенно под привычки, которые не дают ничего полезного, а часто и наоборот вредят.
Так вам никто не запрещает писать на чём вы хотите. Но это же вы приходите к остальным со своей истинной верой.
Если разработчик не в состоянии уделить немного времени, чтобы разобраться в простейшем синтаксисе, то, ну, что сказать, хех, пусть пишет себе дальше на реакте, рано ему еще в $mol, не дорос.
Вы бы, наверное, тоже отказались, если бы вам навязывали писать на PHP вместо Python, хотя оба Тьюринг-полные языки.
cmyser Автор
21.06.2026 18:01Так вам никто не запрещает писать на чём вы хотите. Но это же вы приходите к остальным со своей истинной верой.
вот да, этот подход неправильный, и часто вызывает хейт а не потребность разобраться
с другой стороны, а как другие пиарятся ? тоже ведь за счет преимуществ
сложно это всё
Amigun
21.06.2026 18:01Вы бы, наверное, тоже отказались, если бы вам навязывали писать на PHP вместо Python, хотя оба Тьюринг-полные языки.
учитывая вектор развития Python, не грех и на PHP посмотреть…. Если бы мне показали что-нибудь лучше, чем мой привычный инструмент, привели примеры проблем моего основного инструмента и как их решает “навязываемый” инструмент, то не вижу причин не попробовать, вдруг и правда лучше? Как минимум - расширить кругозор, а в хорошем случае - посмотреть какие есть хорошие решения и попробовать применить их у себя, не обязательно переходить на новый инструмент, особенно если для тебя важно наличие вакансий, а их нет.Надо лишь отбросить принципиальность и, в контексте $mol, предвзятое отношение к автору. По вашему или чьему-либо еще мнению он может быть токсиком вселенского масштаба, но это не влияет на технические характеристики его фреймворка.
FranzSPb
21.06.2026 18:01Кирилл, прекрати тратить свое драгоценное время на этот мертвый проект, он не взлетит. Синтаксис ужасный, вам никогда не преодолеть сопротивление разработчиков, это другой язык, никто не будет учить язык просто чтобы посмотреть что там Карловский навыдумывал, что бы ты ни писал про его удобство. Ваши все демонстрационные страницы выглядят ужасно, как будто дед на колентке напрограммировал. Ваша виртуализация не позволяет тянуть за скролл, вам пишут об этом в каждой статье, и в каждой статье вы (в лице Карловского) огрызаетесь, вместо того чтобы это исправить. $mol хороший пет-проект Карловского, Карловский талантлевый, если не гениальный, программист, но плохой продакт, кто-то наверняка подсмотрел или подсмотрит там что-то для своих нормальных фреймворков, но этот не взлетит
cmyser Автор
21.06.2026 18:01Спасибо за критику, скрол да, нужно починить обязательно
По дизайну тоже согласен. Я например вот такую штуку сделал https://b-on-g.github.io/builderui/base=stone/theme=violet/chart=green/font_body=eb-garamond/font_head=dm-sans/radius=medium для создания различных дизайнов и быстрого использования у себя
Я считаю что у проекта очень очень много преимуществ, которые нужны индустрии, поэтому я и хочу вкладывать в это усилия и время
NZT
Абсолютно субъективное и ложное утверждение. Время на дебаг вообще не зависит от количества багов. То же относится и к сложности багов.
cmyser Автор
как бы да, есть просто логические баги, которые можно долго выискивывать, особенно на стыке систем, но вот вот багов а-ля че то у нас экран не тот или поведение иногда после клика странное, вот такого меньше
cmyser Автор
собственно, сегодня вот и пример нашелся
https://habr.com/ru/companies/tbank/articles/1048446/
такого бага, в моле не заложено архитектурно вообще