Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 27
Я вот не понимаю восторгов в стиле «WebComponents изменят весь веб». С чего бы? У нас и сейчас есть тонны готовых компонент россыпью и пачками, и то что они живут не в shadow dom — не сильно кому и мешает.
Мешает совсем другое — наоборот их слабая связанность. Чтобы из компонент можно было собирать приложение, они хотя бы выглядеть должны одинаково. Не говоря уже о том, чтобы иметь одинаковый UX, уметь гибко вкладываться друг в друга собираясь в более крупные компоненты, иметь общую модель databinding-а, и т.п.
Мешает совсем другое — наоборот их слабая связанность. Чтобы из компонент можно было собирать приложение, они хотя бы выглядеть должны одинаково. Не говоря уже о том, чтобы иметь одинаковый UX, уметь гибко вкладываться друг в друга собираясь в более крупные компоненты, иметь общую модель databinding-а, и т.п.
Именно. Модель component.io, где компоненты — просто npm-модули, выглядит гораздо привлекательнее. А уже как эти модули обернуты — будь то в веб-компонент, standalone, jquery-плагин, browserify или другой сборщик — это отдельный вопрос, — вопрос потребителя.
Поэтому разработка компонента сразу в целевую систему — странное занятие. Это все приводит к тому, что в мире js есть море дубликатов одного и того же.
Поэтому разработка компонента сразу в целевую систему — странное занятие. Это все приводит к тому, что в мире js есть море дубликатов одного и того же.
Всё, что напрягает в «готовых компонентах россыпью и пачками» — это необходимость каждый раз для контролов копировать определённую вермешель разметки из документации, затем не забывая инициализировать из JS. Я бы не отказался от WebComponents в этом контексте. Особенно это касается замысловатых input-контролов, которые оборачиваются как-нибудь вокруг стандартных.
Давайте я вам на живом примере объясню, почему восторг такой.
Как мы обычно делаем в случае с какой-нибудь аякс-страницей:
Что вы делаете в веб-компонентах
Все. Вам не нужно отлавливать внутренние переходы на страницы для redraw. Не нужно как-то навешиваться. Это самостоятельный модуль, и он не относится к основной логике страницы.
Как мы обычно делаем в случае с какой-нибудь аякс-страницей:
<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. Не нужно как-то навешиваться. Это самостоятельный модуль, и он не относится к основной логике страницы.
paper-elements например вполне «одинаково выглядящая коллекция».
Посмотрите видео «Два» в конце.
WebComponents не готовые изменят веб, а подход к разработке.
Посмотрите видео «Два» в конце.
WebComponents не готовые изменят веб, а подход к разработке.
Я так и не понял, гугл собирается ангуляр на эту технологию переводить или нет? Я так понимаю они еще перевод на дарт не закончили, а тут и polymer подоспел.
И возможно ли использовать какую-то связку этих компонент, как совсем базовый ангуляр? Есть ли сборки какие-то?
И возможно ли использовать какую-то связку этих компонент, как совсем базовый ангуляр? Есть ли сборки какие-то?
Собирается, только постепенно, пока это ещё альфа, которая с трудом и тормозами работает только в evergreen браузерах. Никто тестами производительности пока не занимался (а там есть чем заняться) и т.п. Много вопросов пока.
Тем не менее, они отказались в Dart от Web UI и портируют Polymer на Dart www.dartlang.org/polymer/
Если Angular сблекджеком Dart и полимерами взлетит через год другой — всем будет интересно.
Тем не менее, они отказались в Dart от Web UI и портируют Polymer на Dart www.dartlang.org/polymer/
Если Angular с
да, angularjs 2.0 будет поддерживать веб-компоненты, доки по архитектуре angularjs 2.0 в открытом доступе, там все подробно описано — drive.google.com/?pli=1&authuser=0#folders/0B7Ovm8bUYiUDR29iSkEyMk5pVUk
что-то картинка к топику на логотип РЖД похожа…
Как-то мой мозг не успевает за «инновациями» гугла в вебе…
Хм. А вроде сто лет назад уже была кухня с xml + стили + трансформация = html… Это не те же яйца, только в профиль?
То же чего-то не пойму. Создали в xsl-стиле именованный template в который параметрами принимаем любые значения для любой визуализации, а далее ссылаемся на него в любом месте страницы. Этот template ровно так же может сидеть в отдельных подгружаемых xsl-файлах.
Гуру, подскажите где разница-то???! 14 лет назад работало!
Гуру, подскажите где разница-то???! 14 лет назад работало!
В очередной раз изобрели COM?
Выше уже сказали, что это работает медленно. Но судя по тому как оно работает, оно в принципе не может быстро работать, так как перпендикулярно логике рендринга в браузера. Скорее всего такой подход не сильно будет ухудшать ситуацию с single page приложениями, но вот с более классическими сайтами всё не понятно.
На сколько я могу смотреть, абсолютно всё на SinglePage не перевести (если у вас не NodeJS то много гемора с SEO). А если тягать CSS/JS в произвольных местах при каждой загрузке страницы явно перебор.
Сейчас мы стараемся уменьшить количество загрузок CSS и загрузить его раньше всех, а JS поставить прям перед (ну не весь конечно). Или shadow dom из веб компонентов позволяет не ждать его загрузки, для отображения самой страницы?
Короче это всё в моём понимании ломает pipe line рендринга страницы.
Если я не прав и мои страхи беспочвенны то пожалуйста напишите, в целом идея изоляции компонентов она интересная.
На сколько я могу смотреть, абсолютно всё на 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 — это отдель ностоящая штука, как jQuery, скорее всего в браузеры встроена не будет. А вот полифилы Polymer Platform — да, можно будет когда-то отключить.
Совершенно нормально работает с не-SinglePage страницами, отлично индексируется поисковиками, так как HTML кода на выходе меньше, по сути только контент, и для изменения представления достаточно изменить веб-компонент, а не исходный HTML, это то о чём я уже давно говорил на счёт шаблонизаторов.
Рендеринг не ломает, просто попробуйте поработать — увидите. Как пример могу показать приложение для Firefox OS — там исключительно веб-компоненты, и работает нормально, ещё один проект с закрытым кодом, потому показать не могу, но, скорее всего, некоторые компоненты для форм (выпадающие списки, инпуты, чекбоксы кастомные и прочее) будут позже выложены в Open Source.
А ещё веб-компоненты это не обязательно Polymer, как считает автор статьи:
Ну и еще существует большая вероятность, что Polymer-ное виденье будущего станет реальностью, и вы в будущем просто отключите Polymer и все продолжит работать нативно.
Polymer — это отдель ностоящая штука, как jQuery, скорее всего в браузеры встроена не будет. А вот полифилы Polymer Platform — да, можно будет когда-то отключить.
Я не считаю что веб-компоненты это Polymer. Возможно не правильно выразился. Я имел ввиду именно полифилы.
По скорости поддерживаю, по крайней мере то что я протестировал — работает быстрее angular-a, даже в ie (не знаю какой, последний).
По скорости поддерживаю, по крайней мере то что я протестировал — работает быстрее angular-a, даже в ie (не знаю какой, последний).
Ну про HTTP 2.0 я знаю, а вулканизация наверное решит проблему с лишними сетевыми запросами, и всё же что с рендрингом?
Ведь если у нас возникает css где то в центре html то браузер не показывает картинку пока этот css не скушает.
Или с JS, если инициализация компонента будет долгой, то пользователь увидит всё до компонента, потом будет тупняк и пользователь увидит всё после компонента? Я знаю что есть всякие defer и прочее, но как это реализовано тут?
К примеру скорость работы gmail, adsense, analytics меня не очень устраивает, я знаю что это ещё не веб компоненты но автор тот же.
Ведь если у нас возникает css где то в центре html то браузер не показывает картинку пока этот css не скушает.
Или с JS, если инициализация компонента будет долгой, то пользователь увидит всё до компонента, потом будет тупняк и пользователь увидит всё после компонента? Я знаю что есть всякие defer и прочее, но как это реализовано тут?
К примеру скорость работы gmail, adsense, analytics меня не очень устраивает, я знаю что это ещё не веб компоненты но автор тот же.
Посмотрите их демо www.polymer-project.org/apps/topeka/
В polymer есть атрибут unresolved для body, он решает проблему частичной отрисовки, пока страница не готова — она не показывается. Это простое решение. Визуально выглядит как белый фон, потом плавно появляется содержимое. Не мешает совершенно.
Я бы не сказал что прям автор тот же. Да, Google активно продвигает идею, но она основана на стандартах, то есть не является проприетарной, к тому же при нативной поддержке работать будет гораздо быстрее любых шаблонизаторов и подобных вещей.
Я бы не сказал что прям автор тот же. Да, Google активно продвигает идею, но она основана на стандартах, то есть не является проприетарной, к тому же при нативной поддержке работать будет гораздо быстрее любых шаблонизаторов и подобных вещей.
www.polymer-project.org/components/paper-elements/demo.html#paper-menu-button — ужасно тормозит на Firefox 32 linux, хотя в chrome достаточно шустро.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Веб-компоненты в реализации Polymer от Google