Команда разработчиков 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

Недавно вышла первая стабильная версия официального консольного клиента для GitHub. Аманда Пинскер в статье "GitHub CLI 1.0 is now available" рассказала про его основные возможности.

Консольный клиент позволяет вести полный цикл разработки фичи с использованием GitHub, не выходя из терминала. С его помощью можно найти нужный issue, создать пулл реквест, сделать ревью пулл реквеста, вывести текущий статус проверок, смержить пулл реквест, сделать релиз и многое другое. Можно создать gist прямо из консоли: echo hey | gh gist create. Благодаря интеграции с API можно автоматизировать практически любую задачу.

Возможно вы знакомы с похожей утилитой — hub. Её основного разработчика (Мислава Маронича) нанял GitHub для разработки с нуля нового клиента. Мислав больше не планирует развивать hub, так как проект стал очень затратен в поддержке. Изначальная идея того, что hub может быть враппером вокруг команд git, оказалась неудачной. Про это он написал пост в своём блоге.

#release #tool #github #cli

https://github.blog/2020-09-17-github-cli-1-0-is-now-available/
https://mislav.net/2020/01/github-cli/

Крис Фоллин написал статью про новую архитектуру бэкенда Cranelift — "A New Backend for Cranelift, Part 1: Instruction Selection".

Cranelift — это фреймворк для компиляторов, написанный на Rust. По своему дизайну он похож на llvm: фронтенд часть отвечает за преобразование кода в промежуточное представление (IR), бэкенд часть — за компиляцию IR в исполняемый код целевой платформы. Cranelift используется в Firefox для компиляции wasm. Также он используется в качестве компилятора в wasmtime — обособленном рантайме для WebAssembly.

Старая архитектура бэкенда Cranelift была сложна для добавления новых фич. Также нельзя было скомпилировать последовательность из нескольких команд IR в одну команду (отношение "многие к одному"). Новая архитектура решает эти проблемы.

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

#firefox #internals #wasm

https://cfallin.org/blog/2020/09/18/cranelift-isel-1/

Узнал сегодня про фреймворк neo.mjs. Его основная фишка — разделение SPA на связанные части, с которыми можно работать из разных окон/вкладок. Тобиас Улих — автор фреймворка — написал статью про его особенности — "Expanding Single Page Apps into multiple Browser Windows".

Neo.mjs под капотом активно использует SharedWorker — специальный вид воркера, доступ к которому можно получить из разных контекстов браузера. Приложения, написанные с помощью этого фреймворка, используют минимум три воркера: VDOM Worker (работа с Virtual DOM), Shared App Worker (общее состояние приложения), Shared Data Worker (работа с данными). Каждое новое окно с приложением обращается к ним для выполнения своих задач. Благодаря такому подходу становятся возможны интересные пользовательские сценарии, например, перемещение компонента или дерева компонентов в другое окно/таб браузера с сохранением состояния инстанса компонента.

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

В общем, интересный подход. Но, как мне кажется, он не станет массовым, так как сложнее в реализации и поддержке по сравнению с традиционными SPA.

#jsframeworks

https://medium.com/swlh/expanding-single-page-apps-into-multiple-browser-windows-e6d9bd155d59

Примерно месяц назад вышел первый релиз кандидат React 17, в котором нет новых значимых фич. Но в новой версии появится поддержка нового типа преобразования JSX (JSX transform), благодаря которому больше не нужно постоянно импортировать React. Луна Руан в блоге React написала про это статью — "Introducing the New JSX Transform".

Babel и TypeScript преобразуют JSX в вызовы функций React.createElement, поэтому нужно импортировать React в текущий скоуп. Это неинтутивно. Также использование React.createElement влечёт за собой дополнительные накладные расходы. Для решения этих проблем был разработан новый тип преобразований JSX.

React 17 RC включает в себя две новые функции jsx и jsxs, которые должны использоваться только транспиляторами. Транспиляторы импортируют их в код компонентов автоматически при преобразовании JSX.

Поддержка нового преобразования уже есть в Babel 7.9 и TypeScript v4.1 beta. Для его включения в babel 7.9 нужно указать опцию {"runtime": "automatic"}. В babel 8 он будет включаться по умолчанию.

Новый JSX transform будет бэкпортирован в React 16.x, React 15.x и React 0.14.x.

#react #jsframeworks

https://reactjs.org/blog/2020/09/22/introducing-the-new-jsx-transform.html

Вчера вышел Firefox 81. В новой версии нет каких-либо больших изменений.

Атрибут sandbox у iframe'ов теперь поддерживает токен allow-downloads. Также у iframe'ов была удалена поддержка нестандартного mozallowfullscreen, вместо него следует использовать allow="fullscreen". Новая версия Firefox начала поддерживать нестандартный HTTP-заголовок Content-Disposition, содержащий имя файла с пробелами без кавычек. Скрипты воркеров с неправильным MIME-типом теперь будут блокироваться в Worker и SharedWorker.

Улучшена доступность элементов video и audio. Их элементы управления остаются доступны, даже если они были визуально временно скрыты. Оставшееся время проигрывания теперь доступно скринридерам.

В инструментах разработчика дебагер отображает TypeScript-файлы соответствующей иконкой. JSON-ответы с XSSI-защитой корректно парсятся и отображаются в виде дерева. Добавлена поддержка остановки выполнения скрипта на первой инструкции. Улучшен инструмент симуляции проблем со зрением.

#firefox #release

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

В блоге v8 был опубликован пост Марьи Хёлтэ про использование Atomics — "Atomics.wait, Atomics.notify, Atomics.waitAsync".

Объект Atomics предоставляет набор функций для атомарной работы с разделяемой памятью в воркерах. Можно сказать, что это низкоуровневое API для организации конкурентной работы в JavaScript. В статье разбирается пример создания класса AsyncLock, который реализует мьютекс c помощью Atomics.wait, Atomics.notify и Atomics.waitAsync. Атомики были добавлены в спецификацию ES2017. Их поддержка есть в Firefox, Chrome и Node. Поддержка Atomics.waitAsync пока доступна только в Chrome.

Никогда не работал с Atomics, захотелось посмотреть их в работе. Написал небольшой пример использования AsyncLock (линк на пример в конце этого поста).

В общем, рекомендую заглянуть в статью, если интересно узнать как работать с Atomics.

#js

https://v8.dev/features/atomics
https://github.com/myshov/asynclock

Кэти Хэмпениус написала большую статью про сети доставки содержимого — "Content delivery networks (CDNs)".

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

В статье разбираются фичи и протоколы, которые предоставляют современные CDN: TLS 1.3, HTTP/2, HTTP/3, минификация ресурсов, оптимизация изображений и т.п. Есть немного про тюнинг кэширования и возможные проблемы, с которыми можно столкнуться при включении HTTP/2.

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

#performance #net

https://web.dev/content-delivery-networks/

Лия Веру недавно написала статью с критикой web-компонентов — "The failed promise of Web Components".

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

Хорошая инициатива. Но Доменик Деникола (гуглер, занимающийся разработкой web-стандартов) в комментариях пишет о том, что недостаточно создать реестр, также нужно решить проблемы совместимости браузеров.

#webcomponents #musings

https://lea.verou.me/2020/09/the-failed-promise-of-web-components/

Ян Шеффлер и Сигурд Шнейдер — разработчики Chrome DevTools — рассказали о том, как они добавляли новую фичу в инструменты разработчика — "How we built the Chrome DevTools Issues tab".

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

Добавление новой фичи в инструменты разработчика может затрагивать три области: основной код Chromium, Chrome DevTools Protocol (CDP — это по сути бэкенд для DevTools) и пользовательский интерфейс DevTools (написан с использованием HTML, CSS и JS). В случае добавления "Issues" понадобилось модифицировать только CDP и фронтенд.

Рекомендую заглянуть в статью, если интересно узнать о том, как разрабатывается Chrome DevTools.

#chrome

https://developers.google.com/web/updates/2020/09/issues-tab

Йоханнес Бойс опубликовал итоги анализа производительности большого числа сайтов — "Core Web Vitals – Wix vs. WordPress, Shopify vs. Shopware – What’s fastest?".

В исследование попали 18 миллионов доменов со статистикой о используемых технологиях (CMS, CDN, языки программирования и т.п.) и данными по разным типам устройств. Из самого интересного. Среди CMS самые лучшие метрики производительности показали Jimdo и Typo3. Медленнее всех оказался WIX, на предпоследнем месте находится Wordpress. Только 70% проанализированных AMP-страниц удовлетворяют хорошим показателям Web Vitals. Используемые языки программирования не влияют на метрики производительности. Очень медленными оказались сайты, которые используют Angular.

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

#research #performance

https://www.sistrix.com/blog/core-web-vitals-wix-vs-wordpress-shopify-vs-shopware-whats-fastest

Пролетело две недели. Пора сделать апдейт о том, что было опубликовано в Defront Plus за это время:

— Как в Slack разрабатывают хорошие HTML-формы
— От Rust к TypeScript
— Производительность сайтов, использующих JAMStack-архитектуру
— Эффективная отправка запросов с помощью пула промисов (promise pool)
— Этичность трекинга пользователей с помощью CSS
— Особенности работы и разработки JavaScript-минификаторов
— Скрипты для анализа проблем настройки окружения для разработки
— Создание изображения, которое можно выполнить как JS-код
— 6 способов синхронизации данных между табами
— Сравнение React и web-компонентов

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

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

https://www.patreon.com/myshov

P.S. В опросе по поводу частоты постов о Patreon голоса распределились примерно одинаково на трёх вариантах. Поэтому пока оставлю так как есть. Одна публикация в две недели кажется самым лучшим вариантом.

Сергей Руденко из Airbnb написал статью про миграцию кодовой базы фррнтенда компании с JavaScript на TypeScript — "ts-migrate: A Tool for Migrating to TypeScript at Scale".

Для миграции они разработали инструмент ts-migrate, который помогает в массовой конвертации JavaScript файлов. Для автоматического поиска проблемных мест в коде и запуска необходимых трансформаций используются диагностики TypeScript language server. Трансформации представляют собой кодмоды, которые могут использовать jscodeshift, AST TypeScript или могут работать с исходным кодом как с обычным текстом. Есть трансформации для упрощения миграции на TypeScript React-компонентов, но без поддержки хуков.

Благодаря ts-migrate в Airbnb на TypeScript было переведено более 80% всей кодовой базы фронтенда (6 миллионов строк кода). Но так как утилита устанавливает any в проблемных местах, у ребят осталось ещё много работы над добавлением полноценных типов.

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

#typenoscript #migration #tool

https://medium.com/airbnb-engineering/ts-migrate-a-tool-for-migrating-to-typenoscript-at-scale-cd23bfeb5cc

Джейсон Миллер и Мэйсон Фрид представили экспериментальную поддержку Declarative Shadow DOM в Chrome.

Declarative Shadow DOM позволяет описывать разметку web-компонентов декларативно в коде HTML-страницы без использования императивного API с помощью JavaScript. Это очень важная фича для развития экосистемы web-компонентов. Про неё уже был пост в канале, его можно найти тут.

Самое главное на что стоит обратить внимание при использовании Declarative Shadow DOM. Построение Shadow DOM производится на этапе парсинга страницы, за счёт этого компоненты на странице рендерятся быстрее по сравнению с традиционным императивным подходом. Элемент template c атрибутом shadowroot становится теневым корнем (shadow root) и автоматически прикрепляется к родительскому элементу. Для сериализации DOM дерева с Shadow DOM можно использовать новый метод getInnerHTML().

Экспериментальная поддержка Declarative Shadow DOM появилась в Chrome 85. Ожидается, что она будет включена по умолчанию в Chrome 88. Браузеры без поддержки Declarative Shadow DOM могут использовать полифилл.

#experimental #webcomponents

https://web.dev/declarative-shadow-dom/

Зейнеп Канкара в блоге V8 написала статью про Indicium — новый инструмент рантайм анализа V8 — "Indicium: V8 runtime tracer tool".

Чтобы понять, зачем нужен этот инструмент, нужно немного разобраться в кишках V8. Для представления JavaScript-объектов V8 использует специальную структуру — Map (не тот Map, который определён в ECMAScript). Благодаря этой структуре движок экономит оперативную память при работе с большим числом однотипных объектов. Map в свою очередь использует оптимизацию Inline Cache (IC) для быстрого доступа к свойствам объектов.

Внутри V8 уже есть всё необходимое для получения информации о Map и IC, и уже есть готовые инструменты для их анализа. Indicium представляет эту информацию в удобном виде, связывая между собой Map и IC. С помощью него можно проанализировать создание объектов и быстро выявить проблемные места в исходном коде.

Indicium — это ещё один полезный инструмент для анализа проблем производительности в Chromium и Node.js.

#performance #tool #v8

https://v8.dev/blog/system-analyzer

Вчера, когда писал пост про Indicium, в ссылках увидел очень интересную статью Матиаса Байненса и Бенедикта Мюрера про концепции, которые используются при создании всех современных JS-движков — "JavaScript engine fundamentals: Shapes and Inline Caches".

Современные движки (V8, SpiderMonkey, JavaScriptCore, Chakra) преобразуют абстрактное синтаксическое дерево программы в байткод, который исполняется интерпретатором. Во время исполнения программы собирается дополнительная информация, на основе которой оптимизирующий компилятор преобразует байткод в машинный код. В разных движках этот пайплайн компиляции/интерпретации уникален. В V8 есть один оптимизирующий компилятор (TurboFan), в SpiderMonkey два (Baseline, Ion Monkey), в JavaScriptCore три (Baseline, DFG, FTL).

При работе с объектами движки тоже похожи друг на друга. При создании объекта в памяти, они сохраняют структуру объекта в скрытый класс, который в разных движках называется по-разному (Map, Shape, Type, Structure). Благодаря использованию скрытых классов происходит экономия оперативной памяти и становится возможна оптимизация "Inline Cache" для быстрого доступа к свойствам объекта.

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

Интересная статья. Очень рекомендую почитать всем, кто интересуется внутренним устройством JS-движков.

#js #internals

https://mathiasbynens.be/notes/shapes-ics

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

https://defront.ru/posts/2020/10-october/03-detached-window-memory-leaks/

Джейсон Миллер и Бартек Новиерски из Google рассказали о том, как находить и предотвращать утечки памяти, вызванные откреплёнными окнами, — "Detached window memory leaks".

Откреплённое окно (detached window) — это такое окно, которое было закрыто, но которое всё ещё доступно из JavaScript-кода. Под это определение также попадает iframe (он ведёт себя как вложенное в документ окно), когда в коде сохраняется ссылка на contentWindow или contentDocument. Обычно ссылки на откреплённые окна сохраняются по ошибке, а утечки памяти, связанные с ними, сложно локализовать.

В статье рассказывается о том, как с помощью DevTools находить проблемный код. Предлагается пять вариантов предотвращения появления утечек: обычное удаление ссылки на окно, удаление ссылки при возникновении события pagehide (или установки свойства window.closed ), с помощью использования WeakRef, с помощью использования postMessage для коммуникации окон между собой, с помощью открытия окна с использованием опции noopener.

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

#js

https://web.dev/detached-window-memory-leaks/