Привет Хабр!
Меня зовут Алекс, и я автор фронтенд-библиотеки для создания UI-компонентов-агностиков - Symbiote.js. Я не единственный разработчик, но главный контрибьютор и тот, кто отвечает за концепцию, развитие, документацию, деврел, DX все остальное. Мейнтейнер то есть. Всем этим я занимаюсь в свободное от другой работы время, на которой я фуллстек, R&D-инженер и техлид.
Сегодня, я бы хотел рассказать о том, как появился Симбиот, и почему он вообще существует, при наличии огромного зоопарка библиотек и фреймворков для фронтенда, с куда более значительной аудиторией и поддержкой от крупных IT-компаний. Ведь мы, инженеры, очень НЕ любим, когда вокруг нас начинают плодиться лишние сущности, и сразу начинаем угрожающе размахивать бритвой Оккама. Верно? (хитро прищурился)
React
Свое первое приложение на React я делал много лет назад, когда тот еще не имел статуса лидирующего решения в отрасли и либы по дефолту. В те славные времена, я работал в команде стартапа, который создавал приложение для живого общения врачей с пациентами. Я пришел в проект на том этапе, когда базовые архитектурные решения уже были приняты, а технологии окончательно выбраны. Мое погружение в React было в жестком боевом режиме, когда, заодно с кодом, я прорабатывал и UX. Мои коллеги рассказывали мне какой React крутой концептуально, а мне не давала покоя одна мысль (ок, далеко не одна)...
Синтаксис JSX. Ведь это язык разметки. Для этого у нас ведь уже есть HTML. А еще, умные дяди и тети нас учили, что логику хорошо бы отделять от представления. А тут, все в кучу, и еще и с многоуровневыми взаимными вложениями... IDE глючит. Новый формат файлов, пока не очень хорошо поддерживается и подсветка синтаксиса постоянно ломается. Ломается и мозг, в сложных случаях. Да, да, я знаю, декомпозиция, но я-же работаю "в команде" а в команде, на декомпозицию могут быть разные взгляды.
А можно было получить, практически то-же самое, и обойтись простыми и ванильными HTML и JS?
Хорошо, держим этот вопрос в уме и идем дальше.
Virtual DOM. Да, нативный DOM браузера медленный, допустим. Это не совсем так, но допустим. Но разве, на этапе синхронизации виртуального DOM с настоящим браузерным, мы не используем тот-же самый DOM API, который, до этого, назвали медленным? То есть, мы родили новую сущность, которая не заменяет собой то, с чем мы "боролись", но теперь сама жрет память и другие ресурсы?
А можно было написать либу так, чтобы и с DOM работать эффективно, и новый ресурсоемкий огород ради этого не городить?
Это второй вопрос, который мы держим в уме.
Состояние. Есть локальное состояние компонента, с ним, вроде бы, все просто. А есть глобальное состояние приложения. Оно может быть довольно сложным, и само по себе, может быть подвергнуто декомпозиции: разделено на элементы, каждый из которых может иметь свои связи с остальными элементами.
К примеру, в вашем приложении может быть глобальный стейт, один из сегментов которого, будет выделен для хранения данных пользователя, другой - для хранения переменных локализации, третий - для определения текущего состояния UI, и так далее. У каждого виджета или микрофронтенда может быть свой стейт.
Плюсом ко всему, в работе с данными важна такая вещь как "согласованность" - у вас не должно возникать ситуаций, когда связанные сегменты состояния опираются на разные версии данных в один момент времени.
Но сами данные, при этом, могут иметь совершенно разные источники правды и причины динамических обновлений: что-то прилетает с сервера, что-то зависит от действий пользователя, а что-то получается через какой-нибудь сторонний API. Тотальная асинхронность - одна из основных сложностей фронтенда, всякие там race conditions и прочее такое.
На тот момент, Redux, как частичное решение вышеописанных проблем, уже существовал. А всякие обертки, для уменьшения бойлерплейта - еще нет. Контекстов тоже, как вы понимаете, не было. И мне было больно на это смотреть.
Рождались очередные вопросы. Типа такого: если в библиотеку уже встроен базовый механизм реактивности, почему не сделать его абстрактным, чтобы он-же решал и проблемы глобального стейта, без лишних зависимостей и адаптеров к этим зависимостям?
Svelte
У Svelte, в свое время, был довольно агрессивный маркетинг. Нам говорили, что это "исчезающий фреймворк". То есть, мы придумали для вас еще один, новый формат файлов, который, при обработке специальным компилятором, превращается в... чистый JavaScript! Фантастика!
А разве нельзя, кхм... ну, сразу писать на чистом JavaScript? Ну чтобы не тащить в проект новый (очередной) компилятор, новый (очередной) тип файлов, новый (очередной) синтаксис? Что, совсем-совсем нельзя без "черных ящиков"?
Ну ладно, давайте посмотрим на результат компиляции. Ага, вот у нас импорт базового класса... А вот еще простыня импортов. А вот описание структуры элементов... Ну, короче, вы поняли. Никакой особой магии и очередные вопросы в уме.
Next.js
Как-то раз, React-разработчики поняли, что полностью динамический SPA-сайт - это не всегда очень хорошо. Проблемы с индексацией, скоростью загрузки ассетов и с первичной отрисовкой UI... Бэкендеры смеются и тычут пальцем. Обидно. И родилась идея: а давайте притащим React еще и на бэкенд! Будем делать SSR! А для динамической части страницы, будем применять гидрацию. Или даже гидратацию. Вставим в разметку специальные маркеры и плейсхолдеры и оживим их на фронте в самый нужный момент. Красиво?
А у меня, что? Правильно, очередные вопросы.
А зачем, собственно, React на сервере?
Для формирования всего документа и его частей (а для сервера это, тупо, строки), нам достаточно простых советских... шаблонных литералов. А для вызова определенного поведения, определенных участков документа на клиенте, нет ничего лучше стандарта Custom Elements: вставил такой в любое место разметки - а он сам активировался, посмотрел вокруг через DOM API и реализовал любой интерактив.
И опять вопрос: а можно было решить вопрос на уровне базовых возможностей платформы и самого языка? Зачем городить очередной "черный ящик", который порождает самые неожиданные сложности в самый неподходящий момент? Зачем, в очередной раз, изобретать то, что есть и так из коробки и бесплатно?
Да, я понимаю, есть еще роутинг, права, кэш, всякие другие ассеты, кроме HTML... Но React то здесь каким боком помогает? Никаким. Просто мы не хотим знать ничего кроме React.
Lit
Выше я упомянул Custom Elements. А где Custom Elements - там и Lit: главная библиотека для работы с веб-компонентами от Гугл. Хорошая штука, которая выросла из проекта Polymer. Когда-то, ребята из Гугл сказали "Use the Platform!", и это был свет. Заодно, они чуть пропатчили саму "Platform", чтобы этот "Use" не вызывал много "Pain". Я искренне благодарен им за это.
Но дальше, они стали сами удаляться от платформы. Даже не удаляться, а отгораживаться абстракциями. Например, для работы с шаблонами, они используют свою магическую функцию html, которая перерабатывает основанный на HTML синтаксис, в специальный объект. И эта функция, накладывает сразу массу ограничений на то, как работает шаблонный литерал. Например, вы становитесь очень зависимы от контекста исполнения этой функции. И теряете возможность делать обычную строковую интерполяцию. Нам говорят: хотите что-то имплантировать в шаблон - создавайте новый экземпляр нашего специального объекта, и уже его, вставляйте в материнский шаблон.
А я хочу спросить: а можно было без этого? Ну чтобы шаблоны формировать и хранить как угодно, включая возможность использовать и оживлять разметку самого материнского документа?
Искусство компромиссов
Инжиниринг - это искусство компромиссов. Грамотное инженерное решение - это взвешивание большого количества "ЗА" и "ПРОТИВ", причем как для общего, так и для частных случаев. Мы все люди, и иногда, склонны переоценивать или недооценивать какие-то "ЗА" и какие-то "ПРОТИВ". Часть факторов может ускользать от нашего взора, по различным причинам. Любую технологию можно критиковать. Любая технология и решение - могут быть хороши в своем контексте, который может быть не всем очевиден и не до конца понятен людям со стороны.
Мы всегда чем-то немного жертвуем: удобством, производительностью, количеством лишних килобайт или концептуальной инженерной красотой. Иногда (часто), мы попадаем в ловушку иллюзий. Иногда, ради иллюзорных целей, мы делаем лишнюю работу и плодим лишние сущности. Как бороться с этим? Мой рецепт - задавать себе вопросы. На примере тех, которые я задавал в этой статье.
Моим ответом на эти вопросы стал Symbiote.js.
И да, так было можно.
P. S. Конечно же, я перечислил далеко не все вопросы и не все популярные технологии, которые эти вопросы вызывают. Надеюсь, у вас тоже есть вопросы, которыми вы поделитесь в комментариях.
Комментарии (52)
Gromilo
27.09.2024 11:06+1А зачем, собственно, React на сервере?
Я не настоящий фронтерндер, но понимаю так: один и тот же код выполняется и на клиенте и на сервере.
Например, есть страница каталога. Её можно открыть сразу со всем содержимым, а можно по навигации перейти на неё и получить данные запросом к апи. А код хождения в апи один и тот же.
i360u Автор
27.09.2024 11:06+1А код хождения в апи один и тот же.
Но React то здесь причем? Код хождения в API и рисование UI - это же вещи ортогональные. Вам никто не мешает использовать общий код и без React.
Gromilo
27.09.2024 11:06+1И средства отрисовки одни и те же, и стейт перетекает бесшовное. Т.е. ещё и шаблоны одинаковые.
i360u Автор
27.09.2024 11:06+2Да, шаблоны одинаковые. Почти. Но если вы хотите использовать HTML а не JSX, то не одинаковые. Я пишу о том, что JSX - это сущность, которую можно сократить без особого ущерба для дела. Но React-разработчикам, конечно, удобнее когда вокруг один сплошной React. С этим я не спорю.
gun_dose
27.09.2024 11:06Только всё это очень сильно бьёт по производительности. По сути дела, когда в нексте появился SSG, это надо было понимать так: "ребята, мы сделали тормознутого монстра и никак не можем его ускорить, поэтому держите статику".
savostin
27.09.2024 11:06Открыл, увидел
<button ${{onclick: 'increment'}}>Click me!</button>закрыл. Функция по имени - детский сад какой-то.
i360u Автор
27.09.2024 11:06+2Я очень рад, что вы так быстро во всем разобрались. Однако, приведенный вами пример - это то, как работает функция-хелпер (ее использование не обязательно), которая преобразует объектную нотацию в следующий вид:
<button bind="onclick: increment">Click me!</button>А это уже - просто HTML-строка, которая использует значения HTML-атрибутов для описания биндингов. Чем эта строка интересна? А тем, что она парсится нативным браузерным парсером и преобразуется в DOM без использования каких-либо дополнительных обработок. А также, может быть полностью независима от контекстов экземпляров компонентов. Может формироваться любым способом, хоть на сервере, хоть на клиенте. Ну, то есть, это бесплатный SSR, если вы понимаете о чем я говорю.
Да, в Symbiote.js биндинги задаются по строковым ключам, это решает массу проблем. Не вижу в этом никакого детского сада.
savostin
27.09.2024 11:06Это создает одну большую проблему при разработке - очень легко ошибиться в имени. И никто не поможет найти эту ошибку.
supercat1337
27.09.2024 11:06Очень часто слышу этот аргумент. Интересно ваше мнение. А разве ошибки не выявляются тестами? И почему, например, во избежание ошибки не завести в коде отдельную строковую переменную, которая будет хранить значение идентификатора?
savostin
27.09.2024 11:06Хранить имена всех функций в константах? Отличное решение.
supercat1337
27.09.2024 11:06Отличное, при боязни ошибиться в имени. Вот ошибка в идентификаторе как раз самая простая, потому что тесты рухнут, если к ненайденному элементу будет обращение.
savostin
27.09.2024 11:06+2Я не могу ждать тестов. Я хочу в IDE автодополнение имени функции и ее параметров. И проверку типов. И не хочу заводить для каждой функции константу с ее именем. И следить, чтобы значение этой константы совпадало с именем функции. И хочу namespace.
Наверное я многого хочу...
DarthVictor
27.09.2024 11:06+1А при переименовании функции в 10 местах, тесты придётся запустить всего 9 раз.
Проблемы со строковыми константами возникают не при написании своего кода, а при рефакторинге чужого.
Хотя если компонент небольшой, то это не будет проблемой, конечно.
i360u Автор
27.09.2024 11:06И никто не поможет найти эту ошибку.
А с чего вы это взяли? В чем проблема, на уровне дизайна либы, выводить ворниниги или даже выбрасывать исключения в таком случае? В Симбиоте, в частности, реализована мягкая схема с ворнингами, все необходимое вы увидите в консоли.
В нашей практике, для комфортной работы оказалось вполне достаточно спеллчекера в IDE (в принципе очень помогает с опечатками) и вывода предупреждений. Планируем еще запились статический анализатор в будущем (с ИИ), но серьезно, даже без него все нормально работает и никаких проблем не вызывает в сложных приложениях.
fertilis
27.09.2024 11:06+2А можно ли на уровне шаблона сделать вызов с аргументами? Типа `bind="onclick: (e) => changeRoute('foo')"`.
Вообще, автор, спасибо тебе. Вполне годная библиотека. Попробую в каком-нибудь мелком проекте.
vojaganto
27.09.2024 11:06+1Чем больше я читаю про "продвинутый" фронтенд, тем больше это похоже на JSDD - job safety-driven development https://habr.com/ru/articles/169017/
i360u Автор
27.09.2024 11:06+1Так и есть. Но тут еще один момент есть, который относится к веб-разработке в целом: проблемы, чаще всего, решаются не на том уровне абстракции, где они имеют наиболее эффективное решение, а на том, где это решение требует наименьший уровень компетенций. Из-за этого плодятся всякие монструозные мета-платформы, типа экосистемы React.
DarthVictor
27.09.2024 11:06Чем больше я читаю про "продвинутый" фронтенд, тем больше это похоже на JSDD
и из статьи по ссылке
Фреймворконенавистничество — не стоит использовать популярные фреймворки и библиотеки, гораздо лучше написать свое решение под конкретные задачи. Ведь потом надо поддерживать продукт и возможно на эту роль понадобятся новые более дешевые разработчики. Куда проще найти на рынке разработчика со знанием популярных фреймворков, чем способных разобраться с самописными. А это значит, что вы надолго обеспечены работой.
i360u Автор
27.09.2024 11:06+2Статья по ссылке интересная, в целом, но в ней есть и много очень спорных пунктов. Этот - спорный. В общем случае, мысль правильная, но если ее возвести в абсолют - то в мире должен существовать только один фреймворк - самый первый (а не самый лучший). Возведение каких-то вещей в абсолют - грех гораздо более страшный для разработчика, чем любое фреймворкотворчество и велосипедостроение. Все популярные либы и фреймворки когда-то были самописными велосипедами.
И мне нравится как многие, при обсуждении этого вопроса, исключают из контекста такие вещи как производительность, размер, количество зависимостей и так далее. Популярная либа может весьма сильно проседать по этим параметрам, а вашей целью может быть напротив - максимальная эффективность и технические требования, а не то, насколько ваше решение соответствует мнению большинства. И цифры - могут быть серьезным аргументом в пользу условного велосипеда.
Ну и обеспечивать себя (и других) работой - далеко не самая плохая идея.
DarthVictor
27.09.2024 11:06Всё так, но тут есть проблема, что если вы используете, что-то нестандартное, то оно должно быть либо популярным, либо очень тонким. Вы lit частично в этом обвиняете, кстати.
С другой стороны, я не считаю API Custom ELements заменовй Vue / React / Svelte. Скорее как общий знаменатель библиотеки компонент.
i360u Автор
27.09.2024 11:06+2Я и призываю к использованию стандартного: стандартного HTML, стандартного JavaScript, стандартного DOM API, стандартных importmaps, стандартных Custom Elements, стандартного template literal, стандартного патерна Pub/Sub и так далее.
alexnozer
27.09.2024 11:06+2Вот это то, что мне не нравится во многих фреймворках. Код нужно писать в специально придуманном файле. Для подсветки синтаксиса нужен специальный плагин с Language Server и IDE, которая поддерживает плагин. Разметку нужно писать на специальном диалекте при наличии HTML. Для стилей нужны какие-то пакеты, иначе нельзя писать CSS. Вместо JavaScript нужно писать на каком-то мета-языке. Для перехода между страницами нужен ещё один пакет, потому что нельзя использовать a[href]. И чтоб всё это заработало, ещё нужен сборщик, десять плагинов для него, пять конфигов, npm и node нужных версий и 5 минут билда. Утрирую, но суть примерно такая.
DarthVictor
27.09.2024 11:06стандартного патерна Pub/Sub
А это какого, если не секрет?
стандартного HTML
А у стандартного HTML есть шаблонизатор?
Arlekcangp
27.09.2024 11:06Не соглашусь. Я не фронтэндер и давно за развитием js не слежу, так что могу и ошибаться, но здесь действительно сделана попытка развить прорывную идею компонентов для web, приблизив их реализацию к стандартным средствам. Реакт на момент появления был отличным вариантом. До него все компонентные фреймворки хромали на одну или обе ноги, т к компонент в них мог жить только в очень приспособленном для него окружении. (Вспомните первые фреймворки для spa типа underscore, там вообще деления на компоненты по факту отсутствовало. Помню ещё очень тяжеловесный ember.js и не менее тяжёлые платные варианты, если не путаю, Ext.js. Медленные, сложные, неудобные...) И тут выходит реакт... Начисто сметая ангулар от гугла первой версии, по всем показателям. (Что и показало время) На тот момент много из того, что автор использует в своём фреймворке в стандартах не было. Поэтому реакт был более чем совершенен. Сейчас возможно настало время пересмотреть концепцию в сторону большей стандартизации. Понятно, что одному человеку вряд ли удастся конкурировать с корпорациями, но это не повод ничего не делать. Ведь и реакт создали не с чистого листа. Это продукт эволюции идеи компонентов в web.
qbz
27.09.2024 11:06+4Небольшой совет: укажите прямо, четко и ясно, прямо сразу же и в лоб, в двух-трех емких предложениях что это такое и зачем оно мне нужно как разрабу. На сайте я вижу лишь, что вышла новая версия Симбиота и много разделов. Ни один из них не называется или что-то в этом духе. Окей, жму докс. Там сразу как установить и прочий онбординг. А если я просто хочу узнать что это такое? К сожалению, маркетинг проектов от нас, программистов, зачастую страдает или его вообще нет, так как прежде чем "войти во вкус" и сказать на сколько вы крутые 70% людей бросит это даже не начав из-за таких вот мелочей.
tuxi
Я так и не понял, в итоге Symbiote.js умеет в SSR или нет?
i360u Автор
Да.
tuxi
Вопрос от нефронтендера и не совсем по теме статьи:
При прочих равных, на какой из существующих сейчас технологий фронтенда легче всего сделать наиболее производительный SSR ?
bubji9
Отрендерить на бэкенде и отдать html, который подхватится js’ом в браузере.
Если из js фреймворков смотреть, то svelte умеет компилировать компоненты под ssr - там вместо работы с dom(а на сервере это будет какая-нибудь его эмуляция), будет работа со строками, что довольно шустро.
i360u Автор
Симбиот это гораздо лучше и проще делает.
tuxi
Я понимаю, что детали важны, но если говорить упрощенно:
Вот нужно, чтобы фронт выдерживал 400..500rps, при среднем размере страницы 800кб...1100кб, без какого-либо существенного кеширования. Будем считать, что бэк тратит не больше чем 50..100мс на генерацию данных. Текущее значение вложенности нод в хтмл наверное нет смысла сейчас озвучивать как я понимаю.
Это какое железо навскидку потребуется под решение ssr на svelte js ?
venanen
400 rps это не так много, ssr умеет в кеш. В принципе, если это не самый-самый дешевый сервер, то этому требованию удовлетворит любой фреймворк.
DarthVictor
Я своих тестов не делал, но везде где видел, SSR самого React, будучи самым тормозным, показывал результат максимум раза в два медленнее, чем хороший серверный шаблонизатор.
Например
https://blog.platformatic.dev/ssr-performance-showdown
https://malloc.fi/performance-cost-of-server-side-rendered-react-node-js (старая статья)
Скорее всего вы упрётесь в производительность в другом месте.
wisead
Бери Nuxt.js, не пожалеешь.
i360u Автор
Очень спорно.
wisead
Аргументы? В чем спорность?
i360u Автор
В моей статье есть аргументы, просто подставьте Vue и Nuxt в нужные места: очередной черный ящик, очередные абстракции поверх ненужных абстракций. В браузере вы видите нечто очень далекое от исходников, что затрудняет дебаг. Я хочу сам контролировать то, как и что у меня собирается и подключается к странице. Честно говоря, очень достали все эти случаи, когда то стили подгружаются в неправильном порядке, то скрипты, то в дев-режиме все работает а в проде - сломано.
При этом вы утверждение "не пожалеешь" делаете без аргументов.
wisead
Смешные аргументы в вашей статье) Если руки растут откуда надо, то все решаемо и более того не исключено что проблемы которые вы описываете дело ваших же рук. Аргументы ЗА nuxt.js - это куча проектов в продакшне, известные платформы которые используют именно эту технологию и тем самым инвестирует в ее развитие, что то я не припомню ничего что было бы реализовано на симбиот.
Mr_FatCat
кажется, вы слишком придираетесь к молодой библиотеке. Да, у проверенных технологий за плечами много реализованных проектов, но это не значит, что нужно зацикливаться только на них. Автор предлагает новый подход, который может реально оптимизировать работу и снизить затраты на разработку. К тому же, если посмотреть на статистику, эта библиотека показывает хороший рост в использовании. Понятно, что всё новое часто встречает сопротивление от тех, кто привык к старому и не хочет вникать в новое. Но это же не повод предвзято относиться к свежим идеям, особенно не углубляясь в суть проблемы. Хороший разработчик решит задачу на любой технологии, но именно то, как он это делает, отражает его инженерный склад ума.
wisead
Ну во - первых а с чего вы взяли что я против нового? Я вообще никого не трогал) Проходя мимо просто ответил человеку на вопрос, что для задач с ssr я рекомендую nuxt, можно посмотреть выше.
Во - вторых на счет сопротивления и не желания вникать в новое) Если вникать во все новое что появляется каждый день у тебя жизни не хватит что бы во всем разбраться, тут ключевое слово РАЗОБРАТЬСЯ. Тут хорошо бы еще понять в чем вы лично хорошо разбираетесь Mr_FatCat? Причислили себя к тем кто идет в ногу со временем, а того кто решил немного поспорить с тем кто как раз таки пытался сказать что существующий инструмент плох - вы отвели к категории людей которые не хотят ни в чем разбираться?)
В-третьих - на счет хорошего разработчика - я как раз об этом и говорил, что хороший программист возьмет интсрумент и решит задачу. Понятно что задачу можно решить разными способами и с помощью разных инструментов. Но как показывает опыт, разработчик который в своей работе постоянно меняют тех стэк - не являются хорошим специалистом ни в одном из выбранных им инструментов. Собственно поэтому на рынке больше ценятся специалисты узкой направленности.
tuxi
Вопрос аналогичный тому, что выше - насколько хорошо nuxt.js впишется в те условия?
wisead
Если речь про 400 - 500 rps, и если учесть что статика ляжет на плечи nginx, то справится и на вполне бюджетном железе