Дэниэл Эренберг — участник 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/

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

— Влияние типографики на производительность сайтов
— Опыт разработки JavaScript-песочницы
— Сравнение производительности Houdini Paint API и CSS
— Верхнеуровневый анализ проблем производительности сайтов
— Поиск неиспользуемого кода в TypeScript
— Почему разработка современного фронтенда это нетривиальная задача
— Проблемы производительности twitter.com
— UX-паттерны для безопасного выполнения операций
— Поддержка HTTP/3 в curl c помощью заголовка Alt-Svc
— Основной принцип работы со списками элементов

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

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

https://www.patreon.com/myshov

В блоге Google был опубликован апдейт про грядущие изменения в ранжировании результатов поиска — "Timing for bringing page experience to Google Search".

Пару месяцев назад Google объявил о том, что метрики производительности будут учитываться в ранжировании. Сегодня было опубликовано уточнение, что это произойдёт в мае 2021 года. Владельцам сайтов рекомендуется оптимизировать работу сайта с учётом метрик Web Vitals. Сайты с хорошим пользовательским опытом будут выделятся особой пометкой в результатах поиска. Также с мая 2021 года в новостную выдачу будут попадать не только AMP-сайты, но и обычные сайты, которые работают быстро.

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

#google #seo #performance

https://webmasters.googleblog.com/2020/11/timing-for-page-experience.html

Роб Палмер из Bloomberg рассказал об опыте использования TypeScript с огромной кодовой базой — "10 Insights from Adopting TypeScript at Scale".

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

TypeScript в Bloomberg используется как "JavaScript с типами", то есть без использования фич, которые не были стандартизированы TC39 (декораторы, enum, namespace и т.п.) Такой подход значительно облегчает дебаг сгенерированного JavaScript-кода и оставляет возможность для работы с JS-движками (задел на будущее), которые смогут отбрасывать типы и запускать TypeScript-код без предварительной компиляции.

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

#typenoscript #migration

https://www.techatbloomberg.com/blog/10-insights-adopting-typenoscript-at-scale/

Разработчики Chromium сообщили о своих планах полностью удалить поддержку Server Push и gQUIC — "Intent to Remove: HTTP/2 and gQUIC server push".

Server Push — фича HTTP/2, благодаря которой сервер может отправлять браузеру ресурсы, не дожидаясь от него явных запросов; gQUIC — нестандартный протокол, разработанный Google, который также позволяет пушить ресурсы. Пуши сложно настроить так, чтобы использующий их сайт всегда работал быстро, в самых плохих случаях они могут быть причиной деградации производительности.

Разработчики Chromium хотят удалить поддержку Server Push и gQUIC. Они ссылаются на проблемы производительности и на то, что оставлять их поддержку нет смысла, так как доля HTTP/2 соединений, использующих пуши, составляет 0.05%. Также реализация пушей в коде довольно сложная и её дорого поддерживать.

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

#performance #chromium #http

https://groups.google.com/a/chromium.org/g/blink-dev/c/K3rYLvmQUBY

Вчера вышел Angular 11. Марк Тексон рассказал про новые фичи релиза — "Version 11 of Angular Now Available".

С версии Angular 11 шрифты будут инлайниться по умолчанию. Улучшена инфраструктура для тестирования компонентов. Улучшен вывод информации о процессе сборки. Идёт работа над Language Service, который улучшает опыт разработки, предоставляя полезные сервисы для IDE (полноценный релиз запланирован в следующей версии). Улучшена поддержка Hot Module Replacement (HMR). Ускорена сборка благодаря переходу на TypeScript 4.0 и улучшениям в Angular compatibility compiler (ngcc).

Также появилась экспериментальная поддержка Webpack 5 (для её включения нужен yarn). TSLint официально задеприкейчен; рекомендуется переходить на ESLint. Была удалена поддержка IE9, IE10 и IE mobile.

Команда Angular начинает больше работать с сообществом. У проекта появился публичный Roadmap. Идут активные работы по инвентаризации всех открытых ишью. Было исправлено несколько проблем и реализована новая фича с большим количеством голосов.

#release #angular

https://blog.angular.io/version-11-of-angular-now-available-74721b7952f7

В начале этого месяца Николь Салливан из Google твитнула о старте работ над внедрением в Chromium долгожданной фичи — выражений от контейнера (container queries). Через некоторое время Брайан Карделл написал статью о проделанной работе над выражениями от контейнера со стороны Igalia.

Над отзывчивыми элементами (aka responsive elements или container queries) авторы спецификаций и разработчики браузерных движков бьются уже несколько лет. До недавнего времени они не могли найти такое решение, которое было бы эффективно и которое бы не требовало изменения архитектуры текущих реализаций CSS-движков. Работа продвинулась после реализации во всех браузерах ResizeObserver. Благодаря отзывчивым элементам можно описывать стили элементов, которые зависят от ширины элементов, не используя JavaScript.

На данный момент разработчики браузеров подходят к разработке фичи с разных сторон. Брайан и его команда из Igalia работают над новой CSS-функцией switch(), которая будет служить основой для добавления нового синтаксического сахара в будущем, например, синтаксиса выражений от контейнера. Эмилио Кобос из Mozilla работает над похожим примитивом nth-value() (по сути альтернативный синтаксис switch() ), который можно очень легко интегрировать в текущую кодовую базу любого браузера. (Уже после публикации статьи Брайан Карделл дал фидбек по статье и рассказал, что идея switch() была предложена архитектором Google, который отвечает за движок layout'а в Chrome). Разработчики из Google идут другим путём и хотят сразу реализовать поддержку выражений от контейнера без добавления в CSS новых примитивов. Стоит сказать, что Igalia и Google не конкурируют друг с другом по этому вопросу. Их работа в конечном счёте будет дополнять друг друга.

В общем, работа над отзывчивыми элементами кипит. CSS-функции, над которыми работают Брайан и Эмилио, всего лишь эксперимент, который с большой вероятностью примет другую форму, если всё пойдёт хорошо. Синтаксис выражений от контейнера, который внедряется Google, также неспецифицирован официально и тоже непонятно, что мы получим в будущем как стандарт.

UPD: Обновил статью с учётом фидбека Брайана и Николь

#css #experimental

https://bkardell.com/blog/AllThemSwitches.html
https://twitter.com/stubbornella/status/1324524942650601472

Томас Штайнер в блоге web.dev рассказал про File Handling API — "Let web applications be file handlers".

С помощью File Handling API можно открывать файлы из операционной системы в установленном pwa как в обычном нативном приложении. Это ещё один шаг в направлении сближения возможностей web и нативных платформ.

Для создания ассоциации файлов с pwa-приложением в манифесте в разделе file_handlers нужно указать соответствие между url и типом открываемых файлов. В самом приложении нужно обработать очередь файлов с помощью launchQueue:

if ('launchQueue' in window) {
  launchQueue.setConsumer((launchParams) => {
    // если очередь пустая, ничего не делать
    if (!launchParams.files.length) {
      return;
    }
    for (const fileHandle of launchParams.files) {
      // обработка файлов
    }
  });
}

File Handling API находится на стадии активной разработки. На данный момент он доступен только в Chromium за экспериментальным флагом file-handling-api.

#pwa #experimental

https://web.dev/file-handling/

Буквально на днях выйдет новая версия Firefox. В неё попадут изменения с улучшением работы JS-движка SpiderMonkey. Обо всех подробностях рассказал Ян дер Моой в статье "Warp: Improved JS performance in Firefox 83".

В SpiderMonkey используется два уровня компиляции кода: Baseline JIT для быстрой генерации байткода с минимальным количеством оптимизаций и Ion для генерации оптимизированного байткода. Ion в Firefox 83 будет заменён на новый оптимизирующий JIT-компилятор Warp. Warp в отличие от Ion не использует глобально собираемую информацию о типах и использует формат представления байткода CacheIR, которое используется в Baseline JIT.

Благодаря этим изменениям удалось ускорить выполнение JS-кода и уменьшить потребление памяти. Google Docs с Warp работает на 20% быстрее, бенчмарк Speedometer — на 10-12% быстрее. Firefox с Warp потребляет примерно на 8% меньше памяти по сравнению с Ion.

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

#performance #firefox #internals

https://hacks.mozilla.org/2020/11/warp-improved-js-performance-in-firefox-83/

Сегодня вышел Firefox 83.

В новой версии добавлен режим HTTPS-only (выключен по умолчанию). С включенным HTTPS-only все устанавливаемые соединения будут использовать HTTPS. Если установка безопасного соединения невозможна, будет отображено сообщение об ошибке с возможностью перейти к ресурсу по HTTP. HTTPS-only включается в настройках в разделе "Privacy & Security".

В JS-движок SpiderMonkey добавлен новый оптимизирующий JIT-компилятор Warp. Благодаря ему загрузка страниц ускорилась на 15%, а общее потребление памяти снизилось на 8%. Более подробно о новом JIT-компиляторе можно почитать в предыдущем посте.

В Firefox теперь можно заполнять, сохранять и распечатывать PDF-формы AcroForm с помощью встроенного просмотрщика PDF. Добавили pinch-to-zoom в Windows (для сенсорных дисплеев) и macOS (для тачпадов). Улучшили интерфейс демонстрации экрана.

Для разработчиков не очень много изменений. В CSS была добавлена поддержка конических градиентов conic-gradient(). Свойство :-moz-any() теперь обычный алиас для :is(). В Intl добавлен метод Intl[Symbol.toStringTag], возвращающий строку "[object Intl]". В инспекторе элементов DevTools у DOM-элементов, приводящих к появлению полос прокрутки, теперь отображается бейдж "scroll" (помогает при дебаге двойных скроллов на странице).

#release #firefox

https://www.mozilla.org/en-US/firefox/83.0/releasenotes/
https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/83

Вчера вышла новая версия Chrome. Пит Лепаж рассказал про новые фичи релиза — "New in Chrome 87".

Появилась полноценная поддержка web-камер с функциями панорамы, поворота и зума (PTZ — pan, tilt, zoom). Чтобы проверить поддержку PTZ на уровне браузера нужно использовать метод navigator.mediaDevices.getSupportedConstraints(), для проверки поддержки PTZ у web-камеры — MediaStreamTrack.getSettings().

В сервис воркерах теперь работает получение чанков файлов с помощью HTTP range requests. Раньше для этого использовались разные хаки, с версии Chrome 87 они больше не нужны.

В рамках Origin Trials появилась поддержка Font Access API для получения доступа к локально установленным шрифтам. Это полезно для дизайнерских программ, например, Figma, Gravit, Photopea. Есть возможность получения доступа к потоку байтов шрифта для трансформации глифов или наложения на них векторных фильтров.

Как обычно очень много изменений в Chrome DevTools. Появился инструмент для визуального дебага гридов. Добавлена эмуляция Web Authentication API (доступна на вкладке WebAuthn). Теперь можно одновременно держать открытыми несколько вкладок из одной категории, например, Elements и Sources. Lighthouse обновлён до весрии 6.4 с поддержкой валидации предзагрузки шрифтов для font-display: optional, валидацией соурсмапов и экспериментальной фичей для обнаружения больших JavaScript-библиотек.

#release #chrome

https://developers.google.com/web/updates/2020/11/nic87
https://developers.google.com/web/updates/2020/10/devtools

Карл Джонсон рассказал, почему он отказался от поддержки IE11 в пользу улучшения работы сайта для браузеров с отключённым JS — "Dropping Support For IE11 Is Progressive Enhancement".

Основная мысль статьи. Число пользователей IE11 с каждым годом всё меньше и меньше, но мы продолжаем по инерции транспайлить код в ES5. В некоторых случаях надо прилагать дополнительные усилия, чтобы новая фича заработала под IE11 только для того, чтобы спустя полгода обнаружить, что она была сломана несколько месяцев назад.

Большинство команд без выделенного QA-отдела, постоянно проверяющего работу сайта в IE11, может без проблем дропнуть его поддержку. У пользователей IE11 скорее всего в системе установлен более современный браузер. Освободившиеся ресурсы можно отправить на улучшение доступности и работы сайта без JavaScript (progressive enhancement), это принесёт гораздо больше пользы.

Очень хорошая статья. Дайте её почитать вашим менеджерами, кто сомневается в пользе отказа от IE11.

#musings #ie

https://blog.carlmjohnson.net/post/2020/time-to-kill-ie11/

Неделя релизов продолжается. Вчера вышел TypeScript 4.1. Дениэл Розенвассер рассказал о всех изменениях в новой версии.

В TypeScript 4.1 были добавлены литеральные шаблонные типы (Template Literal Types). Благодаря им можно описывать типы, состоящие из нескольких строковых литеральных типов. Также они позволяют на уровне типов "извлекать" строковые литералы из других литералов. В рамках этой фичи были добавлены новые утилитарные типы для манипуляции строками — Uppercase, Lowercase, Capitalize , Uncapitalize.

С новой версии можно ремапить ключи в отображаемых типах (mapped types). Это можно использовать для фильтрации свойств объектных типов или создания новых объектных типов с ключами, использующими литеральные шаблонные типы.

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

Добавлен флаг --noUncheckedIndexedAccess для более строгой проверки доступа к элементам массивов или свойствам объектов. Параметр paths теперь можно использовать без указания baseUrl. Теперь необязательно включать allowJs при использовании опции checkJs. Добавлена поддержка фабрик jsx и jsxs из React 17 (используются транспиляторами).

Есть несколько ломающих изменений. Условные спрэды создают опциональные свойства. Нужно обязательно указывать параметр функции resolve у промисов. Абстрактные члены больше не могут объявляться с async. Если в условном выражении falsy-позиция возвращает тип any`/`unknown, то any`/`unknown будет распространено на всё выражение.

#release #typenoscript

https://devblogs.microsoft.com/typenoscript/announcing-typenoscript-4-1

Стэфани Стимак написала статью о том, почему элементы управления форм плохо кастомизируются и какие предпринимаются шаги, чтобы изменить эту ситуацию — "Standardizing <select> And Beyond: The Past, Present And Future Of Native HTML Form Controls".

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

Для решения этой проблемы была запущена инициатива Open UI в рамках Web Incubator Community Group. Open UI — это каталог элементов с описанием их семантики, поведения и структуры. Работа над Open UI будет служить основой для развития спецификаций элементов управления форм.

Работа над Open UI не завершена. Стефани приглашает всех желающих присоединиться к работе над проектом.

https://www.smashingmagazine.com/2020/11/standardizing-select-native-html-form-controls/