HTML *

После работы с React/Vue/Angular захотелось вернуться к основам, но с современными возможностями. Сделал RWC — библиотеку реактивных веб-компонентов.

Ключевые преимущества:
• Совместимость — компоненты работают в любом проекте
• Производительность (сигналы для реактивности) — точечные обновления DOM
• Простота — минимальный API, легко обучать команду
• TypeScript-first — типизация из коробки без костылей

Компоненты, написанные на RWC, можно встроить в React, Vue, Angular или даже legacy jQuery-проект. Никакого vendor lock-in.

Библиотека весит <10KB, компоненты работают в любом проекте.

Пора к части второй! У нас уже есть очень хорошие функциональные тултипы с позиционированием, но они в основном «смотрели» вверх или вниз и смещались у краёв, чтобы избежать выхода за границы. Теперь мы пойдём дальше и рассмотрим четыре позиции без смещений.

Устал от однообразных каруселей? В статье показываю, как шаг за шагом собрать 3D-таймлайн-слайдер с перспективной сеткой, плавной прокруткой и переключением категорий на чистом TypeScript и CSS.

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

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

Кто же будет первым? Более 12 лет я являюсь клиентом Приорбанка (Беларусь, РБ). Банки — это важные сервисы, они определенно должны быть доступны людям с ограничениями. Я решил начать именно с него, это сервис который важен и для меня, поэтому в двойне интересно это сделать. Да простят меня сотрудники банка!)

Привет, Хабр! На связи Герман Frontend-разработчик в Webest, и сегодня хочу поделиться тем, почему мы продолжаем использовать препроцессор SASS/SCSS в наших проектах, несмотря на растущую популярность Tailwind и CSS-in-JS решений.

К слову, мы не «олдскульные фанаты» SASS, и Tailwind тоже используем, но в зависимости от типа проекта. Комбинированный подход дает гибкость, особенно в масштабируемых фронтенд-системах.

Ранняя версия Sanitizer API была реализована в Chrome, но позже была удалена. Поэтому не стоит ориентироваться на старые материалы — спецификация API со временем значительно изменилась.

На данный момент Sanitizer API поддерживается в Firefox Nightly в соответствии с актуальной спецификацией. В Chrome Canary он также доступен, но только при включении специального флага. В Safari реализация пока не ведется, однако команда разработчиков Safari выразила поддержку этой инициативе.

Trusted Types API уже реализован в Chrome/Edge, Samsung Internet, Safari и Firefox Nightly. В Chrome он поддерживается начиная с версии 83, а начиная с версии 144 полностью соответствует последней спецификации и реализации в других браузерах.

Тултипы — классика веб-разработки. Кликаешь по элементу — и рядом всплывает небольшой «бабл» с дополнительной информацией. Но за этим простым кликом почти всегда стоит JavaScript, который рассчитывает, где именно показать тултип.

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

В этой статье я покажу, как написать хороший JavaScript, который обработает все такие случаи…

Шучу! Мы обойдёмся CSS и посмотрим, как современный Anchor Positioning API может помочь со всем этим. Никакого тяжёлого JS и лишних проблем с производительностью.

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

Ранее мы говорили о том, как улучшить кэширование наших проектов и правильно загружать поставщиков. А в этой статье мы рассмотрим следующее:
- Как мы можем использовать стратегии предварительной загрузки, включая что такое "магические" комментарии Webpack, и что такое спекулятивная/ручная предварительная загрузка;
- Как мы можем запрашивать данные с сервера, не дожидаясь загрузки наших статических файлов;
- А также какие сторонние или наши собственные решения могут быть использованы для этого.

Ранее мы поговорили о том, как сделать дерево зависимостей нашего проекта максимально чистым и почему это важно для ленивой загрузки. А в этой статье мы расскажем о следующем:
- Как мы должны загружать вендор файлы с точки зрения правильной организации ленивой загрузки.
- Что общего между стратегиями оптимизации "ленивой загрузки" и "кэширования", и как использование одной из них влияет на другую.
- Что такое кэшируемость и как сделать наше приложение максимально кэшируемым.
- А также как правильно настраивать группы кэша в Webpack и не испортить кэшируемость.

Ранее мы обсуждали самые основы ленивой загрузки и то, почему она вообще важна. А в этой статье мы рассмотрим следующее:
- Как бандлеры анализируют файлы исходного кода, строят деревья зависимостей и генерируют файлы для сборки.
- Как они генерируют файлы JavaScript из исходного кода.
- Как браузеры решают, какие сгенерированные файлы следует загружать, чтобы отобразить ленивую страницу/компонент.
- И как мы можем уменьшить размер и количество загружаемых файлов, правильно настроив структуру файлов и корректно используя статический импорт.

Ленивая загрузка - это принцип, который должен быть известен большинству frontend разработчиков. Однако, этот механизм обманчиво прост, и его освоение является гораздо более комплексной задачей, чем кажется многим. Если уже используете Lazy Loading, у вас все равно могут быть серьезные пробелы в знаниях. Но даже если вы считаете, что знаете про ленивую загрузку абсолютно все, освежить память не будет лишним.

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

Пишем Slider с Web Components
В этой статье мы создали полнофункциональный слайдер, используя современные веб-стандарты. Мы не только реализовали базовую логику, но и освоили ключевые концепции:

• Работу с Shadow DOM для изоляции стилей и структуры

• Использование слотов для композиции контента

• Реакцию на атрибуты для настройки поведения компонента

• Организацию жизненного цикла через connectedCallback

Современный фронтенд напоминает перегруженный интерфейс: мощные возможности, но чтобы начать работать, нужно изучить десятки концепций. React, Vue, Angular — у каждого свой сложный путь изучения.

Мы задались вопросом: что действительно нужно знать, чтобы создавать UI?

Оказалось, всего четыре концепции: компоненты, состояние, эффекты и DOM. Все остальное — синтаксический сахар и edge cases.

Так родился наш эксперимент: упаковать эти основы в максимально простую модель. Не изобретать новое, а отшлифовать существующее.

Иногда прогресс — это не добавление возможностей, а смелость убрать лишнее.

Каждый архив самостоятельно выбирает ИС, на базе которой будет предоставлять доступ к оцифрованным делам. Это последствия того самого единственного, на мой взгляд, недостатка.

Можно также отметить и следующие последствия:

не все архивы спешат переходить на цифру

цену доступа к оцифрованным документам регламентирует администрация субъекта

Представьте, что вы — разумный человек. Вы знаете, что CSS — это язык стилей. Cascading Style Sheets. Для оформления. Не для логики. Не для программирования. Просто цвета, шрифты, отступы.

А потом вы заходите на CodePen.

И там кто-то сделал полностью рабочий калькулятор. На чистом CSS. Без JavaScript.

Последняя часть по созданию своего starter-kit.

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

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

При обучении разным языкам программирования всегда есть практики, которым не рекомендуется следовать. Это очень сильно помогает разработчикам избегать ошибок.

Только по какой-то причине сложно найти антипаттерны по языкам HTML и CSS. Может, потому что они не языки программирования?

В общем, у меня появилось желание это исправить. Я собрал несколько примеров, которые лично отношу к антипаттернам. Возможно, это субъективно, но надеюсь, что нет.

Давайте посмотрим, что я вам подготовил.

Компонентно-ориентированный подход уже давно зарекомендовал себя как отличная практика разработки. Его массовая популярность пришла вместе с такими библиотеками, как React и Vue. Создавая компоненты, мы чётко разграничиваем логику, формируем зоны ответственности и эффективно боремся с дублированием кода. Обычно компонент отвечает за рендеринг HTML-разметки и динамически обновляет её в зависимости от своего состояния. Кроме того, ключевую роль играют механизмы контроля жизненного цикла, например, обработка этапов: «компонент присоединился», «компонент обновился» и «компонент был удалён». Это база, но часто существует и множество других хуков.

Раньше для работы с этой парадигмой мы были вынуждены использовать React, Vue или аналогичные фреймворки. Однако сегодня можно обойтись без дополнительных библиотек и обязательной сложной сборки, потому что компоненты доступны «из коробки» в современных браузерах. Да, я говорю о Веб-компонентах. Если быть точнее, о Пользовательских элементах (Custom Elements), поскольку «Веб-компоненты» — это скорее набор стандартных технологий, позволяющих создавать эти самые элементы.

Всем привет! Меня зовут Леонид, я разработчик компании DD Planet.

Как мы все прекрасно понимаем, ни один бизнес‑проект немыслим без разного рода отчетов. Быстрота и удобство их создания зачастую критично важны.

В нашей компании мы долгое время использовали инструмент DevExpress Reports. Однако после ухода DX с отечественного рынка остро встал вопрос о пересмотре архитектуры формирования отчетов — особенно тех, что создавались с помощью визуального дизайнера форм.

Раньше, при использовании компонентов DevExpress, такие отчеты можно было создать в несколько кликов и практически без знания кода — за счет мощного и удобного дизайнера: