Комментарии 23
А вот компоненты полимера + Backbone прям конфетка.
Что по поводу серверного рендеринга? Если все состоит из web-компонентов (а не просто используются как часть разметки), я так понимаю решения нет?
Я никогда не поддерживал серверный рендеринг. Между фронт и сервером должны летать только данные. Но есть и множество кейсов где рендерится на серваке. Вы можете сфетчить компоненты и проинициализировать их на фронте, почему нет? Но вы теряете офлайн поддержку.
Между фронт и сервером должны летать только данные.
Каким образом должна происходить первая загрузка страница? А если остаются только приложения, то зачем вообще нужны браузеры и сопутствующие им проблемы и решения?
Вы можете сфетчить компоненты и проинициализировать их на фронте, почему нет?
Ну вот как быть с web-компонентами у которых все в shadow-dom? Сделать его не shadow? Повторно сформировать DOM уже на клиенте?
Боюсь мы друг друга не понимаем. Почитайте на тему стандарта веб-компонентов и одностраничных приложений.
Приложение не означает, что это, что-то в не браузера))
Приложение не означает, что это, что-то в не браузера))
Боюсь мы друг друга не понимаем. Почитайте на тему стандарта веб-компонентов и одностраничных приложений.
Приложение не означает, что это, что-то в не браузера))
Вопрос простой — каким образом должна происходить загрузка первой страницы приложения. В случае нативных приложений операционных систем — пользователь явным образом скачивает его. В случае браузера пользователь ожидает открытия страницы и чем быстрее, тем лучше.
Если у нас все сайты становятся приложениями, не способными быстро отобразить первую страницу, то теряется смысл браузера — куча ограничений, проблем с безопасностью, скоростью и т.д., в то время как те же приложения поддерживают все основные ОС.
Идеальный вариант — использовать для транспорта данных JSON-LD. Выглядит так:
При первой загрузке данные можно вставить напрямую, в ходе работы приложения грузить из API и напрямую вставлять таким же образом. JSON-LD понимают и поисковые машины, и в коде распарсить 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) стилизируются, при чём по разному и даже в разном порядке для настольной и мобильной версии. При этом верстка не содержит интерфейсных элементов, только контент. Это простой вариант, некоторые другие показать не могу, но если интересно — пишите в личку.
Не рекламы ради, посмотрите инспектором в Firefox, Chrome: ecois.me/en
Там семантически размеченные блоки, которые в итоге с помощью веб-компонентов (Polymer 0.5.x) стилизируются, при чём по разному и даже в разном порядке для настольной и мобильной версии. При этом верстка не содержит интерфейсных элементов, только контент. Это простой вариант, некоторые другие показать не могу, но если интересно — пишите в личку.
Понятно, что не обязательно, но судя по примерам самого Polymer и их готовым компонентам, а также примерами многих других — Polymer предполагается как основной инструмент для разметки. И на самом деле, мне нравится этот подход. Но в отличии от ReactJS (ну или другого компонентного фреймворка), web-компоненты нельзя использовать изоморфно.
Их примеры показывают, что с «правильными», назовем их так, компонентами, большинство вещей можно будет делать декларативно, например, вложить метку в карту, и оно отрендерится ожидаемым образом, хотя у вас заняло 3 строчки HTML и 0 JS.
Чем проще ваша верстка, тем проще достичь изоморфности. Вам больше не нужны множественные вложенные шаблоны на сервере и аналогичные на клиенте, вы просто ложите кусочек JSON-LD (полученный прямиком из API) и оборачиваете его в один тэг,. Остальное уже чистый фронтенд и сервера не касается.
Чем проще ваша верстка, тем проще достичь изоморфности. Вам больше не нужны множественные вложенные шаблоны на сервере и аналогичные на клиенте, вы просто ложите кусочек JSON-LD (полученный прямиком из API) и оборачиваете его в один тэг,. Остальное уже чистый фронтенд и сервера не касается.
Дело не в декларативности, чистый HTML и CSS тоже декларативны. Дело в декомпозиции, инкапсуляции, в повторном использовании. Но прикол в том, что чем больше мы реализуем в виде компонентов, тем дольше будет загружаться страница, ведь нативные элементы в бразуере человек скачивает вместе с браузером, а web-компоненты при загрузке страницы.
Конечно просто написать изоморфное приложение из 1 тега <my-app />. Но цена…
Конечно просто написать изоморфное приложение из 1 тега <my-app />. Но цена…
Во-первых на счёт декларативности я упоминал JavaScript, вы не подключите вот так просто с помощью декларативного HTML и CSS карту с меткой на ней, придется писать JavaScript, с веб-компонентами же вы делаете всё декларативно.
Во-вторых мы страница загружаться дольше не будет, поскольку если вы не используете веб-компоненты — вы ту же логику и стили закладываете в обычные CSS и JavaScript файлы, то есть браузеру принципиальной разницы нет что выполнять, вот только организацию компонентов вам придется делать самому, что совсем не обязательно будет быстрее нативных веб-компонентов и всего что они предлагают (вроде наследования и тому подобного). О полифиллах сейчас речь не шла.
Во-вторых мы страница загружаться дольше не будет, поскольку если вы не используете веб-компоненты — вы ту же логику и стили закладываете в обычные CSS и JavaScript файлы, то есть браузеру принципиальной разницы нет что выполнять, вот только организацию компонентов вам придется делать самому, что совсем не обязательно будет быстрее нативных веб-компонентов и всего что они предлагают (вроде наследования и тому подобного). О полифиллах сейчас речь не шла.
Согласна с тем, что в итоге мы получим одно и то же, и вроде бы страница не должна дольше загружаться, но пока слишком много нюансов. Т.е. когда-нибудь ShadowDOM будет везде и быстро работать, когда-нибудь HTTP2 будет везде работать и можно будет не париться с множественным количеством файлов.
Сейчас есть хорошая практика JS выполнять после рендеринга страницы, опять же вопрос, с web-компонентами уже не так красиво получается в разных местах генерировать код?
Ну и по поводу привязки данных и навешивания событий, я так понимаю, единого мнения тоже пока нет.
Сейчас есть хорошая практика JS выполнять после рендеринга страницы, опять же вопрос, с web-компонентами уже не так красиво получается в разных местах генерировать код?
Ну и по поводу привязки данных и навешивания событий, я так понимаю, единого мнения тоже пока нет.
Почему используя один элемент вы выкачиваете все приложение сразу? ;) Главный элемент приложения может подгружать данные по необходимости.
Так же вы можете организовать структуру приложения иным способом, не говоря уже о том, что просто брать от полимера только те элементы, что вам действительно необходимы, а всю логику писать используя совершенно другой инструмент.
Так же вы можете организовать структуру приложения иным способом, не говоря уже о том, что просто брать от полимера только те элементы, что вам действительно необходимы, а всю логику писать используя совершенно другой инструмент.
Shadow DOM имплементирует инкапсуляцию, но нативно его только Гугл и поддерживает.
Уже есть давно под флагом в Firefox, Apple тоже планируют имплементировать, но у них возникли некоторые комментарии/пожелания, сейчас ищут компромисс. По своему опыту скажу что скорости полифиллов уже достаточно, просто в перспективе будет ещё быстрее.
Довольно красивые контролы, но тест производительности угнетает. Делал добавление 5000 элементов, после чего браузер можно только килять. Что будет на смартфоне я даже представить боюсь.
То есть они хотят делать вид что делают Shadow DOM сделав свой jQuery, который игнорирует типа-шедоу-дом?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Теневой DOM (Shady DOM)