Pull to refresh

Comments 27

Я вот не понимаю восторгов в стиле «WebComponents изменят весь веб». С чего бы? У нас и сейчас есть тонны готовых компонент россыпью и пачками, и то что они живут не в shadow dom — не сильно кому и мешает.

Мешает совсем другое — наоборот их слабая связанность. Чтобы из компонент можно было собирать приложение, они хотя бы выглядеть должны одинаково. Не говоря уже о том, чтобы иметь одинаковый UX, уметь гибко вкладываться друг в друга собираясь в более крупные компоненты, иметь общую модель databinding-а, и т.п.
Именно. Модель component.io, где компоненты — просто npm-модули, выглядит гораздо привлекательнее. А уже как эти модули обернуты — будь то в веб-компонент, standalone, jquery-плагин, browserify или другой сборщик — это отдельный вопрос, — вопрос потребителя.
Поэтому разработка компонента сразу в целевую систему — странное занятие. Это все приводит к тому, что в мире js есть море дубликатов одного и того же.
Всё, что напрягает в «готовых компонентах россыпью и пачками» — это необходимость каждый раз для контролов копировать определённую вермешель разметки из документации, затем не забывая инициализировать из JS. Я бы не отказался от WebComponents в этом контексте. Особенно это касается замысловатых input-контролов, которые оборачиваются как-нибудь вокруг стандартных.
Давайте я вам на живом примере объясню, почему восторг такой.

Как мы обычно делаем в случае с какой-нибудь аякс-страницей:

<script src="jquery.js"/>
<script src="jquery.slider.js"/>
<div class="slider"/>
<script>
$('.slider').slider();
</script>

Что вы делаете в веб-компонентах
<link rel="import" href="slider.html"/>
<my-slider/>


Все. Вам не нужно отлавливать внутренние переходы на страницы для redraw. Не нужно как-то навешиваться. Это самостоятельный модуль, и он не относится к основной логике страницы.
Если пишешь на jQuery в стиле «вермишелька» — то всё что угодно будет казаться дзеном.
у меня по сравнению с angular-ом кода меньше выходит. (jquery нету)
paper-elements например вполне «одинаково выглядящая коллекция».
Посмотрите видео «Два» в конце.

WebComponents не готовые изменят веб, а подход к разработке.
Я так и не понял, гугл собирается ангуляр на эту технологию переводить или нет? Я так понимаю они еще перевод на дарт не закончили, а тут и polymer подоспел.
И возможно ли использовать какую-то связку этих компонент, как совсем базовый ангуляр? Есть ли сборки какие-то?
Собирается, только постепенно, пока это ещё альфа, которая с трудом и тормозами работает только в evergreen браузерах. Никто тестами производительности пока не занимался (а там есть чем заняться) и т.п. Много вопросов пока.
Тем не менее, они отказались в Dart от Web UI и портируют Polymer на Dart www.dartlang.org/polymer/

Если Angular с блекджеком Dart и полимерами взлетит через год другой — всем будет интересно.
что-то картинка к топику на логотип РЖД похожа…
image
Как-то мой мозг не успевает за «инновациями» гугла в вебе…
Хм. А вроде сто лет назад уже была кухня с xml + стили + трансформация = html… Это не те же яйца, только в профиль?
То же чего-то не пойму. Создали в xsl-стиле именованный template в который параметрами принимаем любые значения для любой визуализации, а далее ссылаемся на него в любом месте страницы. Этот template ровно так же может сидеть в отдельных подгружаемых xsl-файлах.

Гуру, подскажите где разница-то???! 14 лет назад работало!
Выше уже сказали, что это работает медленно. Но судя по тому как оно работает, оно в принципе не может быстро работать, так как перпендикулярно логике рендринга в браузера. Скорее всего такой подход не сильно будет ухудшать ситуацию с single page приложениями, но вот с более классическими сайтами всё не понятно.
На сколько я могу смотреть, абсолютно всё на SinglePage не перевести (если у вас не NodeJS то много гемора с SEO). А если тягать CSS/JS в произвольных местах при каждой загрузке страницы явно перебор.
Сейчас мы стараемся уменьшить количество загрузок CSS и загрузить его раньше всех, а JS поставить прям перед (ну не весь конечно). Или shadow dom из веб компонентов позволяет не ждать его загрузки, для отображения самой страницы?
Короче это всё в моём понимании ломает pipe line рендринга страницы.
Если я не прав и мои страхи беспочвенны то пожалуйста напишите, в целом идея изоляции компонентов она интересная.
Совершенно не перебор. В Polymer есть такое понятие как вулканизация, когда скрипты и стили встраиваются в тот же файл, что и html, потом несколько html можно объединить, зажать gzip, и работает это очень быстро. Я у себя в движке сделал поддержку Web Components, так что они автоматически разруливаются по зависимостям и объединяются. Вулканизацию пока не применял, хотя, возможно, и стоит. Так вот нативно в Chromium работает шустро, в Firefox с полифилами медленнее, но вполне нормально, а с HTTP 2.0 вообще будет красота, никакой вулканизации не нужно будет.

Совершенно нормально работает с не-SinglePage страницами, отлично индексируется поисковиками, так как HTML кода на выходе меньше, по сути только контент, и для изменения представления достаточно изменить веб-компонент, а не исходный HTML, это то о чём я уже давно говорил на счёт шаблонизаторов.

Рендеринг не ломает, просто попробуйте поработать — увидите. Как пример могу показать приложение для Firefox OS — там исключительно веб-компоненты, и работает нормально, ещё один проект с закрытым кодом, потому показать не могу, но, скорее всего, некоторые компоненты для форм (выпадающие списки, инпуты, чекбоксы кастомные и прочее) будут позже выложены в Open Source.

А ещё веб-компоненты это не обязательно Polymer, как считает автор статьи:

Ну и еще существует большая вероятность, что Polymer-ное виденье будущего станет реальностью, и вы в будущем просто отключите Polymer и все продолжит работать нативно.

Polymer — это отдель ностоящая штука, как jQuery, скорее всего в браузеры встроена не будет. А вот полифилы Polymer Platform — да, можно будет когда-то отключить.
Я не считаю что веб-компоненты это Polymer. Возможно не правильно выразился. Я имел ввиду именно полифилы.

По скорости поддерживаю, по крайней мере то что я протестировал — работает быстрее angular-a, даже в ie (не знаю какой, последний).
Ну про HTTP 2.0 я знаю, а вулканизация наверное решит проблему с лишними сетевыми запросами, и всё же что с рендрингом?
Ведь если у нас возникает css где то в центре html то браузер не показывает картинку пока этот css не скушает.
Или с JS, если инициализация компонента будет долгой, то пользователь увидит всё до компонента, потом будет тупняк и пользователь увидит всё после компонента? Я знаю что есть всякие defer и прочее, но как это реализовано тут?
К примеру скорость работы gmail, adsense, analytics меня не очень устраивает, я знаю что это ещё не веб компоненты но автор тот же.
Спасибо, интересно. В Chrome работает достаточно шустро, а в firefox лагает.
Глянул инспектор… хм… html на 800 килобайт (200 сжатый) со всем всем… а как же кеширование? Но опять же, это single page и web app.
FF нету. IE 11 на ноуте(i5) почти не лагает, я бы сказал не критично. Есть некоторые проблемы в верстке, особенно с «выезжанием окон». Но в целом работать можно. Про хром сказали.
В примере только статика и данные. А что по вашему не web app?
В polymer есть атрибут unresolved для body, он решает проблему частичной отрисовки, пока страница не готова — она не показывается. Это простое решение. Визуально выглядит как белый фон, потом плавно появляется содержимое. Не мешает совершенно.
Я бы не сказал что прям автор тот же. Да, Google активно продвигает идею, но она основана на стандартах, то есть не является проприетарной, к тому же при нативной поддержке работать будет гораздо быстрее любых шаблонизаторов и подобных вещей.
они там в iframe подгружают целую страничку с демо (из компонента), оно в хроме часто тупит с этой подгрузкой.
UFO just landed and posted this here
Sign up to leave a comment.

Articles