В Chromium планируется добавление Raw Sockets API — API для прямых сетевых соединений. Register опубликовал статью про это API — "Chromium devs want the browser to talk to devices, computers directly via TCP, UDP. Obviously, nothing can go wrong".

Идея Raw Sockets API заключается в том, чтобы предоставить браузерным приложениям возможность работать напрямую с сетевыми сокетами. Это открывает новые сценарии использования web-приложений для работы к сетевыми устройствами (сканеры, принтеры) и реализации полноценных ssh-клиентов, irc-клиентов, клиентов децентрализованных p2p-сетей и т.п с помощью web-технологий. Не все разработчики высказываются положительно относительно нового API. Эприл Кинг — инженер по безопасности Mozilla — очень скептически отзывается о попапе как средстве защиты от нежелательных соединений.

Raw Sockets API находится на стадии разработки прототипа. Предварительный план состоит в том, чтобы добавить его поддержку сначала в Chrome OS, а затем в Chromium.

#experimental #chromium

https://www.theregister.com/2020/08/22/chromium_devices_raw_sockets/
https://github.com/WICG/raw-sockets

Еиджи Китамура на web.dev рассказал о том, как упростить процесс обновления данных для аутентификации с помощью менеджеров паролей — "Help users change passwords easily by adding a well-known URL for changing passwords".

Менеджеры паролей в Safari и Chrome (с версии 86) предоставляют элемент управления для быстрого перехода к изменению пароля. Чтобы он правильно работал, на вашем сайте должен быть настроен редирект со страницы /.well-known/change-password на страницу изменения пароля. Для редиректа лучше всего использовать: 302 Found, 303 See Other или 307 Temporary Redirect.

Редирект для /.well-known/change-password уже поддержали Google, Facebook, GitHub и другие сайты. Если на вашем сайте ещё нет редиректа, то его очень рекомендуется добавить.

#web #security

https://web.dev/change-password-url/

Во фронтенде существует подход с добавлением динамики на страницу с помощью легковесных библиотек, которые расширяют синтаксис HTML и предоставляют средства для DOM-манипуляций и отправки запросов на сервер. В эту категорию попадают библиотеки htmx, unpoly, intercooler (предшественник htmx) и TwinSpark.

Александр Соловьёв написал статью про то, как он внедрил в свой проект TwinSpark, и что в итоге получилось — "A tale of webpage speed, or throwing away React".

TwinSpark разрабатывается Александром. Его библиотека развивает идеи intercooler и решает проблему с большим объёмом загружаемого js, наследованием и батчингом запросов. HTML с необходимым набором атрибутов для TwinSpark создаётся на стороне сервера из React-компонентов (для создания HTML может быть использован любой другой подход). TwinSpark добавляет нужную интерактивность уже поверх готовой разметки, то есть на клиенте React не используется. Внедрение нового подхода в проект Александра заняло четыре месяца. В результате JS уменьшился с 2.5Мб до 40Kб, HTML c 700Кб до 350Кб, и очень сильно улучшились метрики производительности.

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

#jsframeworks #performance

https://solovyov.net/blog/2020/a-tale-of-webpage-speed-or-throwing-away-react/

Eleventy (11ty) — это статический генератор сайтов, который сейчас набирает популярность. Его используют Google, Khan Academy, Netlify. Сайт Defront тоже создаётся с помощью этого движка.

Мальте Убл — инженер из Google — недавно опубликовал шаблон для 11ty, который был оптимизирован для создания высокопроизводительных сайтов. Вот его возможности:
— загружает изображения с внешних источников для их быстрой отдачи клиенту;
— генерирует разные размеры изображений и вставляет их в srcset;
— решает проблему с Cumulative Layout Shift (CLS), извлекая размеры изображений и используя их в атрибутах width и height;
— инлайнит CSS и автоматически удаляет неиспользуемые стили;
— использует иммутабельных URL для изображений и скриптов;
— предзагружает шрифты;
— и делает ещё много всего полезного.

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

#library #performance

https://www.industrialempathy.com/posts/eleventy-high-performance-blog/

Натан Себастиан собрал подборку советов для создания расширяемых React-приложений — "6 Tips and Best Practices for a Scalable React Project".

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

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

#react

https://blog.bitsrc.io/best-practices-and-tips-for-a-scalable-react-application-db708ae49227

Дэйв Руперт поделился своим мнением про важность разнообразия браузеров — "What is the Value of Browser Diversity?".

Иногда возникают разговоры о том, что для web-платформы было бы лучше, если бы существовал только один браузерный движок. Дэйв не согласен с этим утверждением. По его мнению разнообразие движков — это большой плюс. Платформа не развивается под давлением корпораций, в которых менеджеры заинтересованы только своим KPI, платформа развивается благодаря консенсусу разных организаций. Такое неспешное и обдуманное развитие даёт плоды в виде продуманных фич, которые не гонятся за трендами, а улучшают платформу на долгие годы вперёд.

Хорошая статья. Рекомендую почитать.

#web #musings

https://daverupert.com/2020/09/the-value-of-browser-diversity/

Увидел новость, что в Chrome 85 для Android появилась поддержка DNS-over-HTTPS. Прочитал статью "A safer and more private browsing experience with Secure DNS" в блоге Chromium, чтобы разобраться в этой теме подробнее.

DNS-over-HTTPS (DoH) — это протокол для безопасного разрешения ip-адреса по названию сайта. DoH предотвращает перехват данных о посещаемых страницах третьими лицами, которые находятся в той же самой сети, что и легитимный пользователь. Эти данные могут быть использованы для фишинга и фарминга. При использовании DoH появляется дополнительный сервер, к которому подключается браузер по HTTPS для разрешения DNS-запросов. HTTPS гарантирует аутентичность, целостность и конфиденциальность DNS-трафика.

Внедрение DoH в Chromium заняло два года, так как DNS уже существует 35 лет и торопливое внедрение могло бы поломать сервисы, использующие старое поведение DNS, например, фильтрацию контента для детей. Более того в некоторых странах (насколько я помню, в Великобритании) отсутствие такой фильтрации могло бы повлечь проблемы с законом для провайдеров интернета.

В Chromium за включение DNS-over-HTTPS отвечает фича "Secure DNS". По умолчанию Chromium пробует использовать сервисы провайдера, чтобы не ломать их механизмы фильтрации, но в настройках браузера (раздел "Security") можно выбрать любого другого провайдера (есть предустановленные сервисы от Google, Quad9, CleanBrowsing, Cloudflare).

#security #chromium

https://blog.chromium.org/2020/05/a-safer-and-more-private-browsing-DoH.html

В Chrome 85 появилась поддержка формата изображений AVIF. Джек Арчибальд написал большую статью про то, в каких случаях он может быть полезен — "AVIF has landed".

AVIF — это новый формат изображений, который основывается на видеокодеке AV1. По сравнению с другими форматами он сжимает изображения гораздо лучше, но у него есть некоторые ограничения. Для изображений, в которых важна высокая детализация, лучше использовать старый-добрый JPEG. Также AVIF не поддерживает прогрессивный рендеринг, когда изображение медленно появляется на странице по мере его загрузки. Лучше всего AVIF подходит для сжатия небольших изображений.

В статье затрагиваются вопросы производительности при сравнении AVIF c SVG. SVG по качеству превосходит все другие форматы, но сложное векторное изображение может быть очень затратным с точки зрения CPU. Поэтому SVG с большим количеством градиентов и фильтров рекомендуется конвертировать в растровое изображение.

Поддержка AVIF появилась в Chrome 85, в Firefox уже идёт работа над его внедрением. Поддержка AVIF в Safari, скорее всего, тоже не заставит себя долго ждать, так как Apple входит в группу разработчиков AV1.

#graphics #optimization

https://jakearchibald.com/2020/avif-has-landed/

В блоге DebugBear была опубликована статья с обзором техник для улучшения производительности spa-приложений — "Performant front-end architecture".

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

Очень хорошая вводная статья про производительность. Рекомендую заглянуть всем интересующимся.

#performance

https://www.debugbear.com/blog/performant-front-end-architecture

Иван Греков написал статью об опыте миграции на TypeScript фронтенд-проектов команды Badoo — "Как перенести на TypeScript большую кодовую базу React UI-компонентов".

В статье мало технических деталей. В ней в основном рассказывается про организацию процесса миграции. Переводу проектов очень помогло выравнивание знаний о TypeScript в команде. Для этого все компоненты были распределены по разным уровням сложности миграции. Также использовали базу знаний команды с соглашениями по использованию типизированного кода. Регулярно оценивали прогресс миграции, что увеличило прозрачность всего процесса как для команды, так и для руководства.

Использованные инструменты и утилиты. Для предварительной оценки кодовой базы и мониторинга прогресса использовали cloc. С помощью утилиты madge был построен граф зависимостей проектов, чтобы определить порядок миграции модулей. Использовали кодмоды для перевода JS-компонентов на TS.

В итоге за три месяца работы было мигрировано 630 React-компонентов.

Рекомендую почитать статью, если планируете мигрировать большой проект на TS (или любую другую технологию).

#migartion #typescript

https://habr.com/ru/company/badoo/blog/518246/

Юля Бухвалова написала статью о доступности с большим количеством примеров самых распространённых проблем — "Недоступность в картинках".

В самом начале статьи есть небольшой ликбез (must read) по использованию скринридеров в Windows (Narrator) и macOS (Voice Over). Все скринридеры помогают пользователям перемещаться по сайту, предоставляя списки для заголовков, ссылок, изображений и ориентиров (теги main, header, footer, nav и т.п.)

Пара советов из статьи. Для упрощения работы с формами следует использовать теги fieldset и legend. Не следует верстать на дивах интерактивные элементы, лучше всего использовать вместо них соответствующие элементы из стандарта ( button, input и т.д.) Для изображений img всегда нужно добавлять атрибут alt. Если изображение декоративное, его следует поместить в CSS или использовать пустую строку в описании alt.

Очень полезная статья. Рекомендую почитать всем, кто занимается разработкой сайтов.

#a11y #html

http://css.yoksel.ru/inaccessibility/

В блоге DebugBear недавно была опубликована ещё одна статья про производительность — "Front-end JavaScript performance".

В этот раз статья была посвящена обзору распространённых проблем производительности JavaScript в браузере. Разбираются  Layout Thrashing, паттерн Module/NoModule и т.п. Написано немного про то, как искать источники проблем и как их исправлять. В статье есть упоминание оптимизации про кеширование свойства length массивов, когда оно используется в циклах. Насколько я помню, она уже неактуальна для современных браузеров. Пишите в наш чатик @defrontchat, если я ошибаюсь.

Мне статья показалась поверхностной, но её можно рекомендовать, как вводную статью по теме производительности JS.

#js #performance

https://www.debugbear.com/blog/front-end-javascript-performance

Во вчерашнем посте было упоминание про Layout Thrashing — избыточный перерасчёт положения и геометрии элементов на странице (reflow), ведущий к сильному проседанию fps страницы. Год назад Карис Теудулу написал статью про подходы решения этой проблемы — "Web Performance: Minimising DOM Reflow / Layout Shift".

DOM reflow происходит во многих ситуациях: вставка/удаление элементов в DOM, модификация контента, сдвиг элементов, измерение элементов (например, с помощью offsetHeight, getBoundingClientRect ), динамичное изменение CSS и т.д. Основная рекомендация — по мере возможности уменьшать количество таких событий. Это можно сделать с помощью батчинга DOM-операций, редактирования элементов на более нижних уровнях дерева, использования flexbox вместо float для раскладки элементов на странице и т.п.

Хорошая статья. Рекомендую почитать всем, кому интересна тема оптимизации рендеринга в браузере.

#performance

https://medium.com/better-programming/web-performance-dom-reflow-76ac7c4d2d4f

Тим Ван Дер Лип из команды разработки Chrome написал статью о миграции кодовой базы девтулзов на ECMAScript Modules — "DevTools architecture refresh: Migrating to JavaScript modules".

Chrome DevTools — это большое приложение, написанное на стандартных web-технологиях: HTML, CSS, JS. Оно было спроектировано более 10 лет назад до массового распространения модульных систем. Для организации модульности до 2020 года в Dev Tools использовался паттерн Externally Defined Dependencies. В этом паттерне весь граф зависимостей описывается в независимом файле или файлах. Специальная утилита (в случае Dev Tools, написанная на python) считывает этот файл и собирает из большого количества js-файлов один бандл.

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

Чтобы избавиться от этих проблем, ребята решили перенести всю кодовую базу на ESM. Начальная оценка была 2-4 недели, но весь процесс миграции занял 7 месяцев, так как по ходу дела возникло много проблем, например, с интеграцией со старой системой и с тестами, которые работали в sloppy режиме (то есть без "use strict"; ). Миграция включала в себя два этапа: в первом были добавлены новые export'ы, во втором — import'ы с удалением устаревшего кода.

Очень интересная статья. Советую почитать, если хотите узнать больше технических подробностей.

#esm #migration

https://developers.google.com/web/updates/2020/09/migrating-to-js-modules

Прошло уже две недели с момента последней публикации про канал для патронов. За это время в Defront Plus было опубликовано много интересных постов:

— Фаззинг JS-движков
— Пять правил программирования Роба Пайка
— Влияние спекулятивного парсера на производительность загрузки страницы
— Почему ссылки нужно выделять подчёркиванием
— История появления промисов
— Хэширование паролей и корректная терминология
— Обзор альтернатив Google Analytics, ориентированных на приватность
— Quick Focus Highlight и псевдокласс focus-visible в Chrome 86
— Мысли про упрощение Web'а
— RFC8890 "Интернет для пользователей"

Чтобы получить доступ ко всем постам в Defront Plus, поддержите канал на Patreon. Благодаря вашей поддержке канал развивается и становится лучше. Спасибо!

https://www.patreon.com/myshov

Команда разработчиков Moment.js официально объявила о прекращении развития библиотеки.

Moment.js — самая популярная библиотека для работы с датами и временем на сегодняшний день. Она была создана в 2011 году с прицелом на потребности разработчиков того времени. За весь период существования библиотеки её дизайн не менялся, но сообщество хотело изменений, особенно иммутабельности и переработки архитектуры таким образом, чтобы библиотека стала дружить с тришейкингом. Внесение этих изменений вызвало бы вопросы у текущих пользователей библиотеки, так как получилась бы совершенно другая библиотека. Разработчики Moment.js не захотели идти по пути Angular и разработали альтернативную библиотеку — Luxon.

С сентября 2020 года в Moment.js не будут добавляться новые фичи, не будут больше обсуждаться вопросы тришейкинга, не будет никаких мажорных изменений (это означает, что никогда не будет 3-ей версии), возможно, не будут исправляться какие-либо баги и поведенческие странности, если они будут связаны с архитектурными проблемами. Но будут исправляться все проблемы безопасности, будет обновляться база часовых поясов IANA.

Разработчики рекомендуют не использовать Moment.js для новых проектов без поддержки старых браузеров, вместо неё рекомендуются Luxon, Date.js, date-fns и js-Jode. Также сейчас TC39 работает над Temporal (современной заменой объекта Date), в которой реализуется основная масса фич библиотек для работы с временем.

#announcement #date #library

https://momentjs.com/docs/#/-project-status/

Джереми Вагнер поделился своими мыслями по поводу новой фичи Lighthouse, которая анализирует JS-бандлы на предмет наличия тяжеловесных библиотек и предлагает вместо них легковесные альтернативы — "Canned Web Development".

Это хорошая фича, но по мнению Джереми у неё есть две проблемы. Добавление этой фичи неизбежно создаст большую нагрузку на майнтейнеров библиотек, которые в большинстве случаев занимаются поддержкой в своё свободное время. Вторая проблема заключается в том, что наша ментальная модель того как мы создаём приложения очень сильно полагается на закостенелые решения, и lighthouse не помогает разрешению этой проблемы. Например, после анализа lighthouse рекомендует использовать вместо Moment.js библиотеки luxon, date-fns и Day.js. Но, действительно ли это самое оптимальное решение для анализируемого проекта? Вполне возможно, что будет достаточно обычного объекта Date или вообще можно обойтись без JS, работая с датами только на стороне сервера.

В общем, статья заставляет немного задуматься о текущем положении дел. Рекомендую почитать.

#musings #performance

https://jeremy.codes/blog/canned-web-development/

Максимилиано Фиртман написал статью про новинки в iOS 14 и iPadOS 14, которые будут интересны web-разработчикам — "Safari on iOS 14 and iPadOS 14 for PWA and Web Developers".

Apple теперь позволяет устанавливать браузер по умолчанию для всей системы. Для этого браузеры должны пройти специальную  проверку. На данный момент браузером по умолчанию можно сделать Safari, Edge и Chrome.

Появилась поддержка сервис воркеров в сторонних браузерах. Также их поддержка появилась в приложениях, использующих WebView, благодаря новой фиче App-Bound Domains.

В новой версии операционной системы PWA используют зарегистрированные сервис воркеры и CacheStorage из Safari. Cookie, Web Storage и IndexedDB остались изолированы от Safari. Некоторые PWA (например, twitter) не были готовы к этому изменению и работают с ошибками.

Была добавлена экспериментальная поддержка HTTP/3, которую можно включить в настройках. В JavaScriptCore добавлена поддержка BigInt, EventTarget, Logical assignment operator и Public class fields. Web Authentication API поддерживает TouchID и FaceID. Добавлена поддержка формата изображений WebP.

Статья очень большая. В первую очередь рекомендую почитать тем, кто разрабатывает PWA.

#apple #safari #pwa

https://firt.dev/ios-14/

Эван Ю буквально пару часов назад на митапе Vue.js Amsterdam выступил с докладом "The Journey to Vue 3", где анонсировал официальный релиз Vue.js 3.

В начале доклада Эван рассказал про историю третьей версии, её разработка заняла два года. Первая идея о разработке Vue 3 появилась в феврале 2018 года. Затем в сентябре был представлен первый прототип. Потом последовал этап исследований. Были эксперименты с поддержкой классов, TypeScript, функциональных компонентов и time slicing. Какие-то идеи попали в релиз, например, функциональные компоненты в виде Composition API, от некоторых фич отказались, например, Class API.

Весь фреймворк был разбит на модули. Любую часть фреймворка при желании можно использовать в любом другом фреймоврке. Кодовая база была написана полностью на TypeScript. Появилась долгожданная поддержка TS в шаблонах. Система реактивности в третьей версии работает на базе Proxy, улучшая производительность. Реализована новая система рендеринга, использующая компиляцию шаблонов в оптимизированные функции рендеринга Virtual DOM. При необходимости система рендеринга откатывается в diff mode. Был ускорен Server Side Rendering. Фреймворк разрабатывался с учётом поддержки три-шейкинга. Добавлено новое Composition API для улучшения переиспользования и организации кода компонентов. На данный момент в процессе разработки инструменты для миграции со второй версии и поддержка IE11, работу над ними планируется закончить в четвёртом квартале 2020 года.

Также в докладе было обновление про статус второй версии. В первом квартале 2021 вторая версия получит последнее минорное обновление до версии 2.7. В неё попадут фичи из Vue 3, которые возможно портировать. Будут добавлены предупреждения для упрощения миграции на третью версию. Версия 2.7 будет последней минорной версией предыдущего мажорного релиза. Её поддержка закончится через 18 месяцев после даты релиза.

#vue #jsframeworks #release #talk

https://www.youtube.com/watch?v=Vp5ANvd88x0