Как стать автором
Обновить
60
-1

Tech Lead / Full Stack / R&D

Отправить сообщение

Нормально. У BMW давно поворотники работают только по подписке.

А если серьезно, то даже на УАЗ Патриот подписка на дистанционный запуск через приложение уже несколько лет. Никто ей не пользуется, но зато ребята в тренде.

Призыв выкинуть реакт и юзать htmx - поддерживаю. А вот противопоставление SSR и CSR - это ерунда какая-то. Одно другому не мешает и никак не противоречит. Можно использовать гибридный подход, как все нормальные люди сейчас и делают.

То есть, они сами внесли фактор расовой предвзятости в эксперимент (когда подбирали имена), и получили его обратно на выходе? Гениально. А главное, вывод то какой?

Раньше, почему-то, эту страну особо не интересовали ваши тестикулы, но что-то, наверное, произошло... Интересно, что именно?

Зато отлично ассоциируется с экспериментом.

О, мантра про маркетологов. Вот только совсем мимо. Кибертрак - это отличный инженерный эксперимент на тему сокращения издержек на очень затратных тех-процессах - формовке кузовных панелей и окраске. Насколько этот эксперимент успешен - еще рано судить, но презрительно называть его авторов "маркетологами" и "смузихлебами" - это значит расписаться в собственной неспособности смотреть на вопрос немного глубже и шире.

Кибертраку ржавчина к лицу, от нее он будет выглядеть еще брутальнее. Это вообще довольно занимательный арт-объект, к которому общепринятые, в автомире, мерки не вполне применимы. И это не сарказм, я вполне серьезно. Кому нужна просто большая мощная машина - купят Тундру или F150. Меня лично, в Кибертраке больше смущает то, что в Тесла побоялись навалить больше брутализма в салоне, сделав его значительно более "гражданским" чем экстерьер.

Однако пока мне не понятна практическая область применения этой фичи. Обычно компоненту не нужно стилизовать что-то на уровне выше себя. Но, возможно, есть какие-то узкие кейсы.

Все просто: лишние shadow root для каждого интерфейсного примитива (типа кнопки или иконки) - это лишний оверхед. Создание Shadow DOM - штука не бесплатная, можете попробовать создать в цикле много элементов с Shadow DOM и без, увидите очевидную разницу в скорости и потреблении памяти на страницу. Помимо этого, это вносит свои нюансы в сами подходы к стилизации. Однако, если у ваших примитивов не создается Shadow DOM, это не значит, что их нет выше. Более того, абстрактные библиотечные элементы не знают в каком именно контексте документа они используются и что там выше по иерархии. Если вы делаете UI-kit, виджет или микрофронт - вам понадобится изоляция, но только "по верхней границе". Соответственно, у вас должна быть возможность добавить стили только в соответствующий изолированный скоуп. Селектор :root в этом случае, не может быть использован для этих целей в общих стилях документа. Не думаю, что это очень узкие кейсы.

Примерно так же работает и Lit, он тоже создаёт виртуальный <template> под капотом. Тут лишь разница в реализации.

Да, но формат самого темплейта - это разница принципиальная, в одном случае вы можете использовать HTML вне, непосредственно, JS рантайма, а в другом - нет.

Потому что вынести разметку в отдельные файлы можно и в Lit при помощи дополнительных лоадеров, я думаю. А гидрация разметки с сервера возможна благодаря Declarative Shadow DOM (с тонким полифиллом на 20 строк для Firefox). Говоря о стандартах, я имел ввиду, что со временем это будет возможно в браузере нативно, без дополнительных обвязок.

Declarative Shadow DOM это не совсем та гидрация. Гидрация - это когда браузер создает DOM на этапе парсинга HTML-документа, и с уже созданными элементами вы взаимодействуете полноценно в рамках логики своих компонентов, без каких-либо лишних перерисовок. То есть, в очередной раз, речь идет о формате описания биндингов, основанном на атрибутах, для которых вообще не нужен JS-рантайм.

Когда все пропозалы станут стандартами и получат поддержку в браузерах - наступит прекрасное время, но с Symbiote.js вы можете использовать эти принципы уже сейчас.

Если Symbiote использует какую-то свою реализацию, то не факт, что он сможет без проблем с неё переехать на стандартную реализацию.

Symbiote - это не полифил, у него нет цели ранней адаптации черновиков стандартов. Но при этом, вы имеете почти 100%-ю гарантию, что сможете использовать как нативные возможности так и симбиотовские API, как по отдельности так и одновременно.

Мне кажется, что в комплексных приложениях для этого будут использоваться менеджеры состояний или разные Pub-Sub, шины событий и т.д.

В Symbiote.js встроенный Pub/Sub для этих целей и используется. Как для локальных данных компонентов так и для любых абстрактных. Вполне достаточно для сложных приложений, где структура данных представляет собой динамической граф, например.

Интересно, минусующие могут как-то пояснить свои минусы? Похожий коммент ниже набирает плюсы...

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

Не пойму, что здесь такого необычного. Они же не технические собеседования проводят. Одно из интервью в серии. Точнее, финальное, перед офером.

Дополню про :host-context() : это очень похоже на то, как работает интерфейс rootStyles в Symbiote.js. Отличие в том, что `rootStyles`, может работать без Shadow DOM, как основной метод стилизации, в общем случае. И поддерживается во всех современных браузерах, а не только в Chrome.

Я же говорю, НЕ В БАНКЕ. В банк, особенно в рф, я не пойду работать из принципа. Я понимаю, что у всех людей принципы разные, но если область интересов СБ, относительно моей скромной персоны, явно выходит за рамки здоровых трудовых отношений, и приоритеты при оценке меня, как специалиста, выходят за рамки моих профессиональных навыков, то мне такой работодатель - не интересен.

Не до конца понял мысль. Но если речь про добавление стилей на элемент, который содержит теневой корень

Нет, речь о добавлении стилей в родительский, по отношению к элементу скоуп. Это может быть как верхнеуровневый shadow root так и сам документ. Симбиот умеет работать с изолированными и внешними, по отношению к точке интеграции, стилями одновременно, и под капотом, как и Lit, использует adoptedStyleSheets.

В Lit этот объект создаётся для хранения информации и точечного обновления DOM

Symbiote, конечно-же, тоже не использует VDOM, он создает виртуальный элемент template из строки при создании самого класса компонента, и потом уже создает подписки на свойства при его репликации (создании экземпляра). То есть, все изменения вносятся максимально эффективно, без каких-либо лишних перерисовок. Проверить это можно в песочнице, открыв девтулз: https://symbiotejs.org/2x/playground/basic/ - в этом примере, меняется только содержимое текстовой ноды.

У рабочей группы веб-компонентов как раз есть идеи HTML Module Script и DOM Parts

Пока у рабочей группы есть идеи, Симбот уже поддерживает это из коробки. Не сам черновик спецификации конечно, а вещи концептуально очень похожие. То есть, буквально, поддерживает шаблоны переданные в общем документе, как HTML. Когда появится поддержка нативного API, Симбиот на него переедет.

А вот это интересно.

Да, например, можно делать вот так: https://symbiotejs.org/2x/playground/css-data/

Если я ничего не путаю, то у Lit для этого есть пакет @lit/context

С Симбиотом такого рода взаимосвязи задаются просто в шаблоне, с помощью одного-единственного токена `^`, определяющего, что свойство определено в каскадном контексте. Напрмер:

let template = html`
  <button ${{onclick: '^upperLevelClickHandler'}}>Click me!</button>
`;

Или, аналогично, в HTML:

<button bind="onclick: ^upperLevelClickHandler">Click me!</button>

Никакие дополнительные пакеты не нужны. Установка связей между компонентами, причем сложных связей, даже между компонентами от разных поставщиков - это и есть смысл существования этой библиотеки.

Согласен. Я название LitElement использовал, наверное, по инерции, когда он только появился, еще во времена Polymer, авторы так сами называли либу.

История о том, как автор сам выстрелил себе в ногу.

Я как-то давно проходил интервью службы безопасности. Вежливо, но прямо сказал, что отвечать на вопросы, которые их не особо касаются, я не собираюсь. Сотрудник ответил что понимает, и утвердил мою кандидатуру. Оказался адекватом. Но это был не банк, а просто крупная IT-компания.

сильно зависит от стиля написания кода, что как бы не совсем объективное сравнение

Ну блин, ну серьезно, я способен воспроизвести стиль кода, это не какая-то сверхзадача. Вполне объективно. А если вы о объеме кода всего приложения - то в статье об этом есть отдельное упоминание. Но ок, не верите мне - проверьте сами.

Метод render в Lit обладает контекстом this

В своей статья я буквально заявляю, что для меня это недостаток, а не достоинство. Но невозможно в одном материале сделать акцент сразу на всем и в деталях раскрыть почему именно. В общих чертах я попытался это сделать. Я довольно много работал с Lit, чтобы говорить об этом. У абстрактных шаблонов больше преимуществ в тех контекстах, с которыми я сталкиваюсь на практике, об этом я тоже написал. С другой стороны, функция html имеет свою сигнатуру и типизацию, а, соответственно, и подсказки редактора, линтеры и все прочее... Вопрос с выводом типов стейта - более сложный, поскольку в Симбиоте это динамический объект. Здесь также две чаши весов, со своими преимуществами и недостатками, как у слабо-связанной и сильно-связанной архитектуры.

Для шаблонов в Symbiote без какого-то дополнительного туллинга, как у того же angular, может стать больно. И совсем не очевидно как составлять сложные компоненты, с условиями, списками и т. д.

Не понятно с чего вы это взяли. Что сложного в композиции шаблонного литерала? Что сложного в списках:

MyComponent.template = html`
  <div itemize="userList">
    <div>{{firstName}}</div>
    <div>{{secondName}}</div>
  </div>
`;

История Симбиота начинается с тех времен, когда у Lit был еще экспериментальный статус. Тогда основным мотивом того, чтобы попробовать пойти своим путем, было то, что либа-прородитель Симбиота показывала существенное преимущество в производительности: ~ 30% быстрее при первичной отрисовке UI и ~ 50% при обновлении данных. Потом фокус был смещен с производительности на возможности композиции в рамках DOM. Я это к тому, что вся цепочка решений в эволюции Симбиота была с постоянной оглядкой на то, что происходит с Lit и другими либами. И вопрос DX никогда не выходил из рамок базового фокуса.

Забавный факт: сейчас проверил, у Симбиота без декораторов строк получается +/- столько-же, сколько у Lit с декораторами.

Хороший аргумент. Декораторы действительно очень помогают в борьбе с бойлерплейтом. Но, мне кажется, что разработчики Lit не используют декораторы в своей песочнице ровно по той-же причине, по которой их пока нет в Симбиоте - они не поддерживаются в браузерах. Для их поддержки вам необходим TypeScript или Babel. А так как Симбиот позиционируется как библиотека для создания встраиваемых решений, это означает, автоматически, наличие дополнительных требований к окружениям разработки и средам интеграции. Поэтому, Симбиот остается агностиком по максимуму, в этом и есть главная идея его философии.

Пример абсолютно ненаглядный

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

Нет, все наоборот. Императивное создание элементов работает существенно медленнее чем парсинг HTML, если вы об этом. Помимо этого, парсинг шаблона компонента и его репликация при создании экземпляра - это разные этапы работы.

Информация

В рейтинге
Не участвует
Дата рождения
Зарегистрирован
Активность

Специализация

Fullstack Developer, Chief Technology Officer (CTO)
Lead
От 8 000 $
JavaScript
HTML
CSS
Web development
Node.js
TypeScript
Project management
Design
Researching