Использование вулканизации для polymer-модулей

[i360u]

1. Названия веб компонентов должны содержать дефис и закрывающий тег по стандарту: не <App/> как в Реакте, а <my-app></my-app> (Или <app-shell>, если уж говорить о какой-то общепринятой декомпозиции). Если у вас в одном коде декларации компонентов в разных стилях для разных декомпозиционных библиотек — это ад. И само использование в одном проекте разных инструментов делающих одно и то-же — безумие.
2. Подгрузка приложения по частям — это скорее преимущество, если вы работаете с http/2 и server push, вулканизация не нужна как таковая, она может понадобится только в отдельных узких местах.
3. "Глупые компоненты" — это другое: это компоненты содержащие разметку без логики. Iron и paper — не глупые компоненты, а скорее UI-примитивы и утилиты.
4. Polymer-компонент (как и любой веб-компонент) может сам содержать ссылки на все свои зависимости (вкючая ядро Polymer), и если он не вызван на странице — ничего лишнего к ней не подключается.

точно будет дублирование ядра polymer

Polymer подключается из одного места, там ничего не дублируется.

В общем, статья про то, как создать франкенштейна. Не делайте так.

[kolesoffac]

1. По <App/> — это было описано для «схематичного» описания решаемой проблемы. И данные инструменты делают не одно и тоже, а просто расширяют возможности использования системы для решения специфичных задач.
2. Возможное преимущество, но не всегда
3. Я специально написал, что я их так назвал в контексте статьи, что бы разделить по типу
4. Для динамической прогрузки компонентов через importHref, ядро должно быть подгружено раньше

А по поводу не делайте так, я написал в выводах, что статья для специфичной задачи и иллюстрирует один из подходов и делать так везде не обязательно. И даже не нужно.

[i360u]

1. Они (библиотеки) решают одну задачу: декомпозицию вашего вью. Плюс стандартный набор из всяких байндингов и репитеров. Не одно и то-же могут тут делать только сами виджеты, специфичные задачи — только у них. Смешивать это все в одну кашу стоит только при миграции на другой стек и только временно, например, постепенно заменяя React-компоненты веб-компонентами.
2. А когда не?
3. Это устоявшаяся терминология. Переопределять ее на время написания статьи… Крайне странно.
4. Я говорю не о динамической загрузке, а о том, что если браузер не встретит в разметке текущего вида вызова веб-компонента — он просто не импортит его зависимости. А если вы собираете бандл вулканайзом — то да — может загрузиться куча ненужного.

Вы просто описали плохой паттерн который не стоит воспроизводить а значит и развивать специфичный для него тулчейн.

[kolesoffac]

1. Мнение имеет право быть: но в данный момент это не каша, а расширение технологических возможностей системы, не мешающие друг другу, а только увеличивающие эффективность системы в целом. Можно по разному смотреть на ситуацию. Может быть со стороны это кажется кашей, но на практике достаточно гибкое и эффективное решение в использовании различных технологических подходов использования нескольких render-engine'ов в одной обертке системных виджетов.
2. Мнения могут быть разные, но можно сказать одно — вы пробовали когда нибудь копировать тысячу мелких файлов с флешки? И сранить тоже самое когда их запихать в архив — производительность будет на лицо.
3. ГК — который не делает никакой логики, а просто рендерит переданый ему стейт. Поэтому так и назвал. Мне кажется, нет противоречий.
4. В каждом подходе есть + / -.

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

[RuLeZzzBlaBlaBla]

Я конечно ничего не знаю о полимере, но складывается ощущение, что webpack должен решать такую задачу с меньшими усилиями, чем rollup

[kolesoffac]

А Rollup в данном подходе и не хэдлайнер. Думаю, что это можно решить и через webpack, но я использовал именно Rollup.