Комментарии 12
Все эти чисто нативные решения без дев-сервера, и т.д. и т.п. упираются в то, что код писать на них тупо неудобно.
Вот еще несколько моментов:
1. Сервер все равно есть всегда, без сервера тупо не работают многие вещи по причинам безопасности. Почему бы и не быть дев-серверу. Собственно, в Polymer/lit довольно быстро дошли до этой мысли и последние пару лет dev-сервер там есть как и этап сборки.
А если дев-сервер все равно есть, то почему бы не использовать его по полной программе, со всеми плюшками типа target для кроссбраузерности, всевозможных препроцессоров, ленивой загрузки и т.д. Банально на чистом CSS писать крайне неудобно, а для препроцессоров нужен сборщик.
2. Ты говоришь, что шаблонизатор HTML, но это не так, это видно по первому же примеру:
MyComponent.template = /*html*/ `
<h2>{{count}}</h2>
<button set="onclick: increment">Click me!</button>
`;
Это какой то самодельный примитивный шаблонизатор. Если шаблонизатор все равно есть, то почему бы не взять какой то более продвинутый.
3. Синхронные обновления DOM без батчинга там где он нужен = привет тормоза.
4. BaseComponent это тот же рантайм. Хотя здесь вижу плюс, что он маленький и загружается один раз засчет кеширования импортов.
Одним словом, каких то супер-плюсов по сравнению с альтернативами здесь нет, кроме тонкого рантайма. В остальном все хуже. Настолько ли даже пара метров core-бандла какого нибудь фреймворка плохи, чтобы отказываться от на порядок более удобного удобства разработки?
Вы как-то все неверно поняли.
Сервер конечно нужен, но сервера бывают очень разные. Бывают сервера такие, как на GitHub pages, где модули резолвятся только по относительным путям или через https. Бывают локальные дев-сервера, где для хот-релоада добавляются какие-то сущности в ваш документ, которые вам могут мешать в определенных ситуациях (например, когда вы гоняете тесты в Puppeteer). Бывают сервера, решающие другие специфические задачи, как в случае с LitElement. Никто не предлагает отказаться от серверов и удобства. Просто с Symbiote - у Вас все будет работать во ВСЕХ перечисленных случаях, он - серверный агностик. В отличие от LitElement. Кто Вам не дает использовать любые пост/препроцессоры я тоже не очень понял.
Это именно HTML, потому, что браузер это парсит как HTML. Наличие меты для постобработки не делает шаблон чем-то принципиально иным. Еще раз уточню: сначала создается участок DOM, именно в стандартном объектном представлении, а потом обрабатывается как DocumentFragment. НЕ шаблон. Именно поэтому, это не шаблонизатор, во всяком случае, в общепринятом представлении.
Никто не отменяет батчинг там, где он нужен. А вот использование батчинга там, где он не нужен - это и есть "привет тормоза". Вообще, мы очень внимательно следим за производительностью и гоняем бенчмарки. Symbiote вносит обновления быстрее чем те либы, которые батчинг используют безальтернативно, это просто факт. Про бенчмарки я тоже планирую написать, в одну статью всего не засунешь.
BaseComponent, наверное, можно назвать рантаймом, с натяжкой. Но это не непрозрачная абстракция, как у других.
В остальном все хуже.
Кроме перечисленного, еще какие-то аргументы есть?
Настолько ли даже пара метров core-бандла какого нибудь фреймворка плохи, чтобы отказываться от на порядок более удобного удобства разработки?
Во первых, настолько. И вес - при всей значимости, далеко не единственный фактор, об остальных я также писал.
С чего Вы решили, что все плохо с удобством разработки, да еще и на порядок, я тоже совершенно не понимаю. Мы уделяем этому вопросу много внимания, и активно собираем фидбек от тех, кто пробовал все это использовать.
Сразу скажу, что ни в коем случае не хотел обидеть. Мне нравятся разработки на основе веб-компонентов, включая вашу. То, что я описал выше это именно то, с чем столкнулся я сам используя похожие на вашу технологии, поэтому и написал для тех, кто еще не пробовал.
1. Про сервер я писал в ответ на следующее заявление: «Вы можете писать свой код и сразу видеть результат в браузере, без установки каких-либо специфических зависимостей: компиляторов, специальных dev-серверов и прочего». Я говорю, что не будет такой ситуации, когда описанное будет преимуществом. Звучит красиво, но без этапа сборки писать код неудобно, без дев-сервера в большинстве ситаций просто невозможно — работа с JS через файловую систему налагает кучу ограничений. Подобные рекламные заявления делали разработчики Polymer в свое время, но больше не делают по описанной выше причине.
Ну а если появляется этап сборки и дев-сервер, то у React/Vue и прочей братии тут все гораздо лучше в плане обвеса и возможностей.
2. Я понимаю, что этот выбор сделан чтобы уменьшить нагрузку на js-рантайм, т.к. такой шаблон действительно парсится нативно браузером, но повторю свое мнение — это крайне снижает удобство разработки. Например вот это «set='onclick: increment'» если я правильно понял, вынуждает передавать название обработчика в виде строки, что убивает рефакторинг и кучу функуционала в IDE. С точки зрения разработчика это именно то, что я написал в первом комменте — примитивный шаблонизатор.
3. По производительности действительно надо смотреть и тестить, тут согласен.
4. Да такая же как и везде, просто меньше по объему и проще. За что приходится платить DX как у фреймворков допотопного поколения.
Кроме перечисленного, еще какие-то аргументы есть?
Поштучно их много, да тот же Shadow DOM — он не только изолирует стили, но и затрудняет доступ к глубоко вложенным элементам формы извне и мешает SSR. Но мой основной посыл не в этом, а в том что сама эта концепция — максимальное стремление к нативности и отсутствию зависимостей — это путь в никуда. Плюс будет один (в весе), а минусов сколько фантазии хватит.
Ну и я специально старался не зацикливаться на аргументах по отсутствующую вокруг фреймворка инфраструктуру в виде кучи библиотек и прочего, так как очевидно что ее пока нет. Но это же тоже минус.
С чего Вы решили, что все плохо с удобством разработки, да еще и на порядок, я тоже совершенно не понимаю. Мы уделяем этому вопросу много внимания, и активно собираем фидбек от тех, кто пробовал все это использовать.
Я так решил, потому что посмотрел на примеры кода, а также потому, что я писал крупный проект на lit, которым вы точно вдохновлялись, ну потому что пробовал на живых проектах много других фреймворков — React, Angular, Vue и мне есть с чем сравнить.
Инжиниринг - это искусство компромиссов. Мы всегда платим чем-то за что-то. Практически всегда у нас либо "толстая броня", либо "высокая мобильность". Мы все все свои решения взвешиваем на весах. Все эти компромиссы определяются контекстом и теми рамками, в которых ваше решение должно работать.
Я повторю, что Symbiote - это про симбиоз. Он не позиционируется как очередная библиотека общего назначения, которых сейчас и так достаточно. Да, его можно использовать для создания обычных приложений, но в тех рамках, для которых создан Symbiote, у него вообще нет прямых конкурентов.
Фишка симбиота не в том, что он лучше или хуже React или Vue и представляет какую-то альтернативу их развитым экосистемам, а в том, что он может дружить с Vue и React и всеми остальными одновременно. Вы можете рендерить шаблоны Симбиота прямо в Реакте. И на сервере. Вы можете создавать API, для работы с которыми, вашим пользователям не нужно вообще писать ни строчки на JS. И это будет работать и в Wordpress, и с Jamstack и в других местах.
Вы апеллируете к своему опыту, ок. Но я и себя могу назвать "динозавром" в этой теме. Я работаю со стандартами из группы веб-компонентов еще со времен первых черновиков, и посвятил много времени изучению самых разных подходов. Мне тоже есть с чем сравнить, от современных либ до совсем древних.
Если вернутся к более предметному обсуждению, то опять же, Вы пишите про трудности работы с Shadow DOM, при том что именно этот же аргумент использовал и я. Как можно записать это в недостатки, если в Симбиоте нет Shadow DOM по умолчанию (включается флагом, только при необходимости)?
Ну и так далее, вы рубите с плеча не разобравшись.
Вы апеллируете к своему опыту, ок, но я и себя могу назвать «динозавром» в этой теме. Я работаю со стандартами из группы веб-компонентов еще со времен первых черновиков, и посвятил много времени изучению самых разных подходов. Мне тоже есть с чем сравнить, от современных либ до совсем древних.
Так я привел несколько конкретных примеры в комментах без всякой аппелляции к опыту — не реально работать без этапа сборки и дев-сервера, отсутствие поддержки чего либо кроме строк при передаче через аттрибуты HTML, отсутствие внятных плюсов при реализации UI-библиотеки. И не получил на них ответа.
Не хочется тратить время на продолжение обсуждения, не получая ответа на даже очевидные сходу вопросы.
Ну хорошо, давайте разберем не юзкейсы, как ниже, а постановку задачи, ведь как понимаю вся последующая статья это попытка ее решения:
Существует простой и распространенный подход к интеграции виджетов: мы даем указать, через созданный нами API, элемент-контейнер, в который и добавляем всё необходимое.
Да, точно также работают и веб-компоненты, которые использует ваша библиотека. Разница лишь в том, что в вашем случае часть забот берет на себя браузер.
И все у нас хорошо, пока не выяснится, что пользователь-интегратор — использует стили, которые глобально влияют на все элементы определенного типа на странице… И вот, вы должны позаботиться о защите CSS, но таким образом, чтобы дизайн вашего решения можно было настроить снаружи каким-то вменяемым способом...
Нормальный способ изоляции себя от внешних стилей, которые мы не контролируем — Shadow DOM. Это браузерное апи, и его поддержка есть во многих фреймворках, а если ее нет, то компонент-враппер прячущий стили создается от силы за полчаса.
А потом, вы выясните, что цикл рендеринга хост-приложения влияет на то, как ваш виджет инициализируется, и вам нужно будет объяснить пользователю, как и когда вызывать методы вашего API для того, чтобы не возникало никаких «гонок» и прочих «cannot read property X of undefined».
В любом современном фреймворке можно управлять жизненным циклом компонента. Причем удобнее, чем с помощью нативных методов веб-компонента, ибо более высокоуровнево.
А ещё, вам может понадобиться отобразить одну часть интерфейса в одном месте хост-приложения, а другую часть — в другом, и в разное время...
Порталы в реакте, аналогичный функционал в других фреймворках.
А ещё, пользователи вашего виджета захотят его настроить под свои особые требования, изменить дизайн, включить или выключить какие-то функции...
Все это есть в любом современном фреймворке.
В общем, никакие классические и консервативные подходы, достойных ответов, на эти вопросы, не дают.
В свете вышенаписанного, совершенно неочевидный вывод. В итоге непонятно, какая задаче решается.
Если речь про фреймворко-независимые компоненты в гибридных приложениях, где намешаны React/Vue/прочие ангуляры, то вроде идея и красивая — наделаем на Symbiote компоеннтов, а в других частях обернем их во врапперы и все будет красиво. А на деле это будет +1 технология в проекте.
Если на проекте есть React, то можно сделать тоже самое на React, нулевой ценой на частях приложения, уже написанных на реакте, и ценой core-бандла + самих standalone-компонентов на реакте, опирающихся на этот core, на остальных частях приложения. Вместо реакт подставьте любую другую технологию _уже_ использующуюся на проекте.
Если речь про встраивание в хроническое server-page легаси, то получается нет никакой проблемы дружить что-то с чем-то. Берешь фреймворк по вкусу и делаешь как я описал выше.
В общем, мне кажется я более чем подробно сформулировал технические вопросы и вопросы по области применимости. Я бы хотел узнать ответы, прежде чем продолжать обсуждать другие технические моменты.
Так я привел несколько конкретных примеры в комментах без всякой аппелляции к опыту — не реально работать без этапа сборки и дев-сервера, отсутствие поддержки чего либо кроме строк при передаче через аттрибуты HTML, отсутствие внятных плюсов при реализации UI-библиотеки. И не получил на них ответа.
Я вроде ответил. Вы делаете предположения исходя из каких-то неверных предпосылок, а я пытаюсь понять откуда они берутся.
Еще раз, кто вас заставляет работать без сборки и дев-сервера? Во первых, это более чем реально, а во вторых, никто же не обязывает. Делайте как вам удобно, в чем проблема?
Использование строк удобно именно тем, что это строки. У вас есть широчайшие возможности по манипуляции ими. Это самый гибкий подход. Опять же, не совсем понимаю, в чем именно вы видите проблему. Лично у меня эти шаблоны вызывают меньше проблем, чем lit-html или JSX. И не только у меня.
Да, точно также работают и веб-компоненты, которые использует ваша библиотека. Разница лишь в том, что в вашем случае часть забот берет на себя браузер.
Эта разница настолько велика, что я даже не знаю что на это сказать. Веб-компоненты - это возможности композиции на уровне HTML и методы жизненного цикла, доступные изнутри, без необходимости контроля снаружи.
В остальном, вы продолжаете прямые сравнения с другими либами полностью игнорируя аргументы из статьи и базовый кейс - симбиоз. Какая вам разница, если вы делаете, к примеру, видео-плеер, какие замечательные возможности имеет фреймворк, на котором написано хост-приложение? Вам важно чтобы пользователь смог ваше решение использовать. При этом, вам желательно не делать отдельные интеграции для всего огромного зоопарка экосистем. И не поддерживать их по отдельности. Это просто очень затратно. И не втаскивать в чужие проекты монструозные зависимости.
- Виджеты
- Микро-фронтенды
- Элементы UI-библиотек
- Приложения-надстройки
Если мы стремимся к отсутствию зависимостей, то эта библиотека сработает только для кейса «Виджеты», которые делаются вне дизайн-системы.
Если это не так, а например для кейса «Элементы UI-библиотек» это не так, то у вас _будет_ отдельный core-бандл и никуда вы не денетесь и будете его тащить, либо будете дублировать пачки кода и стилей в виде копипаста от компонента к компоненту.
Для приличного размера дизайн-системы эти бандлы могут быть довольно большими, частая задачка которая мне попадается — выпилить material ui (у которого прям отдельный core-бандл в npm без котоого ничего не работает) или что-то подобное, и заменить более легковесным. Так вот даже если менять, все равно сам создаешь такой же бандл, просто уже меньше, и под нужды заказчика.
Да конечно, бандл фреймворка + бандл UI-либы это хуже, чем только бандл UI-либы по весу и нагрузке на скриптинг в браузере. Но звучит уже не так прикольно. Все равно что-то тащим и на что-то завязываемся, а значит вполне можно сравнивать с другими фреймворками, и тут сравнение уже кроме веса будет не в вашу пользу.
Далее кейс «Микро-фронтенды» — полагаю они отличаются от виджетов какой-то повышенной сложностью, возможно наличием роутинга. В общем без пояснения данный пункт не понятен, но выглядит как то что тут тоже будет отдельный рантайм для управления микрофронтендом. Просто меньше чем у того же реакта. Но и неудобнее.
По кейсу «Приложения-надстройки» тоже нужно поясление, не знаю что это такое.
По итогу получается что для UI-либы фреймворк предлагает нативность (которая непонятно что дает, так как все равно таскаем за собой абстракции, просто уже другие и потоньше) и за счет этого меньший объем загружаемого кода. Взамен этого забирает плюшки взрослых фреймворков. А если эти плюшки включать, то получается ухудшенная копия этих фреймворков.
предлагает нативность которая непонятно что дает
Нативность дает общие стандарты, которые будут справедливыми для всех экосистем. Иными словами, какие бы инструменты вы не использовали при разработке своего приложения, это будет преобразовано в DOM. И если вы переносите все взаимодействия на уровень DOM или иных самых базовых, для веб-платформы сущностей, таких как HTML и CSS - ваше решение может быть по-настоящему универсальным. Причем, это касается как рантайма, так и инструментов окружения разработки.
А для шаринга общих зависимостей без какого-либо дублирования, удобно использовать https-импорты в коде. Можно даже (нужно) настроить проект так, чтобы при этом была полноценная поддержка типов. Но это напрямую к теме не относится.
А для шаринга общих зависимостей без какого-либо дублирования, удобно использовать https-импорты в коде. Можно даже (нужно) настроить проект так, чтобы при этом была полноценная поддержка типов. Но это напрямую к теме не относится.
Можно. А можно и использовать возможности какого-нибудь нормального бандлера. Заодно можно будет не париться с относительными путями при написании кода и рефакторинге.
Ну и остальные перечисленные замечания вы пропустили. Вернусь в ветку, если появится что-то по существу.
Мне идея нравится, буду пробовать. Недавно делал виджет для выбора цвета автомобилей, столкнулся почти со всем что тут написано. Но доки мне тяжело пока изучать в таком виде.
Работаю фронтендером, как меня достал это фронтенд, это ужас просто
Мета-приложения и Symbiote.js