Я не знаю ваших потребностей, замечу лишь что это не Sailfish OS. Свои хотелки для повседневного использования я перечислил, и вижу, что они потихоньку реализуются.
Смотря с какой целью. То, что сейчас можно купить вне корпоративного использования, как и написано, больше для энтузиастов-разработчиков. Или как звонилка с доп. плюшками.
Когда появится возможность платить с телефона (СБППэй вроде вышел), втыкать в ютуб и вызывать такси без тормозов (решается выходом более приличных железок и заменой браузерного движка), использовать всякие доставки с маркетплейсов хотя бы как PWA - будет вполне юзабельно, как по мне.
У меня есть Fplus Pro R570E на Авроре, это единственный сейчас доступный для покупки простым смертным смартфон. Как звонилка / проверялка почты вполне годится с софтом из коробки, есть альтернативный клиент для телеги. Сама ОС своеобразная и приятная в использовании.
В остальном для реального использования это очень слабая железка, непригодная для повседневности в качестве смартфона, железо по ощущениям десятилетней давности. Усугубляется устаревшим тормозным браузером на движке Firefox 78.
С другой стороны за 14к это отличная игрушка для программиста побаловаться - обычный линукс, рут из коробки, чего-то не хватает - можно собрать из исходников, основной фреймворк для разработки - Qt. Можно поучиться портировать игры и софт. Мне как веб-разработчику давно хотелось поковыряться с плюсами, пописать что-то нативное для мобилки чисто для себя, поэтому доволен как слон.
Через пару недель должна выйти новая мажорная версия к которой уже портируют браузер на базе Chromium + вот выходят новые девайсы, среди которых есть как минимум один, который вполне тянет на повседневный смарт по железу. Я бы очень хотел поюзать Аврору на нормальном железе, поэтому жду.
Для меня важной фичей была бы возможность подключения компонентов любой сложности поштучно в пару <script> тегов, при этом не таща рантайм какого либо фреймворка. Но сколько не встречал готовых решений, везде вижу обвязки-абстракции (которые надо тащить точно также, как реактовый рантайм). Разве что более тонкие, но с явно менее удобные для разработчика по сравнению с React и др. фреймворками.
Вопрос не совсем по теме статьи - существуют ли хорошие примеры UI-kitов на чистых веб компонентов без дополнительных абстракций типа lit или их аналогов?
Грубо говоря, чтобы все было в одном стиле, и при этом можно было подключить, скажем мультиселект или датагрид одним-двумя импортами прямо в HTML?
Выходной бандл любого фреймворка это в любом случае нативный код. Отличие от вашего будет лишь в удобстве разработке и объеме выходного бандла, т.к. вы сэкономите сотню-другую килобайт используя несколько нативных апи.
А для шаринга общих зависимостей без какого-либо дублирования, удобно использовать https-импорты в коде. Можно даже (нужно) настроить проект так, чтобы при этом была полноценная поддержка типов. Но это напрямую к теме не относится.
Можно. А можно и использовать возможности какого-нибудь нормального бандлера. Заодно можно будет не париться с относительными путями при написании кода и рефакторинге.
Ну и остальные перечисленные замечания вы пропустили. Вернусь в ветку, если появится что-то по существу.
Вы апеллируете к своему опыту, ок, но я и себя могу назвать «динозавром» в этой теме. Я работаю со стандартами из группы веб-компонентов еще со времен первых черновиков, и посвятил много времени изучению самых разных подходов. Мне тоже есть с чем сравнить, от современных либ до совсем древних.
Так я привел несколько конкретных примеры в комментах без всякой аппелляции к опыту — не реально работать без этапа сборки и дев-сервера, отсутствие поддержки чего либо кроме строк при передаче через аттрибуты HTML, отсутствие внятных плюсов при реализации UI-библиотеки. И не получил на них ответа.
Не хочется тратить время на продолжение обсуждения, не получая ответа на даже очевидные сходу вопросы.
Ну хорошо, давайте разберем не юзкейсы, как ниже, а постановку задачи, ведь как понимаю вся последующая статья это попытка ее решения:
Существует простой и распространенный подход к интеграции виджетов: мы даем указать, через созданный нами API, элемент-контейнер, в который и добавляем всё необходимое.
Да, точно также работают и веб-компоненты, которые использует ваша библиотека. Разница лишь в том, что в вашем случае часть забот берет на себя браузер.
И все у нас хорошо, пока не выяснится, что пользователь-интегратор — использует стили, которые глобально влияют на все элементы определенного типа на странице… И вот, вы должны позаботиться о защите CSS, но таким образом, чтобы дизайн вашего решения можно было настроить снаружи каким-то вменяемым способом...
Нормальный способ изоляции себя от внешних стилей, которые мы не контролируем — Shadow DOM. Это браузерное апи, и его поддержка есть во многих фреймворках, а если ее нет, то компонент-враппер прячущий стили создается от силы за полчаса.
А потом, вы выясните, что цикл рендеринга хост-приложения влияет на то, как ваш виджет инициализируется, и вам нужно будет объяснить пользователю, как и когда вызывать методы вашего API для того, чтобы не возникало никаких «гонок» и прочих «cannot read property X of undefined».
В любом современном фреймворке можно управлять жизненным циклом компонента. Причем удобнее, чем с помощью нативных методов веб-компонента, ибо более высокоуровнево.
А ещё, вам может понадобиться отобразить одну часть интерфейса в одном месте хост-приложения, а другую часть — в другом, и в разное время...
Порталы в реакте, аналогичный функционал в других фреймворках.
А ещё, пользователи вашего виджета захотят его настроить под свои особые требования, изменить дизайн, включить или выключить какие-то функции...
Все это есть в любом современном фреймворке.
В общем, никакие классические и консервативные подходы, достойных ответов, на эти вопросы, не дают.
В свете вышенаписанного, совершенно неочевидный вывод. В итоге непонятно, какая задаче решается.
Если речь про фреймворко-независимые компоненты в гибридных приложениях, где намешаны React/Vue/прочие ангуляры, то вроде идея и красивая — наделаем на Symbiote компоеннтов, а в других частях обернем их во врапперы и все будет красиво. А на деле это будет +1 технология в проекте.
Если на проекте есть React, то можно сделать тоже самое на React, нулевой ценой на частях приложения, уже написанных на реакте, и ценой core-бандла + самих standalone-компонентов на реакте, опирающихся на этот core, на остальных частях приложения. Вместо реакт подставьте любую другую технологию _уже_ использующуюся на проекте.
Если речь про встраивание в хроническое server-page легаси, то получается нет никакой проблемы дружить что-то с чем-то. Берешь фреймворк по вкусу и делаешь как я описал выше.
В общем, мне кажется я более чем подробно сформулировал технические вопросы и вопросы по области применимости. Я бы хотел узнать ответы, прежде чем продолжать обсуждать другие технические моменты.
Если мы стремимся к отсутствию зависимостей, то эта библиотека сработает только для кейса «Виджеты», которые делаются вне дизайн-системы.
Если это не так, а например для кейса «Элементы UI-библиотек» это не так, то у вас _будет_ отдельный core-бандл и никуда вы не денетесь и будете его тащить, либо будете дублировать пачки кода и стилей в виде копипаста от компонента к компоненту.
Для приличного размера дизайн-системы эти бандлы могут быть довольно большими, частая задачка которая мне попадается — выпилить material ui (у которого прям отдельный core-бандл в npm без котоого ничего не работает) или что-то подобное, и заменить более легковесным. Так вот даже если менять, все равно сам создаешь такой же бандл, просто уже меньше, и под нужды заказчика.
Да конечно, бандл фреймворка + бандл UI-либы это хуже, чем только бандл UI-либы по весу и нагрузке на скриптинг в браузере. Но звучит уже не так прикольно. Все равно что-то тащим и на что-то завязываемся, а значит вполне можно сравнивать с другими фреймворками, и тут сравнение уже кроме веса будет не в вашу пользу.
Далее кейс «Микро-фронтенды» — полагаю они отличаются от виджетов какой-то повышенной сложностью, возможно наличием роутинга. В общем без пояснения данный пункт не понятен, но выглядит как то что тут тоже будет отдельный рантайм для управления микрофронтендом. Просто меньше чем у того же реакта. Но и неудобнее.
По кейсу «Приложения-надстройки» тоже нужно поясление, не знаю что это такое.
По итогу получается что для UI-либы фреймворк предлагает нативность (которая непонятно что дает, так как все равно таскаем за собой абстракции, просто уже другие и потоньше) и за счет этого меньший объем загружаемого кода. Взамен этого забирает плюшки взрослых фреймворков. А если эти плюшки включать, то получается ухудшенная копия этих фреймворков.
Я разобью ответ на два комментария. Первый про часть техническую.
Сразу скажу, что ни в коем случае не хотел обидеть. Мне нравятся разработки на основе веб-компонентов, включая вашу. То, что я описал выше это именно то, с чем столкнулся я сам используя похожие на вашу технологии, поэтому и написал для тех, кто еще не пробовал.
1. Про сервер я писал в ответ на следующее заявление: «Вы можете писать свой код и сразу видеть результат в браузере, без установки каких-либо специфических зависимостей: компиляторов, специальных dev-серверов и прочего». Я говорю, что не будет такой ситуации, когда описанное будет преимуществом. Звучит красиво, но без этапа сборки писать код неудобно, без дев-сервера в большинстве ситаций просто невозможно — работа с JS через файловую систему налагает кучу ограничений. Подобные рекламные заявления делали разработчики Polymer в свое время, но больше не делают по описанной выше причине.
Ну а если появляется этап сборки и дев-сервер, то у React/Vue и прочей братии тут все гораздо лучше в плане обвеса и возможностей.
2. Я понимаю, что этот выбор сделан чтобы уменьшить нагрузку на js-рантайм, т.к. такой шаблон действительно парсится нативно браузером, но повторю свое мнение — это крайне снижает удобство разработки. Например вот это «set='onclick: increment'» если я правильно понял, вынуждает передавать название обработчика в виде строки, что убивает рефакторинг и кучу функуционала в IDE. С точки зрения разработчика это именно то, что я написал в первом комменте — примитивный шаблонизатор.
3. По производительности действительно надо смотреть и тестить, тут согласен.
4. Да такая же как и везде, просто меньше по объему и проще. За что приходится платить DX как у фреймворков допотопного поколения.
Кроме перечисленного, еще какие-то аргументы есть?
Поштучно их много, да тот же Shadow DOM — он не только изолирует стили, но и затрудняет доступ к глубоко вложенным элементам формы извне и мешает SSR. Но мой основной посыл не в этом, а в том что сама эта концепция — максимальное стремление к нативности и отсутствию зависимостей — это путь в никуда. Плюс будет один (в весе), а минусов сколько фантазии хватит.
Ну и я специально старался не зацикливаться на аргументах по отсутствующую вокруг фреймворка инфраструктуру в виде кучи библиотек и прочего, так как очевидно что ее пока нет. Но это же тоже минус.
С чего Вы решили, что все плохо с удобством разработки, да еще и на порядок, я тоже совершенно не понимаю. Мы уделяем этому вопросу много внимания, и активно собираем фидбек от тех, кто пробовал все это использовать.
Я так решил, потому что посмотрел на примеры кода, а также потому, что я писал крупный проект на lit, которым вы точно вдохновлялись, ну потому что пробовал на живых проектах много других фреймворков — React, Angular, Vue и мне есть с чем сравнить.
Привет, одно время тоже интересовался темой микрофронтендов без рантайма, и в итоге ничего нормального так и не нашел. Правда я решал немного другую задачу — нужно было сделать максимально независимый от зависимостей на внешние библиотеки UI kit, который должен был одинаково работать и выглядеть на любых страницах одного и того же сайта, состряпанного из наслоений различных технологий года так с 2004-го. Сделал в итоге на базе core-бандла React + на нем же независимых микрофронтендов вплоть до отдельных компонентов-бандлов по типа Svelte.
Все эти чисто нативные решения без дев-сервера, и т.д. и т.п. упираются в то, что код писать на них тупо неудобно.
Вот еще несколько моментов:
1. Сервер все равно есть всегда, без сервера тупо не работают многие вещи по причинам безопасности. Почему бы и не быть дев-серверу. Собственно, в Polymer/lit довольно быстро дошли до этой мысли и последние пару лет dev-сервер там есть как и этап сборки.
А если дев-сервер все равно есть, то почему бы не использовать его по полной программе, со всеми плюшками типа target для кроссбраузерности, всевозможных препроцессоров, ленивой загрузки и т.д. Банально на чистом CSS писать крайне неудобно, а для препроцессоров нужен сборщик.
2. Ты говоришь, что шаблонизатор HTML, но это не так, это видно по первому же примеру:
Это какой то самодельный примитивный шаблонизатор. Если шаблонизатор все равно есть, то почему бы не взять какой то более продвинутый.
3. Синхронные обновления DOM без батчинга там где он нужен = привет тормоза.
4. BaseComponent это тот же рантайм. Хотя здесь вижу плюс, что он маленький и загружается один раз засчет кеширования импортов.
Одним словом, каких то супер-плюсов по сравнению с альтернативами здесь нет, кроме тонкого рантайма. В остальном все хуже. Настолько ли даже пара метров core-бандла какого нибудь фреймворка плохи, чтобы отказываться от на порядок более удобного удобства разработки?
GCC поменяли до 12 на 5 версии, ждем пощупать с официальным релизом для некорпоративных пользователей.
Я не знаю ваших потребностей, замечу лишь что это не Sailfish OS. Свои хотелки для повседневного использования я перечислил, и вижу, что они потихоньку реализуются.
Смотря с какой целью. То, что сейчас можно купить вне корпоративного использования, как и написано, больше для энтузиастов-разработчиков. Или как звонилка с доп. плюшками.
Когда появится возможность платить с телефона (СБППэй вроде вышел), втыкать в ютуб и вызывать такси без тормозов (решается выходом более приличных железок и заменой браузерного движка), использовать всякие доставки с маркетплейсов хотя бы как PWA - будет вполне юзабельно, как по мне.
У меня есть Fplus Pro R570E на Авроре, это единственный сейчас доступный для покупки простым смертным смартфон. Как звонилка / проверялка почты вполне годится с софтом из коробки, есть альтернативный клиент для телеги. Сама ОС своеобразная и приятная в использовании.
В остальном для реального использования это очень слабая железка, непригодная для повседневности в качестве смартфона, железо по ощущениям десятилетней давности. Усугубляется устаревшим тормозным браузером на движке Firefox 78.
С другой стороны за 14к это отличная игрушка для программиста побаловаться - обычный линукс, рут из коробки, чего-то не хватает - можно собрать из исходников, основной фреймворк для разработки - Qt. Можно поучиться портировать игры и софт. Мне как веб-разработчику давно хотелось поковыряться с плюсами, пописать что-то нативное для мобилки чисто для себя, поэтому доволен как слон.
Через пару недель должна выйти новая мажорная версия к которой уже портируют браузер на базе Chromium + вот выходят новые девайсы, среди которых есть как минимум один, который вполне тянет на повседневный смарт по железу. Я бы очень хотел поюзать Аврору на нормальном железе, поэтому жду.
Для меня важной фичей была бы возможность подключения компонентов любой сложности поштучно в пару <script> тегов, при этом не таща рантайм какого либо фреймворка. Но сколько не встречал готовых решений, везде вижу обвязки-абстракции (которые надо тащить точно также, как реактовый рантайм). Разве что более тонкие, но с явно менее удобные для разработчика по сравнению с React и др. фреймворками.
UPD. Интересно, правда через CDN можно подключить только все компоненты сразу, поштучно, кажется, нельзя.
Спасибо, изучу!
Вопрос не совсем по теме статьи - существуют ли хорошие примеры UI-kitов на чистых веб компонентов без дополнительных абстракций типа lit или их аналогов?
Грубо говоря, чтобы все было в одном стиле, и при этом можно было подключить, скажем мультиселект или датагрид одним-двумя импортами прямо в HTML?
Можно. А можно и использовать возможности какого-нибудь нормального бандлера. Заодно можно будет не париться с относительными путями при написании кода и рефакторинге.
Ну и остальные перечисленные замечания вы пропустили. Вернусь в ветку, если появится что-то по существу.
Так я привел несколько конкретных примеры в комментах без всякой аппелляции к опыту — не реально работать без этапа сборки и дев-сервера, отсутствие поддержки чего либо кроме строк при передаче через аттрибуты HTML, отсутствие внятных плюсов при реализации UI-библиотеки. И не получил на них ответа.
Не хочется тратить время на продолжение обсуждения, не получая ответа на даже очевидные сходу вопросы.
Ну хорошо, давайте разберем не юзкейсы, как ниже, а постановку задачи, ведь как понимаю вся последующая статья это попытка ее решения:
Да, точно также работают и веб-компоненты, которые использует ваша библиотека. Разница лишь в том, что в вашем случае часть забот берет на себя браузер.
Нормальный способ изоляции себя от внешних стилей, которые мы не контролируем — Shadow DOM. Это браузерное апи, и его поддержка есть во многих фреймворках, а если ее нет, то компонент-враппер прячущий стили создается от силы за полчаса.
В любом современном фреймворке можно управлять жизненным циклом компонента. Причем удобнее, чем с помощью нативных методов веб-компонента, ибо более высокоуровнево.
Порталы в реакте, аналогичный функционал в других фреймворках.
Все это есть в любом современном фреймворке.
В свете вышенаписанного, совершенно неочевидный вывод. В итоге непонятно, какая задаче решается.
Если речь про фреймворко-независимые компоненты в гибридных приложениях, где намешаны React/Vue/прочие ангуляры, то вроде идея и красивая — наделаем на Symbiote компоеннтов, а в других частях обернем их во врапперы и все будет красиво. А на деле это будет +1 технология в проекте.
Если на проекте есть React, то можно сделать тоже самое на React, нулевой ценой на частях приложения, уже написанных на реакте, и ценой core-бандла + самих standalone-компонентов на реакте, опирающихся на этот core, на остальных частях приложения. Вместо реакт подставьте любую другую технологию _уже_ использующуюся на проекте.
Если речь про встраивание в хроническое server-page легаси, то получается нет никакой проблемы дружить что-то с чем-то. Берешь фреймворк по вкусу и делаешь как я описал выше.
В общем, мне кажется я более чем подробно сформулировал технические вопросы и вопросы по области применимости. Я бы хотел узнать ответы, прежде чем продолжать обсуждать другие технические моменты.
Если мы стремимся к отсутствию зависимостей, то эта библиотека сработает только для кейса «Виджеты», которые делаются вне дизайн-системы.
Если это не так, а например для кейса «Элементы UI-библиотек» это не так, то у вас _будет_ отдельный core-бандл и никуда вы не денетесь и будете его тащить, либо будете дублировать пачки кода и стилей в виде копипаста от компонента к компоненту.
Для приличного размера дизайн-системы эти бандлы могут быть довольно большими, частая задачка которая мне попадается — выпилить material ui (у которого прям отдельный core-бандл в npm без котоого ничего не работает) или что-то подобное, и заменить более легковесным. Так вот даже если менять, все равно сам создаешь такой же бандл, просто уже меньше, и под нужды заказчика.
Да конечно, бандл фреймворка + бандл UI-либы это хуже, чем только бандл UI-либы по весу и нагрузке на скриптинг в браузере. Но звучит уже не так прикольно. Все равно что-то тащим и на что-то завязываемся, а значит вполне можно сравнивать с другими фреймворками, и тут сравнение уже кроме веса будет не в вашу пользу.
Далее кейс «Микро-фронтенды» — полагаю они отличаются от виджетов какой-то повышенной сложностью, возможно наличием роутинга. В общем без пояснения данный пункт не понятен, но выглядит как то что тут тоже будет отдельный рантайм для управления микрофронтендом. Просто меньше чем у того же реакта. Но и неудобнее.
По кейсу «Приложения-надстройки» тоже нужно поясление, не знаю что это такое.
По итогу получается что для UI-либы фреймворк предлагает нативность (которая непонятно что дает, так как все равно таскаем за собой абстракции, просто уже другие и потоньше) и за счет этого меньший объем загружаемого кода. Взамен этого забирает плюшки взрослых фреймворков. А если эти плюшки включать, то получается ухудшенная копия этих фреймворков.
Сразу скажу, что ни в коем случае не хотел обидеть. Мне нравятся разработки на основе веб-компонентов, включая вашу. То, что я описал выше это именно то, с чем столкнулся я сам используя похожие на вашу технологии, поэтому и написал для тех, кто еще не пробовал.
1. Про сервер я писал в ответ на следующее заявление: «Вы можете писать свой код и сразу видеть результат в браузере, без установки каких-либо специфических зависимостей: компиляторов, специальных dev-серверов и прочего». Я говорю, что не будет такой ситуации, когда описанное будет преимуществом. Звучит красиво, но без этапа сборки писать код неудобно, без дев-сервера в большинстве ситаций просто невозможно — работа с JS через файловую систему налагает кучу ограничений. Подобные рекламные заявления делали разработчики Polymer в свое время, но больше не делают по описанной выше причине.
Ну а если появляется этап сборки и дев-сервер, то у React/Vue и прочей братии тут все гораздо лучше в плане обвеса и возможностей.
2. Я понимаю, что этот выбор сделан чтобы уменьшить нагрузку на js-рантайм, т.к. такой шаблон действительно парсится нативно браузером, но повторю свое мнение — это крайне снижает удобство разработки. Например вот это «set='onclick: increment'» если я правильно понял, вынуждает передавать название обработчика в виде строки, что убивает рефакторинг и кучу функуционала в IDE. С точки зрения разработчика это именно то, что я написал в первом комменте — примитивный шаблонизатор.
3. По производительности действительно надо смотреть и тестить, тут согласен.
4. Да такая же как и везде, просто меньше по объему и проще. За что приходится платить DX как у фреймворков допотопного поколения.
Поштучно их много, да тот же Shadow DOM — он не только изолирует стили, но и затрудняет доступ к глубоко вложенным элементам формы извне и мешает SSR. Но мой основной посыл не в этом, а в том что сама эта концепция — максимальное стремление к нативности и отсутствию зависимостей — это путь в никуда. Плюс будет один (в весе), а минусов сколько фантазии хватит.
Ну и я специально старался не зацикливаться на аргументах по отсутствующую вокруг фреймворка инфраструктуру в виде кучи библиотек и прочего, так как очевидно что ее пока нет. Но это же тоже минус.
Я так решил, потому что посмотрел на примеры кода, а также потому, что я писал крупный проект на lit, которым вы точно вдохновлялись, ну потому что пробовал на живых проектах много других фреймворков — React, Angular, Vue и мне есть с чем сравнить.
Все эти чисто нативные решения без дев-сервера, и т.д. и т.п. упираются в то, что код писать на них тупо неудобно.
Вот еще несколько моментов:
1. Сервер все равно есть всегда, без сервера тупо не работают многие вещи по причинам безопасности. Почему бы и не быть дев-серверу. Собственно, в Polymer/lit довольно быстро дошли до этой мысли и последние пару лет dev-сервер там есть как и этап сборки.
А если дев-сервер все равно есть, то почему бы не использовать его по полной программе, со всеми плюшками типа target для кроссбраузерности, всевозможных препроцессоров, ленивой загрузки и т.д. Банально на чистом CSS писать крайне неудобно, а для препроцессоров нужен сборщик.
2. Ты говоришь, что шаблонизатор HTML, но это не так, это видно по первому же примеру:
Это какой то самодельный примитивный шаблонизатор. Если шаблонизатор все равно есть, то почему бы не взять какой то более продвинутый.
3. Синхронные обновления DOM без батчинга там где он нужен = привет тормоза.
4. BaseComponent это тот же рантайм. Хотя здесь вижу плюс, что он маленький и загружается один раз засчет кеширования импортов.
Одним словом, каких то супер-плюсов по сравнению с альтернативами здесь нет, кроме тонкого рантайма. В остальном все хуже. Настолько ли даже пара метров core-бандла какого нибудь фреймворка плохи, чтобы отказываться от на порядок более удобного удобства разработки?