Вчера вышел Node.js v15.0.0.

TLDR

В релизе был обновлён движок V8 до версии 8.6, npm был обновлён до седьмой версии, обновлена версия N-API, была добавлена поддержка AbortController и QUIC, необработанные ошибки промисов теперь приводят к прекращению работы Node.js.

Подробнее

V8 был обновлён до версии 8.6. С новой версией движка в Node.js появилась поддержка Promise.any(), AggregateError, логических операторов присваивания &&=, ||=, ??=, String.prototype.replaceAll().

Npm был обновлён до версии 7. В нём появилась поддержка воркспейсов, изменён формат package-lock.json, добавлена поддержка yarn.lock, установка peerDependencies по умолчанию. Недавно в канале был подробный пост про новую версию npm, его можно почитать тут.

Была добавлена экспериментальная поддержка нового транспортного протокола QUIC, который лежит в основе HTTP/3. Основные фичи QUIC: по умолчанию безопасен (используется TLS 1.3), исправление проблемы head-of-line blocking, поддержка миграции соединения. Более подробно про QUIC и HTTP/3 можно почитать тут.

В Node.js 15 необработанные ошибки промисов будут выкидывать исключение и приводить к остановке работы Node.js, если не была установлена глобальная обработка unhandledRejection. Такое решение было принято, чтобы показать важность обработки ошибок промисов, без них могут возникать утечки памяти и другие проблемы. Это поведение можно поменять с помощью флага --unhandled-rejections=warn.

Была добавлена экспериментальная поддержка AbortController — Web API, с помощью которого можно отменять работу API на базе промисов.

N-API — API для создания аддонов — было обновлено до седьмой версии. В нём были добавлены дополнительные методы для работы с ArrayBuffers.

Нечётное число в версии Node.js означает, что это экспериментальная версия, она будет поддерживаться до июня 2021 года. Самая последняя стабильная версия Node.js 14 на следующей неделе получит статус LTS.

#nodejs #release

https://medium.com/@nodejs/node-js-v15-0-0-is-here-deb00750f278

Лукас Ф. Коста — автор библиотеки Chai.js — написал статью про package-lock.json — "Why does package-lock.json exist, and how does it work?".

При повторной установке пакетов с зафиксированными версиями результирующий node_modules может отличаться, так как могут быть обновлены зависимости зависимостей. Чтобы добиться детерминированной установки в npm используется файл package-lock.json, в котором явно описываются все версии всех зависимостей.

При запуске команды npm i установщик получает список зависимостей проекта из package.json и во время их установки обновляет package-lock.json, записывая туда полное дерево зависимостей с необходимой метаинформацей. Для установки пакетов из package-lock.json нужно использовать другую команду — npm ci. Эта команда устанавливает все зависимости, создавая идентичное дерево зависимостей на момент последнего выполнения npm i. Кроме детерминированности npm ci даёт очень хороший буст в скорости установки пакетов, поэтому чаще всего её используют в CI-системах.

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

#npm

https://lucasfcosta.com/2020/10/17/lockfile-guide.html

Не знаю как у вас, но меня постоянно вводили в ступор хинты производительности <link rel="prefetch"> и <link rel="preload">. Когда пытался вспомнить их назначение, в голове возникали примерно такие вопросы: "Prefetch отвечает за оптимизацию загрузки ресурсов для текущей страницы или следующих страниц? А за что тогда отвечает preload?"

Prefetch и preload похожи друг на друга: prefetch отвечает за оптимизацию загрузки ресурсов на страницах, которые будут открыты через некоторое время, preload — за оптимизацию загрузки ресурсов, которые нужны прямо сейчас на текущей странице.

Сегодня придумал мнемоническое правило, помогающее запомнить, что за что отвечает: preLoad помогает оптимизировать загрузку ресурсов на локальной (Local) странице (то есть текущей), preFetch помогает оптимизировать загрузку ресурсов на будущих (Future) страницах.

Preload — local, prefetch — future.

#performance #trick

https://twitter.com/myshov/status/1319652179263868928

Эдди Османи написал статью про использование паттерна PRPL — "Faster Web App Delivery with PRPL".

PRPL — это паттерн для структурирования и улучшения производительности web-приложений (SPA и PWA).

PRPL описывает четыре этапа жизненного цикла приложения от этапа доставки кода в браузер до его отрисовки:
— Push — при первом открытии приложения, самые необходимые ресурсы доставляются как можно быстрее с помощью server push или preload;
— Render — затем отрисовывается экран приложения с использованием минимального количества необходимых ему ресурсов;
— Pre-cache — после того как приложение было отрисовано, оно может подгрузить ресурсы тех страниц приложения, которые с большой вероятностью будут открыты пользователем;
— Lazy-load — при работе с приложением его куски доставляются в браузер по мере необходимости, это обычно реализуется с помощью code splitting и динамических импортов.

Хорошая статья. Обязательно загляните, если занимаетесь разработкой web-приложений.

#performance #mobile #js

https://addyosmani.com/blog/the-prpl-pattern/

Артём Караваев на хабре написал статью о том, как складывать числа с плавающей запятой без потери точности.

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

Математически можно доказать, что ошибку округления сложения чисел с плавающей запятой всегда можно точно представить другим числом с плавающей запятой. То есть чтобы сложить два числа с плавающей запятой без потери точности, нужно вычислить погрешность и использовать её в других вычислениях. Найти эти числа можно так (в статье есть более точные алгоритмы поиска для разных входных значений):

s = a+b; // сумма
z = s-a;
t = b-z; // погрешность

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

#math #algorithm

https://habr.com/ru/post/523654/

Рич Харрис на Svelte Summit 2020 рассказал про новые фичи фреймворка, над которыми работает основная команда разработчиков Svelte — "Futuristic Web Development".

Идёт работа над интеграцией возможностей Sapper (фреймворк для построения приложений на базе Svelte с роутингом, код-сплиттингом и т.п.) в основную кодовую базу Svelte. В перспективе разработка Sapper будет остановлена.

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

Svelte будет полагаться на поддержку ESM в современных браузерах, так как для менеджмента зависимостей будет использоваться Snowpack. Благодаря этому не нужно постоянно собирать приложение при изменении кода. Rollup будет использоваться только для сборки финального оптимизированного бандла приложения.

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

#svelte #jsframeworks #talk #experimental

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

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

— Почему важно использовать правильный атрибут lang
— Сеть доверия в npm
— Rust и Web — столкновение парадигм
— Инструменты JS-экосистемы, написанные на компилируемых языках
— Влияние CSS на производительность сайтов
— Использование CSS-функций min(), max() и clamp()
— Early Hints — ускорение доставки ресурсов сайтов
— Как запомнить разницу между justify-content и align-items
— Потерянная аудитория сайтов
— Перенос Redux в web-воркер

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

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

https://www.patreon.com/myshov

Теренс Эден — разработчик web-стандартов — призывает отказаться от использования специализированных CDN для доставки JS-библиотек — "Please stop using CDNs for external Javanoscript libraries".

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

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

Теренс предлагает начать считать антипаттерном подключение кода со сторонних доменов.

#musings #js

https://shkspr.mobi/blog/2020/10/please-stop-using-cdns-for-external-javanoscript-libraries/

Степан Парунашвили объяснил принципы работы Lisp-подобных языков с помощью JavaScript — "An Intuition for Lisp Syntax".

В статье разбирается пример создания системы, которая принимает команды и выполняет их. Сначала используются предопределённые команды, затем добавляется поддержка переменных, потом поддержка создания произвольных функций. В итоге получается игрушечный язык, с помощью которого объясняются основные принципы, на которых построены все Lisp-подобные языки. А именно, почему синтаксис построен на списках, и в чём преимущества подхода "data is code".

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

#programming #js

https://stopa.io/post/265

В Китае очень популярны суперприложения — приложения, с помощью которых можно получить доступ к разным сервисам (заказ такси, бронирование столиков в ресторане и т.п.) Они состоят из нативной оболочки и миниприложений конкретных сервисов, которые создаются с помощью web-технологий. Томас Штайнер из Google разобрался с разными видами миниприложений и подготовил доклад для TPAC 2020 — "Learning From Mini Apps".

Из интересного. Все суперприложения используют разные диалекты HTML и CSS для описания представлений миниприложений — Wxml/WXSS (WeChat), AXML/ACSS (Alipay), Swan Element/CSS (Baidu), TTML/TTSS (ByteDance). Для описания логики используется подмножество JavaScript — WXS (WeChat), SJS (Alipay, ByteDance), Baidu (JS). Для доступа к функциям операционной системы используется специальный мост (bridge). Для связи представления и состояния используется паттерн model-view-viewmodel (MVVM). Все суперприложения предоставляют специальные среды разработки.

Томас предлагает использовать идеи миниприложений для создания многостраничных приложений (multi-page single-page apps — MPSPA) на базе легковесных компонентных фрейморков или custom elements.

#architecture

https://docs.google.com/presentation/d/e/2PACX-1vREwN7H71zfjPP8lwYgyc-iXam7_PMFCxiZy2dQNZ-XpbiKk1aRSj67vxfcegkHogcO0q3BFHxPf6S5/pub

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

Примеры использования:

— "noscript src" — самый распространённый вариант загрузки, используется для загрузки кода стандарта ES5 и ниже
— "noscript src defer" — для отложенного выполнения кода с сохранением порядка выполнения скриптов
— "noscript src async" — для отложенного выполнения кода без сохранения порядка выполнения
— "noscript src async defer" — тоже самое, что и предыдущий вариант, но с поддержкой IE9
— "noscript inline" — для внедрения на страницу небольших сниппетов кода, которые нужно выполнить как можно быстрее
— "noscript src module" — для загрузки кода в современных браузерах
— "noscript src module async" — для загрузки кода для прогрессивного улучшения страницы в современных браузерах
— "noscript inline module" — небольшой сниппет кода, который не нужно кэшировать
— "noscript inline module async" — небольшой сниппет кода для прогрессивного улучшения страницы, который не нужно кэшировать
— "noscript nomodule" — фоллбек для старых браузеров, не поддерживающих модульную систему ECMAScript 2015

#js #esm

https://gist.github.com/jakub-g/385ee6b41085303a53ad92c7c8afd7a6

Пару месяцев назад в твиттере завирусился свежий CSS-синтаксис для задания прозрачности у цвета. Крис Койер написал по этому поводу небольшую статью — "No-Comma Color Functions in CSS".

Ранее у CSS-функций для работы с цветом были две версии: обычная ( rgb, hsl ), и с добавлением альфа-канала ( rgba, hsla ). Чтобы не создавать лишние сущности, авторы спецификации унифицировали синтаксис определения прозрачности при добавлении новых функций lab, lch, color, и теперь можно задать цвет с альфа-каналом без использования специальных функций. В новом синтаксисе компоненты цвета перечисляются через пробел, альфа-канал указывается после символа "/":

/* было */
rgba(0, 128, 255, 0.5)
hsla(198, 28%, 50%, 0.5)

/* стало */
rgb(0 128 255 / 50%)
hsl(198deg 28% 50% / 50%)
lab(56.29% -10.93 16.58 / 50%)
lch(56.29% 19.86 236.62 / 50%)
color(sRGB 0 0.50 1 / 50%)

Поддержка нового синтаксиса есть во всех современных браузерах кроме IE11 (для его поддержки можно использовать PostCSS-плагин).

#css

https://css-tricks.com/no-comma-color-functions-in-css/

Стэфан Гису и Мартин Ширли в блоге web.dev рассказали о том, как собирать аналитику, когда устройство находится в оффлайне — "Measuring offline usage".

Собирать аналитику в оффлайне можно с помощью сервис воркеров. В статье для этого используется библиотека workbox, которая использует сервис воркеры под капотом. В workbox в свою очередь есть расширение, с помощью которого можно собирать оффлайн-аналитику и отправлять её в Google Analytics после перехода устройства в онлайн. Это расширение использует Background Sync API (поддерживается только в Chrome).

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

Рекомендую почитать статью всем, кто думал над тем, чтобы добавить оффлайн-режим в свой проект.

#serviceworker #mobile

https://web.dev/measuring-offline-usage/

Дэниэл Эренберг — участник TC39 — на конференции NodeTLV рассказал про предложение о добавлении в JavaScript нового типа для работы с десятичными числами — "BigDecimal: Avoid rounding errors on decimals in JavaScript".

Не все действительные числа в JavaScript могут быть представлены точно. Это связано с внутренним представлением чисел с плавающей запятой в соответствии со стандартом IEEE 754, который используется в большинстве языков (JavaScript, C, C++, Java и т.п.) Такое представление может приводить к проблемам с операциями над числами, которые должны быть быть представлены точно: деньги, расстояния, размеры и т.п.

В пропозале Decimal описывается новый тип для работы с десятичными числами. Такие числа будут задаваться с помощью суффикса m ( 0.1m + 0.2m === 0.3m ). На данный момент ещё не принято окончательное решение о внутреннем представлении таких чисел. Выбор стоит между BigDecimal и Decimal128.

Предложение находится на первом этапе добавления в стандарт, его поддержки пока нет ни в одном движке.

#js #proposal #talk

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

Инженеры Quip написали две статьи про опыт миграции большого проекта на TypeScript — "The Road to TypeScript at Quip".

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

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

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

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

#typenoscript #migration

https://quip.com/blog/the-road-to-typenoscript-at-quip-part-one
https://quip.com/blog/the-road-to-typenoscript-at-quip-part-two

Марк Эриксон рассказал о том, в каких случаях Redux не самое лучшее решение — "When (and when not) to reach for Redux".

Redux появился в 2015 году и был очень популярен несколько лет, но сейчас это не самый лучший инструмент. Вопрос кэширования данных взяли на себя библиотеки swr, React Query, Apollo. Проблемы с явной передачей пропсов от корня к дочерним компонентам (props drilling) решается в React из коробки, начиная с версии 16.3, благодаря стабилизировавшемуся Context API. Также Марк говорит о том, что Redux неоптимален для работы со стейтом, но не приводит альтернатив, поэтому позволю себе наглость добавить их от себя: Mobx, Reatom, Effector.

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

#react #statemanagement

https://changelog.com/posts/when-and-when-not-to-reach-for-redux

Недавно Джейми Коултер запостил на codepen свою работу — полноценный квест с сюжетом, вся логика которого описывается в CSS. Илья Стрельцин разобрал внутреннее устройство квеста и написал статью "Безумие на чистом HTML + CSS".

Основная часть логики игры построена с помощью использования невидимых чекбоксов и радиокнопок, с помощью которых задаются стили других элементов. Такими элементами могут быть другие чекбоксы, образуя дерево состояний. Вся карта игры — большая картинка, поделенная на 64 сегмента-локации. Переход от локации к локации сделан с помощью чекбоксов, при их активации картинка "прокручивается" к нужной позиции. Для решения одной из загадок нужно открыть отсек с батарейками, Джейми придумал использовать <input type="range"> для эмуляции drag-n-drop.

Илья пишет, что такие штуки традиционно попадают в разделы типа «ненормальное программирование», но не становятся от этого менее интересными.

#css #fun

https://css-live.ru/tricks/bezumie-na-chistom-html-css.html

Сэм Ричард из Google написал статью об опыте добавления локализации и интернационализации для статически генерируемого сайта — "Internationalization And Localization For Static Sites".

Сэм работал над блогом chromeos.dev, для генерации сайта был выбран движок 11ty. Нужно было сделать так, чтобы переводчики могли без проблем работать с контентом. Рассматривалось несколько вариантов, остановились на структуре, в которой каждая локализация находится в своей директории, а логика адаптации контента под нужную локаль работает в сервис воркере.

Если пользователь заходит на сайт без установленного сервис воркера, то локализация страницы, на которую он попал, записывается в IndexedDB как предпочитаемый язык. Установленное значение можно потом поменять с помощью переключателя языков. После установки сервис воркера он начинает перехватывать все запросы на сайт и при необходимости перенаправляет на страницы с выбранной локалью.

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

#i18n #ssg

https://www.smashingmagazine.com/2020/11/internationalization-localization-static-sites/

Джош Комю написал статью о том, как он программирует без клавиатуры — "Hands-Free Coding".

В этом году у Джоша возник локтевой туннельный синдром, из-за которого он больше не может использовать мышь и клавиатуру. Чтобы продолжать работать, он перешёл на альтернативные системы ввода: голосовой ввод текста и систему отслеживания взгляда. Для голосового ввода текста используется программа Talon, которая приспособлена для написания кода. Для отслеживания взгляда используется девайс tobii 5. По сравнению с обычным воркфлоу скорость написания кода примерно в два раза ниже, но самое главное, что благодаря такому набору софта/железа можно полноценно работать с компьютером.

Рекомендую почитать статью и посмотреть там небольшие скринкасты рабочего воркфлоу Джоша.

P.S. В случае проблем не откладывайте поход к врачу, не упарывайтесь с кодом и делайте регулярные перерывы.

#programming #a11y

https://joshwcomeau.com/accessibility/hands-free-coding/
https://habr.com/ru/company/vdsina/blog/524664/ (перевод)

Тим Кадлек написал статью про лучшие практики использования скелетных экранов — "Effective Skeleton Screens".

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

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

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

#performance #ux

https://timkadlec.com/remembers/2020-11-02-skeleton-screens/

Нашёл статью Эрика Лоуренса, в которой рассказывается про историю появления алгоритма сжатия Brotli.

Brotli — это детище Google, которое было разработано Юрки Алакуйяла и Золтаном Сабадка. До Brotli Юрки разработал алгоритм сжатия Zopfli, который был совместим с DEFLATE, но работал на 5% лучше всех альтернатив. Brotli — это идейное продолжение Zopfli, комбинирующее алгоритм Хаффмана и LZ77. Он был разработан для формата шрифтов WOFF2, но потом был адаптирован для сжатия передаваемых данных между браузером и web-сервером.

Ребята из Google до внедрения Brotli экспериментировали с другими форматами сжатия (bzip2, SDCH). Во время экспериментов иногда возникали проблемы совместимости с промежуточными прокси-серверами и шлюзами, поэтому для предотвращения проблем доставки данных было решено сделать так, чтобы Brotli был доступен только по HTTPS.

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

#performance #algorithm #history

https://textslashplain.com/2015/09/10/brotli/