Недавно под постом в канале 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 признали сначала в мире, а потом уже в России и начали копировать и использовать. Я считаю так.
Потому что своё в россии мы продвигать не хотим, зато лучше возьмём какое-нибудь чужое распиаренное решение, пусть и похуже. Очень грустно от этого, господа.
