R
вообще веб-компоненты мне кажутся оптимальным путем длля “переползания” с легаси
да можно и наоборот с сплошного SPA на нативный JS через них вылезти
Size: a a a
2020 February 19
MB
вообще веб-компоненты мне кажутся оптимальным путем длля “переползания” с легаси
Причем постоянного переползания, с наименьшим оверхедом
MB
У меня были дебаты не раз с разными людьми. Например с @paulcodiny . По поводу того, а не проще ли просто с нуля каждые 2 года переписывать все на новом условном FancyJSFramework чем писать все на веб компонентов. Вопрос открытый. Я думаю, что для некоторых компаний не проще.
АР
У меня были дебаты не раз с разными людьми. Например с @paulcodiny . По поводу того, а не проще ли просто с нуля каждые 2 года переписывать все на новом условном FancyJSFramework чем писать все на веб компонентов. Вопрос открытый. Я думаю, что для некоторых компаний не проще.
Компоненты тоже приходится переписывать. Если юзал ванильные, то из-за V0 -> V1. Если юзал либы типа Polymer, то тоже с Polymer 1 на Polymer 2, потом из-за Bower -> NPM на Polymer 3, сейчас вот на LitElement.
АР
Если в Polymer был two-way data binding, то в Lit от этой концепции отказались. В итоге во многих компонентах логично по другому диспатчать эвенты (не при изменении проперти на каждый чих).
АР
Причём эти переезды реально подкосили количество компонентов. Многие просто забили и не стали свои компоненты обновлять.
АР
Так что ни чем не лучше переписывания с одной версии фреймворка на другую.
АР
Я помню сколько компонентов было на customelements.io и когда появился потом webcomponents.org, там и 10 части нет до сих пор.
MB
понимаю что ты говоришь, но практика в моем случае показала обратное
с болью и сложностями я видел как приложение, над которым совокупно работали сотни разработчиков, переписывали постепенно с Polymer на LitElement
с болью и сложностями я видел как приложение, над которым совокупно работали сотни разработчиков, переписывали постепенно с Polymer на LitElement
MB
на таком скейле выходят на первый план совсем другие вещи
люди заботятся не о том, чтобы условно бандл был максимально маленьким или чтобы API был не изменен при переписывание
а о том, чтобы можно было брать отдельный умный компонент и заменить в нем маленькие крупицы, а потом и сам компонент переписывать на новый LitElement
люди заботятся не о том, чтобы условно бандл был максимально маленьким или чтобы API был не изменен при переписывание
а о том, чтобы можно было брать отдельный умный компонент и заменить в нем маленькие крупицы, а потом и сам компонент переписывать на новый LitElement
MB
и на таком скейле переписывать с какого-ибудь Angular 7 на Angular 8 было бы вероятнее всего даже сложнее
у меня как раз будет будет возможность сейчас такие переписывания сравнить
у меня как раз будет будет возможность сейчас такие переписывания сравнить
2020 February 20
АР
Внезапно:
АР
Не прошло и 6 лет. 😂
AM
Не прошло и 6 лет. 😂
Боюсь, что первое сообщение и второе как-то связаны. Polymer. Некоторые функции могут не работать
2020 February 21
DS
и на таком скейле переписывать с какого-ибудь Angular 7 на Angular 8 было бы вероятнее всего даже сложнее
у меня как раз будет будет возможность сейчас такие переписывания сравнить
у меня как раз будет будет возможность сейчас такие переписывания сравнить
Переписывал проект с angular 7 на 8 - проблем не возникло (в проекте на тот момен было 67 тысяч наших файлов, несколько сотен модулей).
DS
По поводу lit-element не скажу, а вот в целом в wc меня сейчас больше смущает завязка на lit-html (поняно, что теоретически можно и без него, но все используют его или hyper или stencil) в итоге получается, что нельзя написать и забыть. Все равно придется обновляться даже без учета изменения стандартов.
AY
По поводу lit-element не скажу, а вот в целом в wc меня сейчас больше смущает завязка на lit-html (поняно, что теоретически можно и без него, но все используют его или hyper или stencil) в итоге получается, что нельзя написать и забыть. Все равно придется обновляться даже без учета изменения стандартов.
Ну даже если писать используя чисто API WC, всё равно вырастает фреймворк, всё равно поддержка, обновления, вот это всё, только возможно еще хуже.
MB
По поводу lit-element не скажу, а вот в целом в wc меня сейчас больше смущает завязка на lit-html (поняно, что теоретически можно и без него, но все используют его или hyper или stencil) в итоге получается, что нельзя написать и забыть. Все равно придется обновляться даже без учета изменения стандартов.
Все так, но сложность переписывания иная. Потому что связанность компонентов маленькая. Фреймворки не потому сложны, что предоставляют много из коробки, а потому, что создают слишком много магии за счет тесной связанности различных компонентов системы
MB
Поэтому я бы предложил lit-html считать библиотекой. Как и LitElement.