Теневой DOM (Shady DOM)

[sferrka]

А вот компоненты полимера + Backbone прям конфетка.

Что по поводу серверного рендеринга? Если все состоит из web-компонентов (а не просто используются как часть разметки), я так понимаю решения нет?

[DmitryOlkhovoi]

Я никогда не поддерживал серверный рендеринг. Между фронт и сервером должны летать только данные. Но есть и множество кейсов где рендерится на серваке. Вы можете сфетчить компоненты и проинициализировать их на фронте, почему нет? Но вы теряете офлайн поддержку.

[sferrka]

Между фронт и сервером должны летать только данные.

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

Вы можете сфетчить компоненты и проинициализировать их на фронте, почему нет?

Ну вот как быть с web-компонентами у которых все в shadow-dom? Сделать его не shadow? Повторно сформировать DOM уже на клиенте?

[DmitryOlkhovoi]

Боюсь мы друг друга не понимаем. Почитайте на тему стандарта веб-компонентов и одностраничных приложений.
Приложение не означает, что это, что-то в не браузера))

[sferrka]

Боюсь мы друг друга не понимаем. Почитайте на тему стандарта веб-компонентов и одностраничных приложений.
Приложение не означает, что это, что-то в не браузера))

Вопрос простой — каким образом должна происходить загрузка первой страницы приложения. В случае нативных приложений операционных систем — пользователь явным образом скачивает его. В случае браузера пользователь ожидает открытия страницы и чем быстрее, тем лучше.
Если у нас все сайты становятся приложениями, не способными быстро отобразить первую страницу, то теряется смысл браузера — куча ограничений, проблем с безопасностью, скоростью и т.д., в то время как те же приложения поддерживают все основные ОС.

[nazarpc]

Идеальный вариант — использовать для транспорта данных JSON-LD. Выглядит так:

<my-element>
    <script type="application/ld+json">
        JSON-LD data structure
    </script>
</my-element>

При первой загрузке данные можно вставить напрямую, в ходе работы приложения грузить из API и напрямую вставлять таким же образом. JSON-LD понимают и поисковые машины, и в коде распарсить JSON-LD быстро и удобно, и формат данных один на все случаи жизни. А используя алиасы даже структуру БД менять не нужно.

[nazarpc]

Ну вот как быть с web-компонентами у которых все в shadow-dom? Сделать его не shadow? Повторно сформировать DOM уже на клиенте?

В Shadow DOM реализация, данные остаются в обычном DOM, в том числе упрощая чтение и разбор DOM поисковым машинам, ибо в коде нет интерфейсного мусора, только семантически размеченные данные.

[sferrka]

В Shadow DOM реализация, данные остаются в обычном DOM, в том числе упрощая чтение и разбор DOM поисковым машинам, ибо в коде нет интерфейсного мусора, только семантически размеченные данные.

Я понимаю, когда компоненты вставляются в обычную верстку, как расширение стандартных элементов, но в случае с Polymer все оборачивается в компоненты, в Body вставляется только <my-app />. А все компоненты хранятся в импортированных HTML.

[nazarpc]

Нет, совершенно не обязательно. Вы, конечно, можете до такой степени всё обернуть, то здесь ведь тоже есть здравый смысл, верно?
Не рекламы ради, посмотрите инспектором в Firefox, Chrome: ecois.me/en
Там семантически размеченные блоки, которые в итоге с помощью веб-компонентов (Polymer 0.5.x) стилизируются, при чём по разному и даже в разном порядке для настольной и мобильной версии. При этом верстка не содержит интерфейсных элементов, только контент. Это простой вариант, некоторые другие показать не могу, но если интересно — пишите в личку.

[sferrka]

Понятно, что не обязательно, но судя по примерам самого Polymer и их готовым компонентам, а также примерами многих других — Polymer предполагается как основной инструмент для разметки. И на самом деле, мне нравится этот подход. Но в отличии от ReactJS (ну или другого компонентного фреймворка), web-компоненты нельзя использовать изоморфно.

[nazarpc]

Их примеры показывают, что с «правильными», назовем их так, компонентами, большинство вещей можно будет делать декларативно, например, вложить метку в карту, и оно отрендерится ожидаемым образом, хотя у вас заняло 3 строчки HTML и 0 JS.
Чем проще ваша верстка, тем проще достичь изоморфности. Вам больше не нужны множественные вложенные шаблоны на сервере и аналогичные на клиенте, вы просто ложите кусочек JSON-LD (полученный прямиком из API) и оборачиваете его в один тэг,. Остальное уже чистый фронтенд и сервера не касается.

[sferrka]

Дело не в декларативности, чистый HTML и CSS тоже декларативны. Дело в декомпозиции, инкапсуляции, в повторном использовании. Но прикол в том, что чем больше мы реализуем в виде компонентов, тем дольше будет загружаться страница, ведь нативные элементы в бразуере человек скачивает вместе с браузером, а web-компоненты при загрузке страницы.
Конечно просто написать изоморфное приложение из 1 тега <my-app />. Но цена…

[nazarpc]

Во-первых на счёт декларативности я упоминал JavaScript, вы не подключите вот так просто с помощью декларативного HTML и CSS карту с меткой на ней, придется писать JavaScript, с веб-компонентами же вы делаете всё декларативно.

Во-вторых мы страница загружаться дольше не будет, поскольку если вы не используете веб-компоненты — вы ту же логику и стили закладываете в обычные CSS и JavaScript файлы, то есть браузеру принципиальной разницы нет что выполнять, вот только организацию компонентов вам придется делать самому, что совсем не обязательно будет быстрее нативных веб-компонентов и всего что они предлагают (вроде наследования и тому подобного). О полифиллах сейчас речь не шла.

[sferrka]

Согласна с тем, что в итоге мы получим одно и то же, и вроде бы страница не должна дольше загружаться, но пока слишком много нюансов. Т.е. когда-нибудь ShadowDOM будет везде и быстро работать, когда-нибудь HTTP2 будет везде работать и можно будет не париться с множественным количеством файлов.
Сейчас есть хорошая практика JS выполнять после рендеринга страницы, опять же вопрос, с web-компонентами уже не так красиво получается в разных местах генерировать код?
Ну и по поводу привязки данных и навешивания событий, я так понимаю, единого мнения тоже пока нет.

[DmitryOlkhovoi]

Почему используя один элемент вы выкачиваете все приложение сразу? ;) Главный элемент приложения может подгружать данные по необходимости.
Так же вы можете организовать структуру приложения иным способом, не говоря уже о том, что просто брать от полимера только те элементы, что вам действительно необходимы, а всю логику писать используя совершенно другой инструмент.

[geakstr]

[nazarpc]

Shadow DOM имплементирует инкапсуляцию, но нативно его только Гугл и поддерживает.

Уже есть давно под флагом в Firefox, Apple тоже планируют имплементировать, но у них возникли некоторые комментарии/пожелания, сейчас ищут компромисс. По своему опыту скажу что скорости полифиллов уже достаточно, просто в перспективе будет ещё быстрее.

[DmitryOlkhovoi]

Понимаете, то, что под флагом не допустимо для продакшена. В данном случае мы рассматривали полифил стандарта веб-компонентов, который как вы поняли если даже и оптимизируете, покрыть все потребности вы не сможете.

[nazarpc]

Конечно, понимаю. Но под поддержкой я имею ввиду что это не вещь, которую эксклюзивно разрабатывает Google и больше никто. Все основные браузеры работают в этом направлении, например, в Firefox уже можно регистрировать пользовательские элементы, теневой DOM под флагом. Не всё сразу)

[Master_Dante]

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

[Jabher]

То есть они хотят делать вид что делают Shadow DOM сделав свой jQuery, который игнорирует типа-шедоу-дом?

[DmitryOlkhovoi]

Конечно же не свой jQuery, вы используя API можете работать с элементами с помощью jQuery, не вопрос. А по факту, да — разделив композицю на два DOM — темный и светлый ;) Через API вы можете выбирать, в какой из них закинуть элемент или по которому из них сделать селект итд.