Как стать автором
Обновить

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

У меня сложилось негативное отношение к $mol из-за агрессивной рекламы и поведения со стороны vintage
1-в-1 причина.
А как же «замечательный» синтаксис?)
Второй аккаунт vintage?! Надеюсь нет…
я пишу огромную статью "$mol: reactive micromodular ui-framework"

Вот же прямая отсылка.

Точно, пропустил (сорри, нет привычки ходить по ссылкам). А вообще, правила хабра запрещают дополнительные аккаунты, насколько помню.

А так же они запрещают писать статьи, если карма меньше -30.

И не зря, судя по стилю постов ;)

Браво, это генеально!

Хотя я как бы fullstack (официально), на деле же — законченный backender, знающий фронтэнд лишь настолько, чтобы суметь обойтись без frontender'а, когда надо. Т.е. «по верхам» мы умеем, но чтобы оценить красоту и ценность (если таковые имеются) нового фреймворка этого недостаточно. А поскольку нас таких очень много (разумеется, сужу субъективно по собственному окружению), то мой первый вопрос — а какова кривая обучения в $mol? Например, Vue.js зашел на ура, спасибо его простоте и отличным докам. Angular (пока не было Vue) тоже ничего так, но время погружения дольше (особенно после его второй версии). React вообще создает впечатление зоопарка в зоопарке. А что с $mol в этом плане?

Года 4 назад я очень легко погрузился в React без Redux и прочего зоопарка. Сегодня React сам по себе зоопарк, ему не помешает мажорный релиз с выкидыванием половины функционала. Пытался во Vue, но с ходу запрыгнуть не получилось, а для основательного изучения не было стимула. Angular намеренно не трогал, потому что уже тогда он считался устаревшим монстром.

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

Для меня основная причина негативного отношения к $mol — из статьи в статью, из комментария в комментарий продвигаемая автором позиция "Все джуниоры, а я Д'Артаньян". Я читал много комментариев — и даже, пожалуй, соглашусь с ними, — что в $mol огромное количество прорывных идей, которые даже, возможно, способны полностью изменить индустрию. Но, каждый раз встречая статью про этот фреймворк, я уже знаю, что будет внутри.


А там будет негатив — ядовитые высказывания в сторону мейнстримных технологий и компаний, их разрабатывающих. Высказывания, которые даже читать неприятно — просто потому, что обычно в нашей индустрии принято уважать чужой труд. Сколько бы проблем ни было у Реакта (а они, конечно же, есть), его пишут умные и талантливые люди, которые любят своё дело и уважают своих клиентов — разработчиков и простых пользователей. И когда ты читаешь высказывания, унижающие их, их труд, их вклад в интернет-технологии, становится сложно воспринимать серьёзно автора таких высказываний — и, как следствие, то, что этот автор создаёт.


Можно же продвигать свой продукт вежливо, уважительно и объективно. Не опускаясь до насмешек над конкурентом. Не обесценивая его труд. Это так просто — и гораздо полезнее для всех.


Давайте относиться друг к другу с уважением.

Абсолютно согласен. Называть код "парашей" (а это есть в статье) — ну верх непрофессионализма. Я не хочу читать про смол и его использовать. Не потому, что он плох, а потому, что его программируют радикалы, мнение которых мне не близко.

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

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

За что уважать компании и разработчиков которые не беспокоятся ни о качестве, ни о чем ином кроме своей прибыли?

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

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

Я буду оценивать то, что я вижу. А вижу я то, что мне суют в нос какое-то решение. Мало того, что они сомнительное технически, так это еще и писал какой-то чувак панк, который даже продавая свою штуку не может слюну свою не выплескивать. Так что не надо тут говорить кому и что нужно оценивать. Хотите оценивать однобоко — я вам не мешаю, я выразил субъективную точку зрения.

Если они сомнительны технически, почему я не вижу технических комментариев, а одни жалобы по поводу автора? Напоминает ситуацию когда Столлмана поперли с поста из-за феменисток

В предыдущих публикациях была критика. Ничего не поменялось с тех пор. Зачем повторяться?

Можно примеры? Тут я точно их не увидел, может еще где-то есть

Можно, конечно. Странно, что вы у меня разрешения просите, но всё равно приятно. Странно было бы их тут увидеть, потому что они в основном там. Пройдите же по ссылкам, они же есть прям в статье.

Я в коде автора, продемонстрированном на данной странице, не понял совсем ничего, хотя во фронтенд неплохо умею. Вот поэтому и нет технических комментариев.
Ну так может стоит разобраться, если это реально инструмент будущего непризнанного гения? Вон тут недавно опубликовали сайт написанный на паскале и все плюсами закидали, что плохого в чем-то новом, если тем более у автора есть причины делать это новое и он считает что оно работает? Просто я вот заинтересовался хвалениями автора фреймворка, но хотел бы почитать технические примеры вообще, все ли так радужно как он описывает и стоит ли тратить свое время на разработку приложений на этом фрейме. Вообще меня больше всего привлекло то, что авторы обещают разработку под все платформы сразу- а это ужасно хорошо, это то от чего веб выстрелил в свое время
Кто-то обещает, а кто-то давно делает. React Native, Uno, Blazor, прости господи, Electron. Впрочем, $mol тоже справиться.
Если автору сложно пояснить, что его код значит, и если автору сложно выбрать более приятный другим людям синтаксис (да хотя бы скобок добавить!), если автору сложно написать решения стандартных практических задач на его фреймворке и каком-нибудь более привычном и подробно разобрать и сравнить… то у проекта, к сожалению, нормального будущего нет. Это очень печально, но тащить автора за волосы из болота у нас возможности нет — у нас свои проекты есть.
Если автору сложно пояснить, что его код значит

Всмысле сложно пояснить? Есть же дока

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

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

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

Если бы дока была збс к автору и вопросов бы не было. Были бы, но другие.


Автор же пишет, что у него были причины выбрать такой синтаксис. Наверно технические решения важнее того, что привычно а что нет?

А синтаксис — говно. Причина — писать меньше кода за бОльшие деньги. Нормальное желание. Но зачем на людях-то?

Так чем плохо писать меньше кода за большие деньги? Если вы потратите время на изучение синтаксиса, но взамен получите золотые горы которые обещает автор с мультиплатформенностью, легкостью и тд?

Меньше работать за большие деньги — хорошо. Это даже работодатель оценит. Я не отрицаю же. Но если я потрачу время на изучение клингонского языка, я могу стать высокооплачиваемым переводчиком-клингонистом. Работу только бы найти… И пока вся суть смола в этом и заключается.

Погодите, в чем суть? Если у вас задача написать фронт вы можете написать его заказчику на чем угодно. Если вы работаете не в легаси, то вы сами вольны выбирать себе на чем писать. Для какого-нибудь фуллстека или фрилансера в этом вообще нет проблем

Да. Вообще, идеально под каждый заказ выдумывать более новый язык программирования. Заказчику, вроде, пофиг, а мне, вроде, профит в долгосрочной перспективе.

Демки интересные. Можно ли на этом фреймворке сделать приложение и запихнуть его в .apk?
Ещё один вопрос — возможно ли сделать клон github.com/instead-hub/instead-js (оригинал написан на Angular, емнип).
Можно ли на этом фреймворке сделать приложение и запихнуть его в .apk?

Можно просто сделать PWA приложение одной строчкой кода. Но можно завернуть в Cordova и получить apk, да.


возможно ли сделать клон github.com/instead-hub/instead-js

Конечно, почему бы и нет.

Зашел на демки.
Потенциал есть, но framework сырой.
200+ ошибок при открытии страницы, это перебор.
В демках проверил контрол грида: без базового функционала фильтрации, сортировки и навигации.

Много текста, много пафосных фраз и душных историй.
Совет: не говните других.
Зря вы на Альфа наехали, их решение структурированное и легкое в поддержке. Я бы выбрал их подход.

Удачи.
В демках проверил контрол грида

В $mol сейчас нет "контрола грида". Есть табличный лейаут, да и тот депрекейтнутый, так как больше не нужен. Будет классно, если попробуете реализовать "контрол грида" с сортировками и фильтрациями.

Сходил открыл для интереса исходники наверно самого простого приложения notes. Ну что я могу сказать МОИ ГЛАЗА. Такой упоротый синтаксис и код-стайл я вижу только когда открываю старый код на перле. Уровень читаемости ровно такой.

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

UPD подсветку синтаксиса для tree увидел. Хоть что-то. Правда это не отменяет моего не понимания зачем придумывать еще один не скучный формат где спокойно бы подошел YAML.

Я вначале не мог понять, что меня в view-tree так раздражает (кроме кучи символов вместо ключевых слов). Потом понял — одинаковая стилистка данных и метаданных. В XML, JSON сразу видно, даже без подвески, где тэг, где поле, а где данных. Стена текста.
Хотя за < input type="button" value="Click me" /> тоже бы ручки то оторвать.

Всё, что начинается с $ — имена классов. С \ — сырые данные. Имена без спец символов вначале — это свойства. Исключение: true, false, null и числа.


С подсветкой выглядит как-то так:


Но чем больше я погружал его в проблематику, тем чаще он приходил к тем же выводам, что и я. И вскоре ненависть сменилась искренней любовью. Порой мы могли по пол дня спорить с Артуторм о правильном поведении, но именно ему я мог доверить разработку любых модулей, зная, что он справится не хуже меня. Тот самый язык view.tree мы пытались полностью перепроектировать с нуля, чтобы он вызывал меньше отторжения своей необычностью. Но результат оказался почти таким же, как и исходный синтаксис.

Кажется я понял, чего мне не хватало. Разработчика фреймворка, сидящего рядом, и «погружающего в проблематику». А скорее даже тупо консультирующего по написанию этого всего, проблематику-то я на своей шкуре всю испытал.

И заодно я скажу своё «bullshit!» на последний процитированный тезис. Подвигать узлы в AST и допилить парсер — это мягко говоря не rocket science, особенно с учётом того, что это всё не в рантайме делается, а именно это и позволяет натянуть читаемый синтаксис на распрекрасные идеи. То, что у вас синтаксис остался нечитаемым даже после переделок — говорит только о том, что читаемость в приоритетах никогда не стояла.
4 года спустя все еще _никому_ не нужен.

Скажите что-то про elm? Мы сейчас часть компонентов пишем на нем (и встраиваем в react наследие).

Я с ним не работал, так что ничего определённого сказать не могу.

Здравствуйте, господин Карловский nin-jin.

Так случилось что с вашим кодом я познакомился лично 4 года назад, когда работал в одной компании, где был внедрен $mol.
Моей первой задачей было немного модифицировать pipeline сборки — протащить новую схему локализации, собрать артефакт под разные среды сразу, собрать js чуть иначе.
На эту задачу я потратил 3 месяца.

Сборка была написана на $mol.
Что я обнаружил:
1. Код написан на ES1 code style, с eval, new Function('asksd ')
2. Активно используются сайд-эффекты в непредсказуемых для общей логики местах.
3. Активно используются глобальные переменные.
4. Тесты отсутствуют.
5. Написано несколько дополнительных шаблонизаторов — tree, mhtml без документации.

Я не понимал, что делает код, как повлияют мои изменения на остальную часть системы.
При этом весь этот монолит работал как единый организм. Любое мое изменение — отторгалось.

Так продолжалось 2 недели. Я приходил на работу пытался понять, что происходит в коде — уходил с работы.
Дальше я не выдержал, сломался. Поэтому переписал весь код на gulp. Сборка стала в разы понятнее. В коде использовал другую наработку github.com/zerkalica/reactive-di как заменитель ambient_context.

Однако каждый раз когда, я думал, что можно релизиться — выяснялись нюансы. Билды опирались на артефакты от предыдущих сборок и я должен был частично повторять эту логику в новой системе. $mol генерировал файлы сборки рядом с исходным кодом, а не в отдельной папке под артефакт. Это было отдельной проблемой.

Потом я столкнулся с автоматической системой сборки модулей без явных import, export на глобальных переменных. Вкратце как она работает. Есть код на регулярках. Он находит все глобальные переменные в коде начинающиеся на $ например: $zoo.animal.putInCage. Сборщик анализирует в каком файле она находится и строит дерево зависимостей между переменными. Затем делает список и конкатенирует. Проблема в том, что система поддерживала даже циклические зависимости. Поэтому в коде встречались и такие конструкции $zoo['ani' + 'mal'].putInCage и даже $zoo[anotherGlobalVarWIthAnimal].putInCage

Отдельного реверанса достойны длинные имена файлов: index.env=production.mode=development.jam.js
вместо того, чтобы разложить файлы по нужным папкам окружений.

Сейчас mol стал взрослее. Часть багов была поправлена, но распространения он так и не получил.
Есть репозиторий github.com/eigenmethod/mol
Весь uikit реализован прямо внутри фреймворка и не отделим от него.

К чему я это все?
Давайте просуммируем что имеем в сухом остатке.
1. Много детских багов.
2. Закрытая экосистема подчиненная одному автору.
3. Сомнительные архитектурные решения, т.к. не было код-ревью.
4. Нет совместимости со сторонними модульными системами.
5. API написан под конкретную задачу и не учитывает потребности внешних потребителей.
6. Если нужно делать расширение компонентов — это нужно делать с оглядкой на uikit в репозитории mol.

Mol имеет внутри множество потрясающих инженерных решений. Это действительно шедевр, как Коралловый замок. Это целая экосистема, но она бесполезна. Т.к. ее нельзя разделить на части:
1. View framework c concurrent rendering
2. Атомы
3. uikit
4. модульная система
5. inversion of control
6. helpers
7. intl
8. сборочная система

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

Советы для vintage
1. Перестаньте выступать на конфах и писать статьи в руссскоязычном сегменте.
2. Выкинуть tree и заменить его на jsx — людям будет проще и привычнее принять ваш образ мыслей.
3. Сделать мостик для совместимости с react компонентами.
4. Пиариться в англоязычном коммьюнити.
5. Сделать mam как лоадер или плагин для вебпака.
6. Пересмотреть полностью внешнее API.
7. Нанять bunopus для продвижения фреймворка. C dart он смог.

З.Ы. Статья хорошая. Даже плюсанул, но с автором по многим вопросам не согласен принципиально, поэтому минусанул профиль.
в одной компании, где был внедрен $mol

Не вводите людей в заблуждение, пожалуйста, никакого $mol там не было. Тот велосипед, о котором вы говорите, писался лет 6 назад на скорую руку. Если бы у меня тогда была возможность довести его до ума, то я бы переписал его уже на тайпскрипте. Но компания решила переходить на Dart. В результате легаси там всё множится и множится, раздув приложение уже до 11 мегабайт сжатого кода.


На эту задачу я потратил 3 месяца.

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


Весь uikit реализован прямо внутри фреймворка и не отделим от него.

Это не так. $mol — это просто набор модулей. Пока вы какие-то модули не используете, они не включаются в бандл.


Закрытая экосистема подчиненная одному автору.

Это не так. Любой человек может использовать свой неймспейс в MAM и пилить там что и как захочет. При этом есть простая возможность использовать наработки из $mol и других неймспейсов. MAM экосистема децентрализованная. Рекомендую ознакомиться хотя бы с этой статьёй, чтобы не вводить людей в заблуждение: https://habr.com/ru/post/456288/

героически бьются сами, а потом предъявляют претензии, что потратили много времени.

Действительно. 4 года.
Язык в вашем случае значения не имеет. $mol сам по себе отдельный язык.

Ваших контактов не было, да и желания обращаться к человеку писавшему eval в коде нет совершенно.

Hello world текущей версии мола запускал — но вылетела ошибка компиляции, ведущая в недра фреймворка. redyuf мне помочь не смог. Сказал что у него все работает.

1. Контакты есть на гитхабе мола, регулярно в чатик приходят люди (правда и уходят также)
2. Мол — это челенж в упорстве и ломки привычных стереотипов, те, кому нужно — разобрались. Через чатик довольно сложно помочь, особенно, если человека бомбит от автора mol, от каждой детали фреймворка и он оставляет эту затею на следующий день.
3. Сборщик в mol был написан видимо одним из первых и левой пяткой, косяков там много, есть задачи на его рефакторинг, нет ресурсов.
4. Не так давно я его немного отрефачил, теперь null-ошибки, которые у тебя тогда возникали, должны пофикситься, некоторые ошибки стали информативнее. Ни я, ни Дима работу над мол прекращать не собираемся, хоть и в пол силы. Баг-репорты приветствуются, мы всегда на них реагируем.
НЛО прилетело и опубликовало эту надпись здесь
Это разве "-". Что язык отделен? Это как раз-то то к чему надо стремиться.

Возможно, да. У того же реакта есть два способа описывать дерево компонентов: старый добрый JS с деревом React.createElement и JSX. Есть простая возможность в $mol заменить синтаксис компонентов хоть на JS, хоть на JSX, хоть на YAML, хоть ещё на что-то более привычное сообществу? Была бы — возможно он был бы более популярен

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

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

Я предлагаю потратить время ещё более контрпродуктивно и помочь с написанием документации. Тем более, что для $mol она есть, хоть и есть куда её улучшать.

Я окончательно запутался после фразы «Поэтому переписал весь код на gulp».
$mol не использую, но вы уверены что это вообще одно и то же?
На мол написана сборка. Ее я и переписал на gulp
А, там совсем все в одной куче.

Там использовалась эта штука, если интересно: https://github.com/nin-jin/pms-jin
К $mol она не имеет никакого отношения. Вот от слова совсем.
Это код из тех диких времён, когда в JS ещё не было классов и каждый велосипедил их по своему.

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

Добрый день, а как было определено авторство кода, комментарии, слова коллег?
Вы так бац, сразу близко к телу пишите. 4 года помнить код именно Карловского. Он реально так насолил?

На эту задачу я потратил 3 месяца.

К сожалению, слишком субъективно, но выражает ваше ощущение боли. Мне это очень понятно.
Сборка была написана на $mol.

Так же интересно как это было обнаружено. Мол в том виде что мы все его знаем релизнулся немногим позже. емнип.

Что я обнаружил:
1. Код написан на ES1 code style, с eval, new Function('asksd ')
2. Активно используются сайд-эффекты в непредсказуемых для общей логики местах.
3. Активно используются глобальные переменные.
4. Тесты отсутствуют.
5. Написано несколько дополнительных шаблонизаторов — tree, mhtml без документации.

Я не люблю обсуждать говнокод без контекста. Например, вас принудили завершить работу с переработкой. Или когда вас там не работало, был страшный ад с менеджментом. Да, гордится нечем, говнокод это не отменяет, но код не существует в вакууме без контекста его написания. Становится хотя бы понятна причина.
По 4 и 5 пункту например, могут быть легко получены ответы исходя из моего посыла выше.

Так продолжалось 2 недели. Я приходил на работу пытался понять, что происходит в коде — уходил с работы.

Местный король разработки чинил багу пол года и не смог, упал в кризис.
Я не хочу измерять чью-то способность нервной системы, но я не вижу ничего смертельного столкнуться с архитектурно другой парадигмой. Да, это всегда больно. Из-за отсутствия комьюнити и коллег мне приходилось оборачивать рабочий код как багу и отправлять в репу флаттера, чтобы хоть кто-то подсказал туда я разрабатываю интеграцию или нет. Действительно, если вы знали что это код Карловского, можно было его нагуглить.

Цифры ваши описывают боль, но где у вас 2 недели у меня в другом месте пол года (java копипаста по большому счету).

Дальше я не выдержал, сломался.

Вопрос патчить или переписать не имеет правильного ответа. Хорошо, что переписали.
Плохо, что ниже хвалите за гениальность, но ругаете только за свой опыт.


Потом я столкнулся с автоматической системой сборки модулей без явных import, export на глобальных переменных.


В постструктурализме, философского направления, «плоды» которого мы пожимаем, есть все таки замечательный инструмент познания как деконструкция. Его целью становится очищение предыдущих решений от авторства и его видения. Зачем? Чтобы избавиться от легаси в мышлении и построить новый смысл. Это ужасно работает в случае культурных традиций, 10 гендеров и квоты в штате, но замечательно работает в технологических решениях.

Если точнее, вы не задумывались, что import модулей несколько идиотская затея, особенно если они от фреймворка? Сделанная для компилятора/сборщика, а не для вас? Почему нельзя использовать просто методы из документации ничего не подключая? Система же знает имя метода, зачем подключать модуль с ним? Мм? Вы пишите все как обычно, просто без import.

Есть код на регулярках.

Ну так, а как ей работать еще в описанном выше виде?
Это сборка, перепиши ее сейчас на esbuild она в три раза шустрее будет. Вопроса производительности не стоит, это просто другой подход.

Отдельного реверанса достойны длинные имена файлов:

Тут я не буду спорить. Мне не нравится тоже это авторское решение.

К чему я это все?

Это действительно шедевр, как Коралловый замок. Это целая экосистема, но она бесполезна. Т.к. ее нельзя разделить на части

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

1. Перестаньте выступать на конфах и писать статьи в руссскоязычном сегменте.


А это открытое хамство.

Выкинуть tree и заменить его на jsx — людям будет проще и привычнее принять ваш образ мыслей.

А разработчики битрикса считают что компонент корзины в 7к строк js кода не надо править потому что он идеален. Tree очень интересный формат и у него объективно есть свои преимущества над jsx.

7. Нанять bunopus для продвижения фреймворка. C dart он смог.

В 21 году кот поджал лапки и… аккуратно перебежал с дарта на тайпскрипт. Не шмогли. Но я их очень люблю за этот эксперимент. Молодцы. Из вашего рассказа, я так понял что Карловский… тренировался на кошках, в прочем, как и Кот.

Если что, в $mol файлы именуются не так:

index.env=production.mode=development.jam.js // JS код для дебажной сборки продакшен билда

А так:

foo.node.test.ts // cпецифичный для NodeJS TS код модуля foo для тестового бандла
я просто помню тоже, что что-то не нравилось с именами, но не в этом суть я не ковырял глубоко.

Ну а Dart в далёком 2014 продавил не Кот, а Игорь. Я, помнится, тогда написал обстоятельное сравнение TS и Dart. Из него следовало, что у Dart нет перспектив во фронтенде. Но оно было полностью проигнорировано. Вскоре меня уволили одним днём. А Игоря повысили до "фронтенд менеджера". Оно и не удивительно, ведь я ходил на обед с обычными программистами и обсуждал технические вопросы отображения десятков тысяч задач в реальном времени, а Игорь обедал с техдиром и вливал ему в уши, что отсутствие разнообразия библиотек на Dart и невозможность плавной миграции - это достоинство, а не недостаток.

В итоге за 7 лет они переползли, на сколько мне известно, с сырого Дарта на ПолимерДарт, потом на АнгулярДарт, потом на Флат.. а, нет, Флаттера так и не дождались на фронте. Лишь только когда сам Гугл признал его бесперспективность, стало уже невозможно скрывать очевидное, - переход на Дарт был глупейшим решением в истории проекта.

Уверен не одна премия была распилена на этих активностях. А сколько ещё предстоит попилить с переходом на TS+React. Пока финансы позволяют, бизнес не особо замечает, как его дурят эффективные менеджеры раздувая под собой штат и тем самым поднимаясь по карьерной лестнице, в то время как архитектура проекта трещит по швам, а сам проект становится похож на монстра Франкенштейна.

Для меня причина номер один даже не пытаться использовать $mol — автор-токсик.
Эта причина принципиально перекрывает любые элегантные решения которые есть или потенциально могут быть в вашем фреймворке. Серебряной пули-то все равно нету.

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

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

В общем если хотите продвинуть ваш мол — найдите себе соратника с нормальным социальным интеллектом, который и будет общаться с пользователями вашего фреймворка.
А сами молчите, ради бога. Хуже не будет.
самым полезным оказался Артур, которого мы наняли специально для разработки фреймворка. Это человек, которого, наверно, увольняли ото всюду, где он работал.

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

Конец 2017. У компании финансовые трудности и люди разбегаются.

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

НЛО прилетело и опубликовало эту надпись здесь

Правильно ли я понимаю, что выбирая между условными Реактом и Ангуляром вы руководствуетесь дизайном их домашних страничек?

НЛО прилетело и опубликовало эту надпись здесь
Да

Больше у меня к вам вопросов нет.


Поясню, чтобы не было недопонимания. Я трачу на этот проект своё личное время не для того, чтобы помочь вам зарабатывать на ваших проектах больше денег. Если вас не волнует эффективность расходования своего времени, то это ваше дело. Меня не лишат премии от того, что сорвётся такой "денежный" клиент.


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

НЛО прилетело и опубликовало эту надпись здесь

vintage — вы нерельно круты. Уважаю вас за интересные мысли и упорство, на протяжении такого времени.


Я в свое время даже почуствовал гордость, когда вы, в расшифровке моего доклада, написали, что типа "лучше бы $mol использовали, а не эти ваши вебпаки". Прям как будто автограф легенды получил :)


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


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

Выглядит как: "$mol лучше, на нём Counter легче сделать, но это неточно и доказать мне нечем, но мне $mol очень нравится".


Есть ли хоть 1 проект на $mol, в котором есть хотя бы десяток разработчиков и проекту уже более года? Можно ли устроиться на работу $mol разработчиком?

Есть ли хоть 1 проект на $mol, в котором есть хотя бы десяток разработчиков и проекту уже более года?

Нет.


Можно ли устроиться на работу $mol разработчиком?

Можно.


Все приведенные в статье конкуретные фреймворки\проекты лучше уже тем, что они доказали свои масштабируемость и используемость в комерческих проектах.

Вы по ссылкам принципиально не ходите?

Можно.

Можете сказать, где ищут $mol разработчиков?


Вы по ссылкам принципиально не ходите?

Хожу конечно. По ссылке команда из 30 человек с помощью react напилила кучу кода и зарелизилась. Проект успешно живет уже несколько лет. Ну т.е. видно, что при использовании react в относительно большом проекте можно писать долгоживущие приложения.


Команде tinkoff стоило взять $mol? Получилось бы лучше? Они бы быстрее переписали сайт, быстрее бы доставляли фичи в прод, легче была бы поддержка, сайт быстрее бы открывался?

Можете сказать, где ищут $mol разработчиков?

Желающие могут написать мне в телеграм и я сведу с нужными людьми.


Получилось бы лучше? Они бы быстрее переписали сайт, быстрее бы доставляли фичи в прод, легче была бы поддержка, сайт быстрее бы открывался?

Да, конечно.

Да, конечно.

Откуда у вас такая уверенность, что у них бы получилось лучше, а не хуже? Может они бы вообще не релизнулись.


Если есть примеры проектов — вы покажите — мы посмотрим и убедимся, что на $mol можно делать что-то прикладное и поддерживать в долгосрочной перспективе.

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

для меня в проекте важно не только удобство использования, но и масштабируемость команды и deploy strategy. в своей работе я пришёл к выводу, что у заказчика слишком часто всё меняется чтобы полагаться на глубокое проектирование, и поэтому я применяю чтото похожее на SCRUM — быстро внедряю свой шаблон проектов на asp.net core 3.1 и MVC + xamarin и дальше смотрю по ситуации.
и тут у меня возник первый вопрос:
мне нужно дизайнера изолировать от программирования, чтобы была вёрстка отдельно, сервер отдельно. иначе не получится зарядить две команды одновременно и они будут зависимы.
и тут важно понимать, как дизайнеру, привыкшему работать с HTML видеть общую картинку компонентов на странице и настраивать их? я full stack но мне достаточно сложно понять по коду, как страница будет выглядеть для конечного пользователя, не запуская все скрипты… или я чтото не правильно понимаю?

следующий неясный момент.
в своей работе я применяю итеративную стратегию разработки и внедрения.
на первом этапе простое приложение на шаблоне, с проработкой всех проблемных функций, чтобы было понятно, какие пожелания заказчика могут доставить наибольшее количество проблем. это делаю обычно я сам с дизайнером. дальше, когда я построю архитектуру проекта, я знаю как внедрить в команду дополнительные рабочие единицы и в каких точках им потребуется обучение. и тут возникает другой вопрос:
если у вас всё является JS и вобще нет HTML, то значит ли это, что мы проделываем очень много дополнительной работы скриптами там, где HTML просто лёг бы неподвижным кодом и не доставлял проблем?
вот тут такой скользкий момент: есть кагбэ два подхода, первый — это как делаете вы и реакт — забыть про HTML и мочить всё в коде. читать это невозможно. ну всмысле я понимаю что я не самый умный, и у меня не получается. второй подход — как делает Vue и наверно Angular — там всётаки есть HTML а скрипты, обслуживающие этот HTML подхватывают его после загрузки и изменяют в какихто моментах, делают динамическими. и вот не кажется ли вам, что этот подход более подходит для команд где людям, обслуживающим дизайн не приходится копаться в программировании?

ещё у меня возник такой вопрос. ошибки понятно у всех бывают, данные приходят или не приходят, или приходят не те… и я, работая в VisualStudio, ставлю breakpoint прямо в JS коде — и дебагер его отрабатывает прямо с клиента. тоесть это выглядит так: я ставлю точку внутри какойто JS функции прямо в студии, и после запуска если код заходит в эту точку мне прямо в студии вылезает стрелочка и я не лезу в браузер. очень удобно.
и вот одна из причин, по которой я выбрал Vue среди всех других фреймворков, заключается в том что они ничего не компилируют, нет никакого node.js, сборщиков пакетов, npm и прочих не очень приятных вещей, которые меняют мой код. тоесть код в разработке на сервере и код выполняющийся в браузере имеет одну и ту же систему нумерации строк — а значит брейкпойнт будет нормально работать. как у вас обстоят дела с отладкой? что мне нужно сделать чтобы брейкпойнты, поставленные в вашем коде, отрабатывали хотя бы в браузере? вопрос такой: есть ли возможность до выкладки в production обойтись без минификаций и изменений JS кода?

ещё одна тема которая меня волнует…
даже если я работаю не на TypeScript а на чистом JS, я стараюсь писать код так, чтобы он подхватывался IntelliSense (система текстовых подсказок VisualStudio). ну всмысле я пишу класс, или функцию, у неё внутри элементы, переменные, потом я создаю объект этого типа, потом ставлю точку и студия подсказывает мне какие переменные я там написал.
что у вас с поддержкой текстовых подсказок?
синтаксист у вас непривычный, и не совсем понятно как поведут себя системы текстовых подсказок в разных средах разработки

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

Знание html тут не поможет, конечно. Просто даёте компонентам и их свойствам говорящие имена. Например, надо вам сделать типичную страничку, создаёте компонент для этого:


$my_page $mol_view
    sub /
        <= Head $mol_view
            sub <= head / <= title \
        <= Body $mol_view
            sub <= body /
        <= Foot $mol_view
            sub <= foot /

Через стили задаёте визуализацию, и теперь при использовании понимаете что где будет:


$my_app $mol_scroll
    sub /
        <= Page $my_page
            title <= title \
            body /
                <= I_am_lucky $mol_button_major title \Мне повезёт
            Foot null

Тут мы задали страничке заголовок, поместили в тело кнопку, а футер вообще убрали.


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

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


есть ли возможность до выкладки в production обойтись без минификаций и изменений JS кода?

Нельзя, но TypeScript генерирует source maps, так что можно отлаживать и через IDE.


что у вас с поддержкой текстовых подсказок?

В Typescript коде с ними всё хорошо, разумеется. Во view.tree их сейчас нет и не очень понятно как прикручивать.

Спасибо за ответ.
мне кажется, что фреймворк очень мощный в потенциале, но есть некоторые вещи которые останавливают людей от его использования — это невозможность интеграции его с готовыми HTML шаблонами и непривычный синтаксис.
если както попытаться решить эти вопросы, как вам кажется, ваш фреймворк сильно пострадает? или отсутствие этих вещей это его основное преимущество?
просто если решить эти проблемы то решится автоматически и проблема высокого порога вхождения.
ещё такой момент — в долгосрочной перспективе не очень приятно работать с компонентами архитектуры, которые подразумевают жёсткую привязку к себе.
vue легко сменить на обычный HTML, ASP.Net partial view с серверной логикой легко сменить на vue-компонент, когда логика сильно усложняется например. какое возможное решение этой проблемы вы видите?

Разумеется мы такой синтаксис выбрали не для того, чтобы всем насолить. Мы рассматривали разные варианты. И текущий синтаксис оказался наиболее простым и понятным. От подражания html всё становится только сложнее. Причина в том, что $mol построен на совершенно иных идиомах: композиция компонент, а не оживление html. Это диаметрально противоположные подходы к построению интерфейсов. Именно поэтому переход с или на "ASP.Net partial view" — это полное переписывание кода. Какой бы синтаксис ни был выбран.

И текущий синтаксис оказался наиболее простым и понятным

:D
Рад, что кто-то задает вопросы по-существу, а не просто хает автора. Так что плюсик.

Заинтересовало несколько моментов:

и вот одна из причин, по которой я выбрал Vue среди всех других фреймворков, заключается в том что они ничего не компилируют, нет никакого node.js, сборщиков пакетов, npm и прочих не очень приятных вещей, которые меняют мой код

То есть разрабатывая на Vue, вы не используете общепринятый подход с .vue файлами (SFC), а работаете черед Vue.extend? Обратил внимание так как всегда считал, что стандартном для Vue считается именно SFC.

тоесть код в разработке на сервере и код выполняющийся в браузере имеет одну и ту же систему нумерации строк — а значит брейкпойнт будет нормально работать.

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

Только я не понял нифига по примеру? ((

Чтобы понимать надо разобраться в синтаксисе. Почитать доку или туториалы.

У меня есть jquery plugin/ es6 module — github.com/DashboardCode/BsMultiSelect (мультиселект с заморочками на мыше и клаве) на котором я технологии компонентые обрабатываю, я его переводил и в web component, и в stencil react (он вполне себе «реактивный»). Мне бы хотелось понять как его (его ядро) завернуть в mol, но ты говоришь о такой революционности mol что убедил — все что было до этого надо выкидывать. И мне страшно. Так что в анкету добавь пункт «не понятно что со старыми компонентами делать».

Можете просто завернуть вашу jQuery реализацию в $mol компонент и использовать, если не хотите переписывать. Сделать это предельно просто: наследуетесь от $mol_view, переопределяете свойство dom_node, чтобы оно возвращало дом-элемент вашего компонента. Опционально можете добавить реактивных свойств для управления.

В чем разница между переписанной и завернтой в mol_view?

Заворачивание не требует переписывания. Хотя, такой компонент был бы полезен и в реализации на $mol. Не хотите попробовать реализовать?

Очень хочу, но я формулирую задачу так «как должен выглядеть код компоненты чтобы его можно было обернуть в mol при чем так чтобы полученная компонента в обертке стала неотличимой по функциональности и сайдэфектом от нативной». Есть подсказка «оберни в mol_view» — отлично, но при этом рекомендация остается «переписать под mol». Вопрос какое это имеет значение, «что изменяет в коде» перепсь под mol, от чего код должен избавиться, какую декомпозицию провести? П.С. Немного деталей не смотря на то что на GitHub jquery plugin у внутренней компонеты нет зависимости от jquery да и с Дом там работы нет (нет селекторов), и внешний цсс не обязателен, в качестве {createElement attach hide/show} можно подсунуть что угодно. И она вполне реактивна (изменения распространяются от данных) Есть зависиомсть от popper.js — и от addEventListener — но и от этого можно абстрагироваться. При данных условиях что надо делать?

Пример оборачивания можно глянуть в компоненте $mol_map_yandex, который просто рендерит ЯндексКарты и реактивно управляет ими, что гораздо удобнее, чем исходное интерактивное карточное апи.


Переписывание может дать следующие бонусы:


  1. Простая кастомизация.
  2. Минимизация дублирования функциональности и соответственно размера бандла.

Есть зависиомсть от popper.js

В $mol для этого есть $mol_pop.


При данных условиях что надо делать?

Тут есть два пути:


  1. Простой и быстрый — обернуть ваш код в $mol компонент.
  2. Правильный и полезный — реализовать заново на $mol компонентах.

Я бы предложил сначала сделать первый вариант, а потом переписать по второму.

Постая кастомизация нативных компонет в mol реализуется каким образом?

Нативных — это каких? Простая кастомизация — это у $mol компонент.

Я о mol к-тах в данном случае (говоря нативные) и я понимаю речь идет о стилях («простая кастомизация.»). Каким образом стили например поля инпута, передаются «mol компоненте»? Мне нужен именно стиль, а не «компонента input», я стилями div раскрашу, а input мне не нужен (у меня «фейковый input»). Замечу что нужны в компоненте и стили псевдоклассов инпута :valid, :invalid? Что со стилем плейсхолдера? П.С. если провести «декомпозицию» т.е. создать компонент «фейковый инпут» отдельно — то ок но это еще не отвечает на вопрос как получить стили «инпута» в компоненте «фейковый инпут»?

В $mol нет "стилей инпута". Каждый инпут стилизуется отдельно, но используется общая тема, определённая в $mol_theme. Используется она так:


[my_input] {
    box-shadow: 0 0 0 1px var(--mol_theme_line);
}

Или так:


$mol_style_define( $my_input , {
    background: `0 0 0 1px ${ $mol_theme.line }`,
} )
Спасибо а стили псевдоклассам как назначаются и как потом доступны?
Cпасибо. Я спрашиваю чтобы от страхов перед докой (и фреймоворком) избавиться. А страхи от того что не понимаю как он работает (из описания фичей). Возможно пропустил статью — «не бойтесь, все просто: миграция с веб компонент, миграция с реакт».

К сожалению, туториал по миграции с других фреймворков пока никто не написал.

Ты правда такой уж реальный бонус в TS видешь или это замануха?

Более того, те, кто сегодня не используют статическую типизацию, пишут сразу легаси.

Когда код будет писать AI нужна ли ему будет статическая типизация?

Вот когда будет, тогда у него и спросим.

Ambient Context — это предельно простая штука

Как по большей части бекэндщик, такие слова для меня режут слух. Годами доказано, что Service Locator и же с ним AmbientContext — антипаттерны, крупные вендоры стараются от них отказываться или маскируют через нормальный DI через конструкторы, за что мой низкий поклон Angular.

В Ангуляре DI реализован через тот же AM, только там он называется Injector.


У SL есть ряд, свойственный глобальным переменным, недостатков, от чего некоторые стараются его избегать. У AM таких недостатков нет.

AM, только там он называется Injector

Это спорный вопрос про Injector — является ли он AC, к тому же в обычных ситуациях его напрямую можно не использовать.
У AM таких недостатков нет.

У SL и AM один фатальный недостаток — их трудно отследить, т.к. обращения к ним разбросаны по коду, а вот у классического DI нет — все зависимости явно указаны в конструкторе.
их трудно отследить, т.к. обращения к ним разбросаны по коду

Вы наверное не используете IDE?
Для WebStorm/PhpStorm — правый клик на интересующую вас переменную --> «Find Usages».
Для VSCode — правый клик на интересующую вас переменную --> «Find All References».

Каким образом это может быть фатальный недостаток, если они элементарно отслеживаются, я уже молчу про то, если вы TypeScript используете, там им вообще никак не спрятаться от ваших глаз.
И ещё, все эти зависимости явно указаны в import'ах. Это к вашему:
а вот у классического DI нет — все зависимости явно указаны в конструкторе.

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


Другая проблема DI в том, что все зависимости надо предоставить в момент инициализации (push семантика). Из-за этого, например, TestBed в ангуляре и тормозит. У нас он давал накладные расходы в 100мс на каждый тест. Попытка получать зависимости лениво по запросу опять же возвращает нас к инжектору и соотвественно к AC.


Так что мы просто минуем бессмысленные пасы руками и реализуем простую и понятную логику работы — у объекта есть контекст, все зависимости он берёт из него, как если бы он их брал из глобальных переменных. Сами контексты образуют иерархию по владению и позволяют переопределять для своего поддерева любую "глобальную" переменную.


А "отслеживать обращения" как правило нет потребности. А когда есть, обычно программист и так знает к чему и зачем идёт обращение.

Там идёт речь про получение контекста через статическую переменную, а не локальную. Впрочем, даже в такой формулировке аргументы там притянуты за уши.

1) Тормозит уж точно не из-за пуш семантики, всегда можно передавать не объекты а их фабрики (для отложенного создания). 2) Но в том как появляется «все нужное» для исполнения «custom кода» как аргументы переданные через запятую или как единый объект контекста — разницы нет. В этом поддерживаю. Правда тащить контекст по всем вызовам методов/конструкторов «в глубь» излишество тоже, там же «всё» и не нужно.

Дмитрий, вы — заебатый чел и идеи заложенные в $mol действительно перекрывают современных фронтенд-трендсеттеров (ака реакт) с головой. Единственная проблема заключается в том, что борьбу за умы вы проиграли (или, вернее, даже не успели в неё вступить). Рынок оформился, есть лидер — реакт, догоняющий — вью и куча всякой мелочи вокруг. Всё, влезть туда уже не получится до следующего большого сдвига (и что этим сдвигом будет — как всегда, непонятно, wasm, может?..).


Вы писали что маркетолог из вас не очень — это потому что вообще мало из кого они очень. Маркетинг — это иллюзорная территория смыслов и образов и лучшие проводники там это Пелевин и Вергилий. Рациональному сознанию никогда не понять как может продукт с объективно лучшими характеристиками продаваться хуже, чем худшая альтернатива. Это вопрос (почти) полностью подсознания и чтобы победить на том уровне, надо или быть случайным счастливчиком или гениальным маркетологом.


Почитайте этих парней: https://www.facebook.com/ultimaconsultingrussia/posts/1857261411001865/, про стратегический маркетинг они всё расписали гениально. Особенно — их закон кристаллизации рынка, который я в двух словах описал в первом абзаце.


Если вы действительно хотите сделать идеальный UI-фреймворк, попробуйте найти ещё не столь сильно попиленную нишу как веб-фронтенд. Сейчас, например, всё ещё пытаются в нормальную кроссплатформу — React Native не особо взлетел, Flutter где-то там на этапе early adopters. Мне кажется, в той области $mol (или, как минимум, его подходы и философия) может блеснуть. Тот же mobx, как, думаю, вы знаете, сделал свою версию для Dart и Flutter, а у Вестстрейта ведь похожая ситуация (хотя mobx всё же сумел пробиться хотя бы на второе место на рынке управления состоянием в веб-фронтенде).


Зачем я это пишу всё? Да хз, просто в статье чувствуется какая-то ваша усталость и даже лёгкое отчаяние, а мне не хочется наблюдать как заебатые челы пытаются пробить лбом законы массового бессознательного.

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

Сдаётся мне что дело не в «религии», а в том что использовать готовую html вёрстку в $mol либо слишком сложно/больно, либо невозможно.

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


А вот что полезно — это умение общаться с заказчиком и объяснять, где накосячил дизайнер, где схалтурил верстальщик.


Так называемая "готовая вёрстка" в большинстве случаев такой треш, угар и содомия, что попытка исправить в ней все болячки — куда более сложный процесс, чем точно так же стилизовать собранное из компонент приложение.



Но, в данном случае, у меня есть претензии и к UX:


  • Неопрятный внешний вид.
  • Огромная никому не нужная шапка на пол экрана.
  • Дублирующиеся блоки.
  • Пагинация из 100500 кнопочек.
  • Потеря контекста при проваливании вглубь.
  • Выжигание глаз в ночное время суток.
Блин, вот почему все диалоги с тобой заканчиваются отмазками из разряда «я д'артаньян»? Задаю тебе вопрос об одном, ты переводишь тему на другое.

Короче делаю вывод — $mol спроектирован так, что не дает возможности переиспользовать готовую верстку и стили, без предварительной адаптации. Этот подход априори не подойдет 99% разработчиков, которые имеют отлаженный процесс разработки.

Да, наговнокодить на $mol сложно. Это была одна из целей его создания, чтобы он гарантировал некоторый уровень качества даже в неумелых руках:


  1. Отсутствие конфликтов стилей и проблем со специфичностью.
  2. Высокая степень настраиваемости.
  3. Высокая степень переиспользования кода.
  4. Консистентный внешний вид по всему проекту и даже по группе проектов.

$mol не про то, чтобы побыстрому налабать ценой потери качества, а про то, как сделать качественно минимумом усилий.

Странные утверждения, учитывая что примеры написанные автором этого «гениального» фреймворка всеми этими чертами ни разу не обладают. Ладно, думаю в этом кейсе дополнительная дискуссия не требуется.

Вообще-то обладают. По другому и быть не может, ибо это особенность фреймворка, а не конкретных приложений.

НЛО прилетело и опубликовало эту надпись здесь
Следите за руками. Вот такое приложение было создано всего за 2 часа:

Такое ощущение, будто фреймворк разрабатывался для того, чтобы создавать подобное приложение за 2 часа. Уверен, за тот же срок можно наклепать то же самое как на Vue, так и на React (за остальные либы не скажу).

А вы проверьте. Пока что только на Ember попробовали реализовать, но удалось лишь половину пунктов.

На челлендж откликнулся лишь один человек: https://twitter.com/vaier/status/1238528080433623042


На Ember за 2 часа ему удалось выполнить лишь половину пунктов: https://lifeart.github.io/demo-notes/


Как это выглядит


Остальные поворчали, что ТЗ неадекватно срокам и даже не стали пытаться.

Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории