Comments 12
Вы как-то все неверно поняли.
Сервер конечно нужен, но сервера бывают очень разные. Бывают сервера такие, как на GitHub pages, где модули резолвятся только по относительным путям или через https. Бывают локальные дев-сервера, где для хот-релоада добавляются какие-то сущности в ваш документ, которые вам могут мешать в определенных ситуациях (например, когда вы гоняете тесты в Puppeteer). Бывают сервера, решающие другие специфические задачи, как в случае с LitElement. Никто не предлагает отказаться от серверов и удобства. Просто с Symbiote - у Вас все будет работать во ВСЕХ перечисленных случаях, он - серверный агностик. В отличие от LitElement. Кто Вам не дает использовать любые пост/препроцессоры я тоже не очень понял.
Это именно HTML, потому, что браузер это парсит как HTML. Наличие меты для постобработки не делает шаблон чем-то принципиально иным. Еще раз уточню: сначала создается участок DOM, именно в стандартном объектном представлении, а потом обрабатывается как DocumentFragment. НЕ шаблон. Именно поэтому, это не шаблонизатор, во всяком случае, в общепринятом представлении.
Никто не отменяет батчинг там, где он нужен. А вот использование батчинга там, где он не нужен - это и есть "привет тормоза". Вообще, мы очень внимательно следим за производительностью и гоняем бенчмарки. Symbiote вносит обновления быстрее чем те либы, которые батчинг используют безальтернативно, это просто факт. Про бенчмарки я тоже планирую написать, в одну статью всего не засунешь.
BaseComponent, наверное, можно назвать рантаймом, с натяжкой. Но это не непрозрачная абстракция, как у других.
В остальном все хуже.
Кроме перечисленного, еще какие-то аргументы есть?
Настолько ли даже пара метров core-бандла какого нибудь фреймворка плохи, чтобы отказываться от на порядок более удобного удобства разработки?
Во первых, настолько. И вес - при всей значимости, далеко не единственный фактор, об остальных я также писал.
С чего Вы решили, что все плохо с удобством разработки, да еще и на порядок, я тоже совершенно не понимаю. Мы уделяем этому вопросу много внимания, и активно собираем фидбек от тех, кто пробовал все это использовать.
Инжиниринг - это искусство компромиссов. Мы всегда платим чем-то за что-то. Практически всегда у нас либо "толстая броня", либо "высокая мобильность". Мы все все свои решения взвешиваем на весах. Все эти компромиссы определяются контекстом и теми рамками, в которых ваше решение должно работать.
Я повторю, что Symbiote - это про симбиоз. Он не позиционируется как очередная библиотека общего назначения, которых сейчас и так достаточно. Да, его можно использовать для создания обычных приложений, но в тех рамках, для которых создан Symbiote, у него вообще нет прямых конкурентов.
Фишка симбиота не в том, что он лучше или хуже React или Vue и представляет какую-то альтернативу их развитым экосистемам, а в том, что он может дружить с Vue и React и всеми остальными одновременно. Вы можете рендерить шаблоны Симбиота прямо в Реакте. И на сервере. Вы можете создавать API, для работы с которыми, вашим пользователям не нужно вообще писать ни строчки на JS. И это будет работать и в Wordpress, и с Jamstack и в других местах.
Вы апеллируете к своему опыту, ок. Но я и себя могу назвать "динозавром" в этой теме. Я работаю со стандартами из группы веб-компонентов еще со времен первых черновиков, и посвятил много времени изучению самых разных подходов. Мне тоже есть с чем сравнить, от современных либ до совсем древних.
Если вернутся к более предметному обсуждению, то опять же, Вы пишите про трудности работы с Shadow DOM, при том что именно этот же аргумент использовал и я. Как можно записать это в недостатки, если в Симбиоте нет Shadow DOM по умолчанию (включается флагом, только при необходимости)?
Ну и так далее, вы рубите с плеча не разобравшись.
Так я привел несколько конкретных примеры в комментах без всякой аппелляции к опыту — не реально работать без этапа сборки и дев-сервера, отсутствие поддержки чего либо кроме строк при передаче через аттрибуты HTML, отсутствие внятных плюсов при реализации UI-библиотеки. И не получил на них ответа.
Я вроде ответил. Вы делаете предположения исходя из каких-то неверных предпосылок, а я пытаюсь понять откуда они берутся.
Еще раз, кто вас заставляет работать без сборки и дев-сервера? Во первых, это более чем реально, а во вторых, никто же не обязывает. Делайте как вам удобно, в чем проблема?
Использование строк удобно именно тем, что это строки. У вас есть широчайшие возможности по манипуляции ими. Это самый гибкий подход. Опять же, не совсем понимаю, в чем именно вы видите проблему. Лично у меня эти шаблоны вызывают меньше проблем, чем lit-html или JSX. И не только у меня.
Да, точно также работают и веб-компоненты, которые использует ваша библиотека. Разница лишь в том, что в вашем случае часть забот берет на себя браузер.
Эта разница настолько велика, что я даже не знаю что на это сказать. Веб-компоненты - это возможности композиции на уровне HTML и методы жизненного цикла, доступные изнутри, без необходимости контроля снаружи.
В остальном, вы продолжаете прямые сравнения с другими либами полностью игнорируя аргументы из статьи и базовый кейс - симбиоз. Какая вам разница, если вы делаете, к примеру, видео-плеер, какие замечательные возможности имеет фреймворк, на котором написано хост-приложение? Вам важно чтобы пользователь смог ваше решение использовать. При этом, вам желательно не делать отдельные интеграции для всего огромного зоопарка экосистем. И не поддерживать их по отдельности. Это просто очень затратно. И не втаскивать в чужие проекты монструозные зависимости.
предлагает нативность которая непонятно что дает
Нативность дает общие стандарты, которые будут справедливыми для всех экосистем. Иными словами, какие бы инструменты вы не использовали при разработке своего приложения, это будет преобразовано в DOM. И если вы переносите все взаимодействия на уровень DOM или иных самых базовых, для веб-платформы сущностей, таких как HTML и CSS - ваше решение может быть по-настоящему универсальным. Причем, это касается как рантайма, так и инструментов окружения разработки.
А для шаринга общих зависимостей без какого-либо дублирования, удобно использовать https-импорты в коде. Можно даже (нужно) настроить проект так, чтобы при этом была полноценная поддержка типов. Но это напрямую к теме не относится.
Мне идея нравится, буду пробовать. Недавно делал виджет для выбора цвета автомобилей, столкнулся почти со всем что тут написано. Но доки мне тяжело пока изучать в таком виде.
Мета-приложения и Symbiote.js