если используем svelte то смысл же тот же, естьь некий сгенеренный html из компонента, он точно так же может вставлятьсяв используя ssi. когда пользователь входит на страницу ему отрисовывается этот компонента логика выполняется когда нить позже, из за подключенного defer

В треде есть хороший комментарий, который лично мне многое объяснил https://github.com/whatwg/dom/issues/831#issuecomment-585451735

у меня нет совсем опыта svelte, я не знаю, как там это реализовано

вопрос такой - есть, например, один шаблон, скажем, для кнопок
и внутри шаблона текст кнопки и иконка

как без какой-либо логики отобразить на странице кнопки с разным текстом и иконками?

окей, встречный вопрос, зачем кнопки без какой либо логики? они отобразились пользователю, но не успел догрузиться JS  (пользователь - Флэш или у него 3g соединение)

хотя пофиг, это частности

прочитал ссыль, все равно это какая то жусткая частность на которую нужно найти применение

это могут быть ссылки, которые работают без какой-либо логики

про частность - возможно, да

но SSR это уже частность. приложения, которые не откликаются на клики вызывают ещё больше негатива, чем отсутствие чего-то на экране (rage clicks...)

в любом случае, очень надеюсь, что эта инициатива хорошо впишется в будущее и найдёт свое применение, а не умрёт, как HTML Imports

эх(((я. бы пописал c html imports. в свое время прям загорелся ими, как поставкой реализации компонентов для легаси системы, а в итоге пересел на  вебкомпоненты и lit-element

сразу придёт контент и сразу вставится в шадов дом и сразу получит изоляцию
так тебе бы пришлось в слоты загонять контент и он был бы не изолирован, пока компонент не прикрепится
или без слотов перекладывать из дома в шадов дом
ну и можно вообще без js

короче, это не революция, а логичное развитие

- но зачем мне от него сразу изоляция, что она решает, что нужна так быстро отобразить?
- если я использую какой то фреймворк который предоставляет мне SSR с декларативным shadow dom, то чем это лучше чем  SSR без shadow dom?
- построить еще одно изолированное дерево что бы скрыть стили, а не является ли это дополнительной нагрузкой на браузер пользователя?
- будет ли этот контент моргать когда произойдет гидрация логикой?
- что будет если произойдет рассинхрон кешей стилей что в декларативном SD и тот что притащит логика?
- зачем мне вообще в рамках фреймворка может быть нужна изоляция стилей, если он, по сути решает эту проблему в том числе обычной генерацией уникальных селекторов?
- действительно ли декларативный SD является логичным развитием для веба и вебкомпонентов, а не стандартное АПИ браузера, которое сделает то, что сейчас делает большая тройка, но без лишнего кода?

если тебе что-то не нужно, то вроде никто не заставляет тебя это использовать
может это мне нужна изоляция, например

плиз, поделись своим виденьем кейса, где бы ты его применил и получил пользу в виде перформанса, стандартизации или TTM

прямой инклуд css кода, например

на этом месте не понял. инклуд куда, зачем и как это сейчас решается?

никак это не решается, ты не можешь подключить css не изолированно

допустим, у тебя есть
.foo{ color: red}

ты его можешь подключить прямо в изолированный элемент

у Вадима Макеева было видео, кстати

Смотрел. Он в видео предлагает поиграться с этой технологией. Не более. С этого видоса у меня и появились вопросы по dsd

ну так пока вариантов кроме как поиграться нет, потому что поддержка слабая, но это не значит, что пользы нет