Джон Дэвис в блоге WebKit рассказал о новых возможностях Safari 14.1, который зарелизился пару дней назад, — "New WebKit Features in Safari 14.1".

В CSS добавлена поддержка гэпов для флексбоксов. Добавлены индивидуальные свойства трансформации элементов: scale, rotate, translate. Также Safai для macOS теперь поддерживает поля для ввода даты и времени.

В JavaScript появилась поддержка приватных полей и публичных статических полей класса. В Internationalization API добавлены новые методы: Intl.DisplayNames, Intl.ListFormat, Intl.Segmenter. В методе Intl.DateTimeFormat добавлена поддержка опций dateStyle и timeStyle. Имплементирован пропозал WeakRef.

Добавлена реализация Paint Timing API. На данный момент он предоставляет информацию по двум метрикам: first-paint и first-contentful-paint. Web Speech API начал предоставлять средства для распознавания речи. Решены некоторые проблемы совместимости в Web Audio API, добавлены Audio Worklets. Добавлена реализация MediaRecorder API для записи аудио и видео. Появилась поддержка WebM (открытый формат для хранения видео). Улучшена приватность Storage Access API. Добавлен механизм для приватного отслеживания кликов — Private Click Measurement (PCM).

WebAssembly теперь умеет работать с потоками, добавлена интеграция с JavaScript BigInt, добавлен новый sign-extension operator (эта фича реализована автором телеграм-канала @webnya).

В инструментах разработчика изменена раскладка инспектора элементов, была добавлена панель с информацией обо всех шрифтах страницы, в отладчике добавлена поддержка logpoints.

#release #safari

https://webkit.org/blog/11648/new-webkit-features-in-safari-14-1/

Джейк Арчибальд взял небольшую паузу в анализе производительности сайтов команд Формулы-1 и попробовал найти причину медленной загрузки сайта Google I/O — "Performance-testing the Google I/O site".

На слабом устройстве сайт Google I/O загружается за 26 секунд. Основная проблема заключается в том, что это SPA-приложение — для отображения описания докладов, времени и аватарок нужно загрузить около 5Мб JS и JSON. Сайт не использует код-сплиттинг, поэтому в бандл попадает много второстепенного кода. Есть проблемы с загрузкой кода для авторизации — он загружается со стороннего сервера, затрачивая секунду на установку соединения. Также для отображения одной иконки меню загружается относительно тяжёлый иконочный шрифт.

Сайт Google I/O работает почти также медленно как сайт МакЛарен, уступая последнее место сайту Ферарри.

#performance

https://jakearchibald.com/2021/io-site-perf/

Джо Сэпл, Майкл Доусон и Бэттани Григгс из команды разработки Node.js рассказали о том, что нам стоит ожидать от Node.js в будущем — "What's Next, The Future of Node.js".

В Node.js 14 была добавлена экспериментальная поддержка AsyncLocalStorage API, который упрощает обмен данными между асинхронными вызовами. Скоро будут стабилизированы основные части этого API (уже есть готовый пулл реквест).

В Node.js 16 появилась стабильная поддержка Source Maps v3. На данный момент можно включить поддержку сорсмапов для стектрейсов, но работа по их внедрению ещё не закончена.

В рамках добавления поддержки ECMAScript Modules идёт работа над Loader API, с помощью которого можно писать свои лоадреы для трансформации импортируемого кода (например, можно написать лоадер, который будет автоматически транспилировать TypeScript-файлы при их импорте). Также идёт работа над добавлением JSON Modules, WASM Modules и top-level await. Некоторые API уже доступны за экспериментальным флагом.

Планируется добавление Fetch API. Fetch требует много работы, но есть вероятность, что он попадёт в Node.js в конце этого года.

Также команда разработки сейчас проводит опрос, который поможет спланировать развитие Node.js на ближайшие десять лет.

#nodejs #talk

https://www.youtube.com/watch?v=vrnToZP47Ro
https://nodejs.medium.com/next-10-years-of-node-js-understanding-the-needs-of-the-node-js-constituencies-2f95a1df6a6f

Недавно была опубликована статья, в которой рассказывается про работу с базой данных на статических сайтах — "Hosting SQLite databases on Github Pages".

Когда нужно организовать доступ к большому массиву данных (в режиме read only), а поднимать полноценный бекенд не хочется, можно воспользоваться решением из статьи. Автор реализовал виртуальную файловую систему для sql.js — WebAssembly-версии SQLite. Движок SQLite думает, что работает с обычным файлом, но все запросы на чтение транслируются в HTTP Range запросы к файлу базы данных на сервере. Для хостинга базы можно использовать GitHub Pages, Netlify и т.п.

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

#webassembly #staticsite

https://phiresky.github.io/blog/2021/hosting-sqlite-databases-on-github-pages/

В блоге CSSSR была опубликована вторая часть статьи про историю фронтенда — "История фронтенда: JavaScript как отражение новой эпохи".

Во второй части рассказывается про историю появления и развития веб-стандартов. HTML и JavaScript пережили похожий процесс: сначала была жёсткая конкуренция браузеров с хаотичным внедрением фич, затем предпринималась попытка стандартизации, которая была отвергнута сообществом (XHTML) или стала неудачной из-за слишком больших амбиций (ECMAScript 4), потом был застой, а затем продуктивная работа вместе с сообществом. HTML и JavaScript стали живыми стандартами, которые обновляются каждый год и поддерживаются всеми браузерами.

Рекомендую почитать статью, если интересуетесь историей развития веба. Ещё есть видеоверсия, но статья интереснее (имхо).

#history #web

https://blog.csssr.com/ru/article/frontend-history-java-script-as-a-reflection-of-a-new-era/
https://www.youtube.com/watch?v=sgyoKkAfGpU (видео)

За прошедшие две недели в канале для патронов Defront было опубликовано десять постов:

— Сравнение производительности JavaScript и WebAssembly
— Великий SameSite конфуз
— Эффективная разработка с помощью декомпозиции задач
— Прохождение алгоритмического интервью на позицию старшего разработчика
— Современный мобильный веб и его тестирование
— Третья эпоха JavaScript
— Миграция фронтенда Sentry на TypeScript
— Лучшие практики разработки куки-баннеров
— Сравнение CSS и CSS-in-JS
— Культ лучших практик

Становитесь патроном канала на Patreon, чтобы получить доступ к дополнительным постам в Defront Plus. Все донаты идут на поддержку канала, покупку еды, оплату аренды квартиры и т.п.

Спасибо всем, кто читает и поддерживает Defront!

https://www.patreon.com/myshov

Кристьян Оддссон рассказал об опыте использования веб-компонентов в GitHub — "How we use Web Components at GitHub".

В 2018 году GitHub завершил модернизацию фронтенд-кода, который был очень сильно завязан на jQuery. С того момента ребята разработали Ruby-фреймворк ViewComponent для создания независимых компонентов-вьюх и библиотеку Catalyst для упрощения разработки веб-компонентов, которая была вдохновлена Stimulus и LitElement.

Веб-компоненты в GitHub используются для серверной валидации форм, создания динамических фильтров, элементов ввода с автодополнением, для элемента копирования текста в буфер обмена, модальных окон и т.п. При открытии их исходного кода разработчики удаляют все зависимости (то есть заменяют код стандартными веб-компонентами), чтобы их компонентами можно было воспользоваться в любом проекте.

#webcomponents

https://github.blog/2021-05-04-how-we-use-web-components-at-github/
https://github.com/github/github-elements (репозиторий компонентов)

P.S. Благодарю Олега Ковалёва (@oleg_log) за наводку на статью.

V8 релиз v9.1

- Включили private brand checks по умолчанию (было за флагом), что позволяет использовать оператор in с приватными полями, то есть #foo in obj
- Включили top-level await по умолчанию (было за флагом). Стоит отметить что фича уже включена в Chrome 89 по умолчанию, видимо на подходе Node.js
- Пара специфичных оптимизаций

Буквально за день до выхода статьи про веб-компоненты от GitHub Тайлер Уильямс рассказал об опыте использования веб-компонентов в GitLab — "Using web components to encapsulate CSS and resolve design system conflicts".

В GitLab веб-компоненты используются для инкрементального внедрения новой дизайн системы с изоляцией стилей. Для этого был создан специальный кастомный элемент slp-blog, в котором отображается статически сгенерированный HTML статьи с новым набором стилей. Если по какой-то причине загрузка JS-кода, отвечающего за инициализацию элемента, отваливается, то пользователь всё равно сможет прочитать статью, но без стилизации.

В общем, статья интересная. Почитайте, если хотите познакомиться с ещё одним сценарием использования веб-компонентов.

#webcomponents #css

https://about.gitlab.com/blog/2021/05/03/using-web-components-to-encapsulate-css-and-resolve-design-system-conflicts/

Вчера вышла новая версия Bootstrap. Марк Отто рассказал о всех изменениях в релизе — "Bootstrap 5".

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

Упрощена работа с раскладкой элементов. Были удалены классы .form-group, .form-row и .form-inline.

Добавлены новые утилитарные классы : .d-grid, .fs, .fw, .overflow-visible, .overflow-scroll, .top-0, .top-50, .top-100 и другие. Появилось API для создания кастомных утилитарных классов.

Добавлена экспериментальная поддержка RTL (Right-to-Left).

#release #css

https://blog.getbootstrap.com/2021/05/05/bootstrap-5/

Кристоф Наказава из Facebook поделился большим количеством советов, которые помогли уменьшить размер зависимостей React Native на порядок — "Dependency Managers Don’t Manage Your Dependencies".

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

В статье рассказывается о том, как быстро найти тяжёлые пакеты, как выстроить процесс добавления новых пакетов в проект с отслеживанием их размера, как избежать проблем с устареванием зависимостей и т.п. Также в статье рассказывается про утилиты, которые полезно использовать при работе с зависимостями. Например, для поиска и удаления дубликатов можно использовать yarn-deduplicate, для поиска неиспользуемых зависимостей — depcheck.

#yarn #package

https://cpojer.net/posts/dependency-managers-dont-manage-your-dependencies

Крис Хагер написал руководство по настройке TypeScript-проекта — "Starting a TypeScript Project in 2021".

Руководство рассказывает про настройку сборки (используя esbuild), линтинга (eslint), тестов (jest), адаптацию Node.js для бесшовной работы с TypeScript (ts-node). Немного затрагивается тема настройки CI (GitHub Actions/GitLab CI) и генерации документации (TypeDoc).

В руководстве предлагается использовать esbuild, и это очень хороший совет. Однако стоит учитывать, что на данный момент поддержка код-сплиттинга в esbuild находится в экспериментальном статусе, поэтому для больших проектов (по крайней мере пока) лучше брать Webpack или Rollup.

#typescript

https://www.metachris.com/2021/04/starting-a-typescript-project-in-2021/

Варун Вачнар пообщался с разработчиками из Adobe, BBC, Twilio, Shopify, Peloton и обобщил подходы, которые они используют при тестировании UI — "How to actually test UIs".

В статье рассказывается о подходах тестирования интерфейсов, создаваемых с помощью компонентного подхода. Для обособленного тестирования компонентов команды используют Storybook, для тестирования поведения компонентов — Testing Library, для тестирования доступности — Axe, для E2E-тестов — Playwright и Cypress.

Есть раздел про визуальное тестирование (тестирование скриншотами), но там нет упоминания инструментов с открытым исходным кодом, например, Hermione, Gemini, cypress-image-snapshot.

Как бы то ни было, статья хорошая. Очень рекомендую почитать.

#testing #tool

https://storybook.js.org/blog/how-to-actually-test-uis/

Неделю назад Себастьян Маккензи — автор Babel и Yarn — написал пост про то, что его проект Rome привлёк инвестиции.

Rome — это тулчейн с открытым исходным кодом, цель которого — консолидация разных инструментов для работы с JavaScript (пакетный менеджер, линтер, тест-раннер, сборщик и т.п.) В отличие от других инструментов Rome использует единое ядро для всех задач, ускоряя работу всего фронтенд-пайплайна.

Привлечённые инвестиции (4.5 миллиона долларов) пойдут на найм фулл-тайм разработчиков. Себастьян пишет о том, что не планирует закрывать какие-то части Rome, инструмент будет доступен без ограничений. Зарабатывать планируют на вспомогательных сервисах.

В общем, проект полетел. Очень интересно, как он повлияет на JavaScript-экосистему в будущем.

#announcement #tool

https://rome.tools/blog/announcing-rome-tools-inc/

Ахмад Шадид написал статью про прошлое и настоящее кроссбраузерной CSS-разработки — "The State of CSS Cross-Browser Development".

Раньше разработчики сталкивались с большим количеством кроссбраузерных проблем. Ситуация стала гораздо лучше после появления гридов, флексбоксов и ухода на пенсию IE. Тем не менее ещё остаются нерешённые кроссбраузерные проблемы. Например, Safari растягивает изображения внутри флекс-контейнеров, position: sticky для заголовков таблиц работает неконсистентно, анимация гридов есть только в Firefox и т.п.

Хорошая новость заключается в том, что в рамках инициативы Compat2021 Google, Microsoft, Igalia и Mozilla начали работу над улучшением поддержки CSS-стандартов, которые наиболее критичны для разработчиков.

#css #history

https://ishadeed.com/article/cross-browser-development/

Карло Пиовесан — разработчик Cheerp — попробовал выяснить, можно ли в автоматическом режиме преобразовать JavaScript-код в эквивалентный более производительный JavaScript-код и поделился результатами своего исследования в статье "A JavaScript optimizing compiler".

Карло написал очень ограниченный транспилятор из JavaScript в C++. Прогнал через него код бенчмарков. Затем получившийся C++-код скомпилировал обратно в JavaScript-код с помощью Cheerp с применением оптимизаций на уровне компилятора (Cheerp — это компилятор, построенный на базе LLVM, аналог Emscripten).

В результате такого преобразования кода, большинство бенчмарков показали прирост производительности. Особенно хорошо показал себя код для проверки простых чисел — он стал быстрее на 80%.

Этот подход нельзя использовать в продакшене, так как транспилятор из JavaScript в C++ очень хрупкий и покрывает только небольшое подмножество JavaScript. Тем не менее проведённый эксперимент говорит о том, что у этой стратегии оптимизации есть право на жизнь.

#experimental #js #performance

https://medium.com/leaningtech/a-javascript-optimizing-compiler-3fd3f49bd071

Александр Косс рассказал про историю появления и развития библиотеки date-fns.

Разработка библиотеки началась осенью 2014 года. На тот момент date-fns не претендовал на замену Moment.js и включал в себя одну функцию startOfDay (у аналогичной функции в Moment.js были проблемы с производительностью). У проекта не было какой-либо стратегии развития, дополнительные функции добавлялись по мере необходимости.

В 2015 году Александр нанял своего брата, чтобы он сделал порт функций из Moment.js. С этого момента проект начал набирать небольшую популярность. В 2016 году Дэн Абрамов попиарил date-fns у себя в твиттере. После этого события пришло очень много новых пользователей, вскрылись проблемы, которые можно было решить только изменением API. Большой поток запросов, багов и сопутствующей работы привёл к тому, что Александр перегорел. Но в 2019 году смог выделить три месяца на фулл-тайм разработку date-fns, и в августе 2019 года вышла вторая версия с переделанным API, из-за чего многие пользователи остались недовольны.

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

В общем, крутая история. Передаю разработчикам свой респект.

#opensource #history #date

https://twitter.com/kossnocorp/status/1392449481053032450

Вчера в блоге Google появилась новость о том, что Google Docs переходит на движок рендеринга, работающий поверх canvas, — "Google Docs will now use canvas based rendering: this may impact some Chrome extensions".

После публикации в сети появились обсуждения насколько это оправдано. Своими мыслями поделился один из авторов оригинального Google Docs. Он говорит о том, что HTML-движки хороши для рендеринга обычных сайтов, но им не хватает фич для реализации полноценных WISWYG-редакторов. И о том, что кастомный движок рендеринга выигрывает по скорости у HTML-движков благодаря ограниченному набору функций.

У многих возникли вопросы по поводу доступности. Я немного потестил тестовый документ из статьи, и с доступностью там более менее всё ок. Озвучивание текста включается с помощью хоткея cmd+option+z — появится div с aria-live вне области просмотра с текстом документа текущей страницы. При перемещении по документу озвучивается текущая строка.

Обновление Google Docs будет раскатываться постепенно в течение двух ближайших месяцев. После обновления браузерные расширения, работающие с HTML-разметкой приложения, перестанут работать.

#architecture #announcement #google #a11y

https://workspaceupdates.googleblog.com/2021/05/Google-Docs-Canvas-Based-Rendering-Update.html
https://news.ycombinator.com/item?id=27129858 (обсуждение на Hacker News)

Эдди Османи написал статью про использование Puppeteer для анализа производительности сайта — "Web Performance Recipes With Puppeteer".

Puppeteer — это библиотека для автоматизированного управления браузерами (Chrome, Edge, Opera, Firefox). Её используют для пререндеринга страниц SPA-приложений, для тестирования, генерации скриншотов страницы и т.п.

В статье Эдди делится Puppeteer-скриптами, которые могут быть полезны для решения проблем производительности. Например, для оценки влияния стороннего кода, для получения метрик производительности (FCP, LCP, CLS), для поиска утечек памяти, для измерения FPS страницы и многого другого.

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

#performance

https://addyosmani.com/blog/puppeteer-recipes/

Сара Суайдан рассказала об оптимизации содержимого страницы для режима чтения — "Design for reading: tips for optimizing content for Reader modes and reading apps".

Стили страницы могут быть доступны не для всех пользователей, например они недоступны для пользователей RSS-ридеров или при использовании режима чтения в браузере. Поэтому очень не рекомендуется размещать контент на уровне стилей. Если с помощью разметки нельзя выразить текущее визуальное представление (например, сложную анимацию), то нужно добавить её описание. Иногда, наоборот, нужно скрыть какую-либо часть контента в режиме для чтения. В этом случае может помочь глобальный атрибут hidden.

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

#html #css

https://www.sarasoueidan.com/blog/tips-for-reader-modes/