Pull to refresh

Comments 23

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

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

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

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

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

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

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

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

Я понимаю, когда компоненты вставляются в обычную верстку, как расширение стандартных элементов, но в случае с Polymer все оборачивается в компоненты, в Body вставляется только <my-app />. А все компоненты хранятся в импортированных HTML.
Нет, совершенно не обязательно. Вы, конечно, можете до такой степени всё обернуть, то здесь ведь тоже есть здравый смысл, верно?
Не рекламы ради, посмотрите инспектором в Firefox, Chrome: ecois.me/en
Там семантически размеченные блоки, которые в итоге с помощью веб-компонентов (Polymer 0.5.x) стилизируются, при чём по разному и даже в разном порядке для настольной и мобильной версии. При этом верстка не содержит интерфейсных элементов, только контент. Это простой вариант, некоторые другие показать не могу, но если интересно — пишите в личку.
Понятно, что не обязательно, но судя по примерам самого Polymer и их готовым компонентам, а также примерами многих других — Polymer предполагается как основной инструмент для разметки. И на самом деле, мне нравится этот подход. Но в отличии от ReactJS (ну или другого компонентного фреймворка), web-компоненты нельзя использовать изоморфно.
Их примеры показывают, что с «правильными», назовем их так, компонентами, большинство вещей можно будет делать декларативно, например, вложить метку в карту, и оно отрендерится ожидаемым образом, хотя у вас заняло 3 строчки HTML и 0 JS.
Чем проще ваша верстка, тем проще достичь изоморфности. Вам больше не нужны множественные вложенные шаблоны на сервере и аналогичные на клиенте, вы просто ложите кусочек JSON-LD (полученный прямиком из API) и оборачиваете его в один тэг,. Остальное уже чистый фронтенд и сервера не касается.
Дело не в декларативности, чистый HTML и CSS тоже декларативны. Дело в декомпозиции, инкапсуляции, в повторном использовании. Но прикол в том, что чем больше мы реализуем в виде компонентов, тем дольше будет загружаться страница, ведь нативные элементы в бразуере человек скачивает вместе с браузером, а web-компоненты при загрузке страницы.
Конечно просто написать изоморфное приложение из 1 тега <my-app />. Но цена…
Во-первых на счёт декларативности я упоминал JavaScript, вы не подключите вот так просто с помощью декларативного HTML и CSS карту с меткой на ней, придется писать JavaScript, с веб-компонентами же вы делаете всё декларативно.

Во-вторых мы страница загружаться дольше не будет, поскольку если вы не используете веб-компоненты — вы ту же логику и стили закладываете в обычные CSS и JavaScript файлы, то есть браузеру принципиальной разницы нет что выполнять, вот только организацию компонентов вам придется делать самому, что совсем не обязательно будет быстрее нативных веб-компонентов и всего что они предлагают (вроде наследования и тому подобного). О полифиллах сейчас речь не шла.
Согласна с тем, что в итоге мы получим одно и то же, и вроде бы страница не должна дольше загружаться, но пока слишком много нюансов. Т.е. когда-нибудь ShadowDOM будет везде и быстро работать, когда-нибудь HTTP2 будет везде работать и можно будет не париться с множественным количеством файлов.
Сейчас есть хорошая практика JS выполнять после рендеринга страницы, опять же вопрос, с web-компонентами уже не так красиво получается в разных местах генерировать код?
Ну и по поводу привязки данных и навешивания событий, я так понимаю, единого мнения тоже пока нет.
Почему используя один элемент вы выкачиваете все приложение сразу? ;) Главный элемент приложения может подгружать данные по необходимости.
Так же вы можете организовать структуру приложения иным способом, не говоря уже о том, что просто брать от полимера только те элементы, что вам действительно необходимы, а всю логику писать используя совершенно другой инструмент.
Не могли бы вы написать пример для polymer как сделать lazy подгрузку?
Просто сколько не смотрю примеров, везде грузится все и сразу.
Shadow DOM имплементирует инкапсуляцию, но нативно его только Гугл и поддерживает.

Уже есть давно под флагом в Firefox, Apple тоже планируют имплементировать, но у них возникли некоторые комментарии/пожелания, сейчас ищут компромисс. По своему опыту скажу что скорости полифиллов уже достаточно, просто в перспективе будет ещё быстрее.
Понимаете, то, что под флагом не допустимо для продакшена. В данном случае мы рассматривали полифил стандарта веб-компонентов, который как вы поняли если даже и оптимизируете, покрыть все потребности вы не сможете.
Конечно, понимаю. Но под поддержкой я имею ввиду что это не вещь, которую эксклюзивно разрабатывает Google и больше никто. Все основные браузеры работают в этом направлении, например, в Firefox уже можно регистрировать пользовательские элементы, теневой DOM под флагом. Не всё сразу)
Довольно красивые контролы, но тест производительности угнетает. Делал добавление 5000 элементов, после чего браузер можно только килять. Что будет на смартфоне я даже представить боюсь.
То есть они хотят делать вид что делают Shadow DOM сделав свой jQuery, который игнорирует типа-шедоу-дом?
Конечно же не свой jQuery, вы используя API можете работать с элементами с помощью jQuery, не вопрос. А по факту, да — разделив композицю на два DOM — темный и светлый ;) Через API вы можете выбирать, в какой из них закинуть элемент или по которому из них сделать селект итд.
Only those users with full accounts are able to leave comments. Log in, please.