Джо Сэпл, Майкл Доусон и Бэттани Григгс из команды разработки 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-noscript-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.

#typenoscript

https://www.metachris.com/2021/04/starting-a-typenoscript-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, аналог Emnoscripten).

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

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

#experimental #js #performance

https://medium.com/leaningtech/a-javanoscript-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/

Брайан Карделл из Igalia поделился планами по прототипированию поддержки CSS-селектора :has() — "Can I :has()".

Cелектор :has() добавляет в CSS возможность стилизации элемента на основе его содержимого. Это единственный селектор в таком роде — другие селекторы работают по направлению от детей к родителям. Он появился в черновике спецификации Selectors Level 4 в 2011 году, но до сих пор не был имплементирован в браузерах. Основная сложность заключается в том, что :has() ломает принципы работы со стилями, которые лежат в основе многих оптимизаций, благодаря которым браузеры могут поддерживать стабильные 60 fps.

На протяжении десяти лет в рабочей группе CSS возникали обсуждения по поводу :has(), но они никуда не вели, потому что никто не брался за прототипирование. Недавно компанию Igalia наняла компания eyeo (разрабатывает Adblock Browser и Adblock Plus) для того, чтобы сдвинуть эту фичу с мёртвой точки. Ребята планируют сделать прототипы и в принципе понять, возможно ли реализовать :has() без проблем для производительности. Этот эксперимент определит дальнейшую судьбу селектора. Либо он будет добавлен в браузеры, либо его функциональность будет реализована в другом виде, например, на уровне DOM API.

#css #experimental

https://bkardell.com/blog/canihas.html

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

— Приоритизация загрузки ресурсов HTML-страницы
— Островная архитектура (Islands Architecture)
— Неизвестный HTML
— Zx — утилита для упрощения работы с shell-скриптами
— Разработка компонента для просмотра введённого пароля
— Недостатки снапшот-тестов
— Opossum — реализация паттерна circuit breaker в Node.js
— Разочарование в JPEG XL
— Как убедить других разработчиков в правоте своей идеи
— Преимущества и недостатки сабсеттинга шрифтов

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

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

https://www.patreon.com/myshov

Дэн Вандеркам рассказал о ситуациях, в которых система типов TypeScript проявляет свою ненадёжность (unsoudness) — "The Seven Sources of Unsoundness in TypeScript".

Надёжная система типов гарантирует соответствие статических типов в коде программы фактическим типам на этапе её выполнения. В TypeScript система типов ненадёжна. Более того разработчики языка осознанно не преследуют цель создания надёжной системы типов, потому что это противоречит более важной цели — максимально поддержать паттерны и подходы, используемые в JavaScript. Поэтому при использовании TypeScript нужно учитывать потенциальные проблемы, чтобы код не взорвался в продакшене.

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

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

#typenoscript

https://effectivetypenoscript.com/2021/05/06/unsoundness/