Привет, Хабр!

Я еще помню времена, когда принудительное ООП было доминирующим паттерном. Сейчас это очевидно не так, и все современные ЯП предлагают намного больше парадигм. Однако в области веб-разработки тотально (и на мой взгляд неоправданно) доминирует реактивность, которая в свое время эффективно решила проблему несовершенного DOM API, попутно создав несколько архитектурных проблем вроде централизованного хранилища данных (что вообще-то нарушает принципы SOLID), или переусложненного механизма взаимодействия компонентов. В условиях современных WEB-стандартов, реактивность нуждается как минимум в некотором переосмыслении. Например, реактивная парадигма прекрасно выглядит, если наш стейт централизован (не случайно самый популярный стек это react / redux), а если он распределен по дереву компонентов (что архитектурно правильней), то зачастую нам нужно меньше реактивности, а больше аккуратной императивности.

Свои проекты я пишу на ванильных веб-компонентах, в стиле императивного ООП, с минимальным количеством библиотечного кода, и очень редко действительно скучаю по реактивности. Если бы чистая реактивность покрывала все потребности разработчика, не пришлось бы в каждом фрейморке создавать императивные лазейки, позволяющие модифицировать компонент вместо его пересоздания (рефы, неуправляемые формы, $parent и т.д.). А когда стоит задача получить экстремально-отзывчивое приложение, то волей-неволей приходится думать (и вручную контролировать) момент и способ обновления DOM, как собственно и сделано в большинстве хороших PWA (например Twitter) и не сделано в менее хороших PWA (например VK). Так, большие списки выгодней формировать методом insertAdjacentHTML(), который вполне способен работать с текстово-параметризуемыми веб-компонентами, но вряд-ли применим к управляемым компонентам, и таких примеров достаточно.

С ростом популярности веб-компонентов и связанных библиотек вроде Polymer, польовательские элементы стали привлекательным способом создания UI. Изначальная инкапсуляция пользовательских элементов делает их особенно полезными в создании независимых виджетов.

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

В Polymer пользовательские элементы декларативные, то есть они импортируются в проект, их очень просто подключить и настроить прямо в HTML, то есть передавать данные через атрибуты.

Было бы здорово избежать повтора и быть уверенными в согласованности данных повторно используя те же сниппеты для разных виджетов, а так же информируя поисковые системы и других потребителей о содержимом на странице. Мы можем достичь этого используя стандарт schema.org и JSON-LD формат для наших данных.

Привет, Хабр! Начнём неделю с разговора о том, как сочетать в работе JSON-LD и Web Components. JSON-LD – это формат структурирования данных на сайте для их отображения в результатах поиска Google и других поисковых систем. Например, если на сайте представлен список событий, мест или людей, то в HTML-код можно добавитьразметку этих данных при помощи конструкций словаря schema.org в виде кода JSON-LD. Структурирование данных помогает Google лучше понимать содержание ваших страниц и выделять его в результатах поиска. Так можно сообщить о предстоящих мероприятиях посредством функции «Сеть знаний» или показать расширенное описание страниц в поисковой выдаче.

Настало время поприветствовать Хабрахабр от имени стартапа Ecoisme!

Администрация уже давненько предоставила стартаперский аккаунт для нашей компании, а мы взамен пообещали рассказывать обо всяких интересных штуках, которые у себя используем.

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

В последнее время на хабре было несколько статей о CMS написанных их разработчиками, вот и я решил написать.
О CleverStyle CMS я уже писал дважды (последний раз год назад), и дважды получал огромный спектр критики и большую пачку замечаний разного плана — спасибо за всё, я потратил время на то, чтобы учесть ошибки и исправить их.

Статья опять для разработчиков, в ней я попытаюсь донести простым языком преимущества использования именно этого движка для разработки сайта, речь пойдёт об одном из самых важных и функциональных компонентов — о модуле.

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

Но, как правило, эти материалы ограничиваются рассмотрением довольно утопичной ситуации: мы делаем отдельный проект, создаем angular-компонент, настраиваем проект на сборку Elements и, наконец, компилируем несколько JS-файлов, подключение которых к обычной странице даст нам необходимый результат. Ура, компонент работает!..



На практике же возникает потребность вытащить несколько компонентов из готового работающего angular-проекта, да еще желательно так, чтобы не влиять на его текущую разработку и использование. Эта статья получилась как раз благодаря одной из таких ситуаций: я хотел не просто собрать отдельные элементы проекта, а сделать процесс компиляции целой UI-библиотеки на Angular в набор файлов с нативными веб-компонентами.

Автор материала, перевод которого мы сегодня публикуем, полагает, что если вы собираетесь использовать при проектировании интерфейсов своих приложений веб-компоненты и подыскиваете подходящую библиотеку, независимую от UI-фреймворков, вам стоит взглянуть на те проекты, о которых пойдёт здесь речь.

Мы, сотрудники GitHub, гордимся тем, что наша платформа обеспечивает тем, кто ей пользуется, первоклассный «опыт разработчика» (Developer Experience, DX). Значительная часть наших усилий сосредоточена на фронтенде системы, который мы стремимся сделать настолько простым, быстрым и доступным, насколько это возможно. Для проекта таких масштабов, как GitHub, это — та ещё задача. В кодовой базе нашего фронтенда, как и во многих других подобных кодовых базах, применяются компоненты — независимые, изолированные фрагменты кода, пригодные для многократного использования. Они позволяют командам, которые занимаются проектом, создавать тщательно проработанные интерфейсы, делая своё дело быстро и эффективно, но при этом не отступая от высоких стандартов качества, принятых в GitHub.



Мы, в работе над GitHub, широко используем веб-компоненты. У нас имеется почти два десятка опенсорсных веб-компонентов, и ещё несколько десятков компонентов, код которых закрыт.