Здравствуйте, меня зовут Дмитрий Карловский и я.. автор самого крутого на текущий момент (и в ближайшем будущем) фреймворка $mol. Вот уже десяток лет я рассказываю о заложенных в него идеях, которые конкуренты, если и пытаются повторить, то получается у них плохо. За это время вокруг него сложилось множество мифов, которые люди с радостью ретранслируют друг другу для самоуспокоения. Что ж, давайте соберём их все вместе, разберёмся, как они возникли, и как обстоят дела на самом деле.
Далее идёт развеивание мифов, касательно разработки "на $mol" в сравнении с разработкой "на React", как типичной ситуации в индустрии. Но вместо React вы смело можете подставлять любой другой его аналог.
🥴 $mol конкурирует с React
В то время, как React решает лишь одну проблему (обновление DOM) и делает это плохо, $mol представляет из себя экосистему из множества лучших в своём классе ортогональных библиотек, объединённых грамотной архитектурой. На самом деле $mol конкурирует не с самим React, а с тем фреймворком, который каждая компания неизбежно создаёт "на React". И каждый такой фреймворк — это как правило уникальная снежинка, созданная прикладными разработчиками без сколь-нибудь существенного опыта в проектировании фреймворков. Не редко таких людей называют "react-архитекторами", подчёркивая узость их кругозора.
Когда разработчики говорят, что они разрабатывают "на VanillaJS", "на jQuery", "на Backbone", "на React", "на Svelte" и тд, то можете быть уверены, что на самом деле они разрабатывают свой собственный in-house фреймворк, в котором для одной из сотен задач используют известную библиотеку, чтобы к ним не было претензий по поводу траты кучи времени и денег на решение уже давно решённых другими проблем. Подробнее об этой беде рассказывается в выступлении: Как программисты дурят бизнес.
🥴 Автор $mol — дилетант
Опыт автора насчитывает более 20 лет коммерческой веб-разработки, половина из которых в крупных компаниях: Яндекс, Wrike, 1С, Deutsche Bank, SAPRUN, Газпром. Всё это время он не только исследовал чужие фреймворки, но и проектировал свои. Он изобрёл парадигмы Объектно Реактивного Программирования, Фрактального Тестирования и много чего ещё по мелочи. Написал сотни статей, десятки раз выступал на профильных конференциях и ведёт канал о компьютерной науке.
Разумеется всё это не делает его правым по всем вопросам, но и отмахиваться от его слов без вникания в их смысл тоже не стоит. То, что на первый взгляд кажется полнейшей глупостью, на деле может оказаться, наоборот, глубокой мудростью, не очевидной на первый взгляд.
Типичный же in-house разработчик начинающий проект "на React" хорошо, если пробовал что-то помимо React за свои лет 5 опыта. Возможно, конечно, это талант, стоящий на плечах гигантов, но давайте будем реалистами: вероятность этого крайне мала, если у человека нет не только глубокого, но и широкого, и продолжительного опыта в своей сфере.
🥴 Автор $mol — токсик
Автор $mol — искренний человек, отвечающий уважением на уважение и сарказмом на ложь. Он не скован корпоративными ограничениями, поэтому может позволить себе говорить всё, что думает. И если собеседник ведёт себя как умалишённый (и порой даже гордится этим), то автор не стесняется давать ему адекватную обратную связь в виде высмеивания. Кроме того, часто суровая правда вызывает у людей негативные эмоции. И в них обвиняют принёсшего её гонца, называя его токсиком.
При этом у него нет конфликта интересов: он ценит своё время, поэтому создал инструмент, который его экономит. У in-house работника на зарплате же, основная цель — заработать денег, растягивая разработку. За показной вежливостью может скрываться деструктивное поведение, выражающееся в:
Продавливание технологий, в которых он разбирается (вместо поддержки лучших), чтобы подняться по карьерной лестнице.
Выбор не эффективных технологий, что раздувают штат, а человек растёт в звании, но бюджеты и сроки при этом необоснованно раздуваются.
🥴 Автор $mol — врунишка
На сайте и в этом треде в телеграме можно найти множество бенчмарков, где $mol всех побеждает, включая VanillaJS. Многих это, конечно же, смущает, ведь все привыкли, что повышение уровня абстракции обычно снижает производительность, а не повышает её.
Однако, никакого секрета здесь нет — бенчмарки объясняются во многих статьях. Суть в том, что $mol выигрывает не потому, что делает что-то быстрее других, а потому, что он достаточно умный, чтобы не делать ту работу, которую остальным делать приходится.
Например, благодаря автоматической виртуализации рендеринга время открытия приложения и отзывчивость его работы практически не зависит от объёма выводимых данных. Вручную, без абстракций, форсируемых фреймворком, это настолько сложно реализуемо, что никто даже не берётся.
В сторонних бенчмарках $mol, к сожалению, практически не появляется. Одни не знают про него, другие делают вид, что не знают, третие просто игнорируют его, считая недостойным даже упоминания.
🥴 $mol может умереть в любой момент
Что мертво умереть не может. $mol не просто существует и развивается вот уже десяток лет, но и всё ещё является технологическим лидером. Не благодаря маркетингу больших компаний, крупному бюджету или большому сообществу, а вопреки отсутствию всего этого.
В его архитектуру изначально заложена экосистемность и минимизация стоимости поддержки. А это значит, что даже смерть мейнтейнера, не остановит его развитие, ведь любой, освоивший разработку на нём, разработчик легко может поддерживать и сам фреймворк. Разработка на фреймворке ничем не отличается от разработки самого фреймворка.
Тем временем известные конкуренты появлялись и исчезали, как только прекращалась поддержка крупных компаний:
🥴 Сложно найти разработчиков на $mol
Разработчика на in-house фреймворке найти ещё сложнее. Но ничего, как-то же находят. Дело ведь не в том, чтобы в резюме разработчика были написаны ключевые слова, а в том, насколько хорошо он знаком с прикладной областью, и насколько быстро он освоится в архитектуре проекта, применяемых в нём инструментах и легаси коде.
$mol, при всей своей мощи, имеет крайне простую архитектуру. К разработке на нативном TypуScript он добавляет лишь MAM соглашения и пару абстракций: реактивную систему, позволяющую гарантировать заданные программистом инварианты; и лаконичный декларативный язык композиции компонент, однозначно транслируемый в JS при сборке.
Проще говоря, любой толковый TypeScript-разработчик легко освоит $mol, даже если с ним ранее никогда не работал. А бестолковых и нанимать не стоит.
🥴 Никто не ведёт коммерческую разработку на $mol
За $mol не стоит больших компаний и громких имён. Корпорации хотя и легко ведутся на хайп, но с трудом преодолевают свою инерционность. Как говорится: "скупой платит дважды, а тупой - трижды". Поэтому связываться с прогрессивными технологиями могут позволить себе лишь небольшие мало известные компании, которые не могут позволить себе тратить деньги впустую.
Тут можно найти информацию о некоторых из коммерческих проектов, реализованных на $mol, и истории успеха, где использование $mol позволило занять призовые места. Но это всё мелочи, мы больше ориентированы на создание своих продуктов на собственной платформе, хотя и продолжаем ещё делать проекты на заказ.
Нашим заказчикам нравится, что разработка на $mol идёт быстрее, но при этом получается ещё и более качественный результат. А секрет не только в том, что у разработчика остаётся больше времени, чтобы продумать разные кейсы, но и в архитектуре, которая форсирует хорошие практики так, что сделать хорошо проще, чем сделать плохо, но при этом не ограничивает возможность реализовать любую смелую идею.
🥴 $mol слишком сырой
$mol состоит из множества ортогональных библиотек. Какие-то из них являются proof-of-concept, а какие-то не меняются уже годами. Не потому, что легаси, а потому, что имеют лишь одну задачу и делают её хорошо.
Как и в любом большом проекте, в $mol есть шероховатости: то какой-то компонент рендерится неопрятно в каком-то браузере, то в каком-то модуле куцая документация с полтора примерами, то ещё что. Всегда есть к чему придраться, но всегда есть и чем восхититься.
И тут уже каждый решает сам: отказаться от достоинств $mol библиотек, героически борясь с более другими; или же помочь сделать их ещё лучше, чем они уже есть, поблагодарив тем самым авторов за то, что они сэкономили вам время и деньги.
В целом же, если сравнивать результат работы больших команд в больших компаниях на популярных технологиях с теми проектами, что полтора землекопа делают на $mol в гораздо меньшие сроки, то на $mol получается более предсказуемый и качественный по всем показателям результат.
🥴 У $mol плохая поддержка
Странно ожидать забесплатно хорошей поддержки. Тем не менее за $mol стоит не большая компания, с кучей бюрократии и толпой людей, которым плевать на проект, а заботливый родитель, не равнодушный к судьбе своего детища. Так что ситуация с фиксом баг-репорта за пол часа — у нас довольно типична.
А вот типичная ситуация для больших компаний — годами игнорировать баги в базовой функциональности (вынуждая разработчиков придумывать костыли), а потом автоматически закрывать баг-репорт ботом из-за долгой неактивности.
Разумеется, и у нас не всегда всё так радужно, и у других не всегда всё не так плохо. Однако, важно подчеркнуть, что команда энтузиастов постарается вам помочь даже при недостатке ресурсов. В то же время, людей на заплате ваши проблемы интересуют в самую последнюю очередь. Это диаметрально противоположные мотивационные системы.
Так что если вы приходите без уважения к проделанной работе, без благодарности за полученную выгоду, без чуткости к обоснованию принятых решений, но с требованием сделать именно так, как нужно именно вам, то не удивляйтесь, что вместо бесплатной работы на вас, вам будет предложено сделать всё самостоятельно. А то и лишь в своём форке, если ваше видение "как правильно" отличается от видения мейнтейнеров.
🥴 У $mol нет документации
Разумеется, она есть. Безусловно, она могла бы быть и лучше. Мы всё ещё ждём того шеф-повара, который сделает из неё конфетку, которая всем придётся по душе. Тем не менее, стоит отметить её главное достоинство: она состоит из множества обстоятельных статей, которые прокачивают разработчика не столько в разработке на $mol, сколько в веб-программировании вообще. Их чтение расширяет кругозор и углубляет понимание, что полезно, даже если в конечном счёте разработка будет вестись на иных фреймворках.
Кроме того, в условиях ограниченных ресурсов, код в $mol пишется таким образом, чтобы его легко было исследовать, даже не читая документацию: все модули небольшие и сконцентрированы на одной задаче, минимизирована копипаста и бойлерплейт, все состояния легко доступны в рантайме, все сущности имеют уникальные глобальные семантичные имена и тд.
🥴 У $mol замкнутая экосистема
$mol предоставляет широкий набор лучших в своих классах библиотек. Это делает фреймворк самодостаточным, но не изолирует от других экосистем. Прежде всего это экосистема MAM, позволяющая легко использовать модули из любых других проектов. В частности, в ней есть неймспейсы $node, позволяющий напрямую использовать любые NodeJS, и $lib, предоставляющий адаптеры к модулям из NPM.
И наоборот, любой MAM-модуль одной командой собирается в независимый NPM-пакет. В NPM реестре полно таких пакетов с бандлами как в JS, так и в MJS форматах, с декларациями типов и прочими плюшками.
Эти интеграции хотелось бы сделать ещё более прозрачными. Но ценности в них не то чтобы много, ибо качество кода в реестре NPM на порядок ниже.
🥴 У $mol нет поддержки в IDE
Поддержка IDE не такая широкая и глубокая, как хотелось бы, но она есть. VSCode — самая популярная IDE. И для неё у нас есть несколько плагинов, которые она автоматически и предлагает установить.
Это nin-jin.vscode-language-tree, предоставляющий подсветку синтаксиса для всех языков, основанных на формате Tree, и stan-donarise.view-tree-language, реализующий навигацию и подсказки во view.tree файлах. А весь остальной код — это обычный TypeScript, который и так поддерживается VSCode лучше всего.
К сожалению, у других IDE ситуация с поддержкой Tree чуть по хуже, но для многих из них есть хотя бы базовая подсветка синтаксиса.
🥴 У $mol высокий порог входа
Архитектурно $mol крайне простой, так как основан на минимальном числе простых, но мощных абстракций, форсирующих лучшие практики. Это позволяет новичкам во фронтенде писать готовый к продакшену код уже через пару недель.
Тем же, кто уже вложился в HTML и тем более во что-то типа React, приходится переучиваться — это существенно сложнее. Кроме того, обманчивая простота перехода с HTML на React, скрывает истинную сложность доведения проекта от концепта до продакшена. Писать качественный код на React cложно, а порой и не возможно. Если вы замечали, как сильно тормозит и глючит новый упрощённый интерфейс VKontakte, то это именно оно — когнитивная сложность, с которой не справляются даже отборные представители индустрии.
🥴 У $mol некрасивый дизайн
Стандартные компоненты намеренно выполнены в максимально аскетичном стиле, чтобы их легко было встраивать в другие дизайны, минимально борясь с дефолтным визуалом, задача которого быть опрятным, приятным и ненавязчивым, с которой он прекрасно справляется.
Тем не менее, касательно дефолтного внешнего вида мнения разнятся от "фу, какой страшный", до "вау, давно искал чего-то подобного", что даёт уверенность в том, что неприятие со стороны некоторых людей связано с личными вкусом или привычками. А всем сразу не угодить, да это и не является целью. Основной упор мы делаем на удобство и практичность, исповедуя принцип "лучший дизайн — тот, что ты не замечаешь".
🥴 Все сайты на $mol выглядят одинаково
Одной из ценностей, предлагаемых $mol является наличие богатой библиотеки стандартных компонент, позволяющих быстро создавать опрятный интерфейс даже профану в области дизайна. Так что в подавляющем большинстве случаев разработчику нет необходимости менять дизайн, ведь менять его - только портить. Поэтому многие приложения выглядят похоже. Особенно те, что созданы гильдей Гипер Дев.
Тем не менее, в отличие других библиотек компонент, архитектура $mol форсирует беспрецедентную настраиваемость не только визуала, но и композиции, и даже поведения. Это даёт богатые возможности по их кастомизации при необходимости. Тут можно найти галерею различных дизайнов, реализованых на $mol.
