HTML *

Ранее мы говорили о том, как улучшить кэширование наших проектов и правильно загружать поставщиков. А в этой статье мы рассмотрим следующее:
- Как мы можем использовать стратегии предварительной загрузки, включая что такое "магические" комментарии 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, такие отчеты можно было создать в несколько кликов и практически без знания кода — за счет мощного и удобного дизайнера:

Ниже я приведу примеры, как пустить пыль в глаза юзерам можно улучшить ситуацию с ощущением чужеродности приложения среди других, написанных на честном Gtk, китами из XCode, Windows UWP и прочим с 0% вайбкодинга

Мне часто доводится вести странные споры с фанатами фреймворков о том, действительно ли <div> «столь же хорош», как и <button>.

Спойлер: нет. И давайте выясним, почему.

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

или как я сделал протокол связи через свет с точностью 99.2 %

Когда мы говорим “оплата телефоном”, в голове сразу всплывает NFC или QR.

А что, если экран и фонарик сами могут обмениваться данными?

Без радиоволн, без Wi‑Fi, без сети вообще.

Так появился Lightprint — протокол, который передаёт данные светом, а камера принимает их и распознаёт как уникальный «отпечаток».

И всё это работает прямо в браузере, на чистом JavaScript.

Полистав различные ресурсы в Интернете и просмотрев множество видео по данной теме, я решил составить наиболее полную картину по данному, не побоюсь этого слова, революционному API, чтобы вы уже сегодня могли начать использовать его в своём проекте!

Всем привет! Меня, как и многих здесь, в какой-то момент достало. Достало логиниться по SSH, чтобы проверить htop. Достало запускать Termius на телефоне, чтобы сделать sudo reboot зависшему инстансу. Достало ставить тяжелые веб-панели, которые жрут ресурсы и открывают лишний порт, только ради того, чтобы посмотреть загрузку диска.

Я админю несколько VPS. На одних крутятся пет-проекты, на других — сайты, на третьих — кастомные сетевые приложения для транспортировки данных. Мне нужен был инструмент, который:

Хабр, я снова пришёл к вам с практическими советами про доступность вместе с Ильёй. Мы показываем, как HTML и CSS могут улучшить или ухудшить её. Напоминаю, что Илья мой незрячий знакомый, который помогает мне найти наши косяки в вёрстке.

Сегодня мы рассмотрим следующие аспекты:

• где полезно использовать элемент search;

• существующие проблемы при использовании единиц измерения от размеров вьюпорта для установки размера текста;

• как элемент hr влияет на опыт пользователей скринридера;

• нужны ли заголовки модальным окнам.

Давайте начнём!

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