Недавно вышла новая версия TypeScript. Дениэл Розенвассер рассказал про новые фичи релиза — "Announcing TypeScript 3.8".

С версии 3.8 можно явно указывать, что импортируется/экспортируется тип, а не значение: import type { SomeThing } from "./some-module.js";. Если импортируется только тип, то на этапе транспиляции import удаляется. Иногда из-за этого возникают ошибки в рантайме, например, в Angular.js (1.x) ломалась регистрация сервисов. С появлением более тонкой декларации импортов и новой опции importsNotUsedAsValues теперь можно предотвратить подобные ошибки.

Была добавлена поддержка Private Fields из предложения Class field declarations, с помощью которой можно создавать приватные поля класса #foo = 'bar'. В TypeScript была возможность создания приватных полей с помощью модификатора private, но Private Fields дают настоящую приватность (hard privacy) на уровне цели транспиляции. Также благодаря им решается проблема с перекрытием полей.

Добавили поддержку пропозала top-level await. Эта фича избавляет от необходимости заворачивать в async-функцию код с await. Она работает только для модулей, поэтому, если ваш файл ничего экспортиует/импортирует, для того чтобы заработал top-level await надо будет добавить формальный экспорт export {}.

Реализовали поддержку ещё одного пропозала будущего стандарта export * as ns. Добавили поддержку модификаторов @public, @private, @protected в JSDoc. Очень много изменений было сделано для улучшения вотчинга файлов — теперь в tsconfig.json есть новая группа опций watchOptions. Реализовали "неточную и быструю" инкрементальную сборку, которая позволяет ускорить скорость пересборки проекта за счёт снижения строгости проверок. В редакторах появятся новые пункты меню для конвертации конкатенации строк в шаблонные строки и для визуализации иерархии вызовов функций.

#typenoscript #release #announcement

https://devblogs.microsoft.com/typenoscript/announcing-typenoscript-3-8/

Сегодня столкнулся с циклическими зависимостями в своём проекте. Захотелось посмотреть, как эту проблему решают другие. Нашёл статью Мишеля Вестстрате (автор mobx) — "How to fix nasty circular dependency issues once and for all in JavaScript & TypeScript".

Суть подхода заключается в использовании двух файлов internal.js и index.js. Файл internal.js реэкспортит все локальные модули. Файл index.js (входная точка в библиотеку) реэкспортит содержимое internal.js — export * from "./internal.js";. Локальные зависимости должны импортировать нужные сущности только из internal.js. В internal.js все реэкспорты размещаются в таком порядке, в котором все зависимости будут корректно разрешены. Благодаря такому подходу можно управлять порядком загрузки модулей.

В итоге пофиксил циклические зависимости по-другому, но взял на заметку подход Мишеля.

#js #esm #trick

https://medium.com/visual-development/how-to-fix-nasty-circular-dependency-issues-once-and-for-all-in-javanoscript-typenoscript-a04c987cf0de

Пару недель назад Мэйсон Фрид из команды разработки Chrome представил предложение о добавлении декларативного способа создания Shadow DOM.

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

Предложение "Declarative Shadow DOM" решает эти проблемы. Декларативная разметка с Shadow DOM может быть отрендерена браузерами без использования JS. Также поисковикам не надо исполнять JS, достаточно модифицировать парсер, чтобы уметь понимать новый атрибут shadowroot в <template>.

Мейсон сделал экспериментальную реализацию декларативного Shadow DOM, которая показала значительный прирост производительности относительно императивного API, так как из этапа рендеринга веб компонентов отпал шаг выполнения JavaScript-кода.

Очень многообещающее предложение. Также радует сам факт того, что разработчики Chrome наконец-то признали, что основной камень преткновения в адаптации веб компонентов — сервер-сайд рендеринг.

#proposal #experimental #webcomponents

https://github.com/mfreed7/declarative-shadow-dom

Тим Кадлек в статье "When CSS Blocks" рассказал, как паттерн оптимизации загрузки CSS нарушает оптимальный порядок загрузки ресурсов и блокирует парсинг HTML.

Когда браузер парсит страницу и видит, что нужно загрузить css, он останавливает процесс рендеринга страницы и ждёт загрузки CSS. Для загрузки некритичного CSS такое поведение нежелательно, поэтому появился паттерн "preload/polyfill", в котором CSS загружается с помощью <link rel="preload" ...> в неблокирующем режиме. Если preload не поддерживается браузером то в работу вступает небольшой полифилл.

Тут возникает две проблемы: 1) использование preload откладывает загрузку важных ресурсов и некритичный CSS загружается в первую очередь, 2) когда полифилл инициирует загрузку CSS, парсинг html останавливается полностью, таким образом сайт рендерится с задержкой. Тим пишет, что авторы паттерна "preload/polyfill" больше не рекомендуют его использовать, а предлагают использовать трюк с медиа:

<link rel="stylesheet" href="/path/to/my.css" media="print" onload="this.media='all'">

Но устаревший паттерн продолжают использовать по инерции, создавая проблемы с производительностью.

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

#perfromance #browser #css

https://timkadlec.com/remembers/2020-02-13-when-css-blocks/

Сегодня на youtube-канале Honeypot вышел документальный фильм, посвящённый Vue.js.

В фильме рассказывается про историю появления фреймворка и про людей, стоящих за его разработкой. Vue.js разработал Эван Ю в 2013 году. Сначала проект назывался seed.js, но когда наступил момент публикации пакета в npm, оказалось, что это имя уже было занято. Эван пошёл в Google Translate и посмотрел перевод слова "view" на разные языки, в итоге он выбрал французский вариант — "vue".

Сначала проект разрабатывался для души, когда Эван работал в Google. Работа над Vue открыла новые возможности — Эвана пригласили работать в команду Meteor. В этот период он параллельно занимался разработкой и Vue, и Meteor. Он не был доволен темпами развития Meteor, поэтому решил рискнуть и полностью переключился на разработку Vue. Риск того стоил. Сейчас у Vue большое сообщество, фреймворк используют по всему миру, а в Китае Эван стал практически национальным героем среди разработчиков.

Ламповый и вдохновляющий фильм. Очень рекомендую посмотреть.

#vue #history

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

На сайте Mozilla Hacks появилась интересная статья Натана Фройда про новый механизма сандбоксинга кода — "Securing Firefox with WebAssembly".

Для предотвращения выполнения вредоносного кода в Firefox используется два подхода: сандбоксинг на уровне процессов и переписывание критичных частей на Rust. Первый подход хороший, но требует много системных ресурсов, переписывание на Rust не всегда самый оптимальный вариант.

Исследователи из Стенфорда, UC и других университетов представили новый инструментарий для более простого сандбоксинга библиотек — RLBox, который сейчас внедряется в Firefox. Его идея состоит в компилировании потенциально небезопасного кода в wasm. Скомпилированный wasm-модуль затем компилируется в нативный код, который может использоваться из любой подсистемы браузера. Данные, которые обрабатываются скомпилированным модулем считаются "испорченными" (tainted), их корректность использования проверяется на этапе компиляции. Если сторонняя библиотека была скомпроментирована, то благодаря дополнительному набору проверок небезопасный код не сможет попасть в браузер. Этот подход уже внедряется в Firefox 74 (Linux) для сандбоксинга библиотеки рендеринга шрифтов Graphite.

WebAssembly давно используется для разработки сложных web-приложений, идёт работа над системным интерфейсом для wasm (WASI), который уже поддерживается в Node.js, и вот сейчас его начинают использовать для изоляции библиотек. WebAssembly становится по-настоящему мощным инструментом.

#security #webassembly #internals

https://hacks.mozilla.org/2020/02/securing-firefox-with-webassembly/

Сегодня вышла новая версия React v16.13.0. Санил Пай рассказал про все изменения в релизе.

Продолжается работа над чисткой кода от устаревших API. Теперь при использовании String Refs в консоль будет лететь deprecated-предупреждение. Также устаревшим методом тперь считается React.createFactory, который использовался для создания компонентов без JSX. Устаревшим методом объявлен unstable_createPortal, вместо него нужно использовать createPortal (достаточно переименовать метод).

Были улучшены сообщения о проблемах. При ошибках гидрации в новой версии отображается стек компонентов, в котором была обнаружена проблема. Теперь отображается предупреждение при смешивании коротких и длинных версий CSS-свойств в style. Делегация вызова setState другому компоненту теперь не поощряется, при таком использовании setState в фазе рендера будет возникать предупреждение (Warning: Cannot update a component from inside the function body of a different component.).

Было сделано несколько улучшений. Добавлена забытая проверка двойного вызова shouldComponentUpdate в React Strict Mode для обнаружения нежелательных сайд-эффектов. onMouseEnter больше не вызывается на неактивном <button>.

#react #release #announcement

https://reactjs.org/blog/2020/02/26/react-v16.13.0.html

Пару недель назад инженеры из Netflix рассказали про новый открытый формат изображений — "AVIF for Next-Generation Image Coding".

Вопрос качества и объёма передаваемых изображений для Netflix стоит особенно остро, поэтому они присоединились к разработке нового формата изображений AVIF на базе кодека AV1, который в свою очередь используется для кодирования видео. На данный момент это один из самых лучших форматов, который превосходит по качеству webp, который был разработан на базе кодека предыдущего поколения VP8. AVIF поддерживает High Dynamic Range (HDR), Wide Color Gamut (WCG) и Standard Dynamic Range (SDR). Для сравнения качества сжатия разных кодеков был разработан специальный фреймворк. Результаты сравнения показали преимущество AVIF.

В ближайшем будущем стоит ожидать появления поддержки AVIF в браузерах — работа над добавлением AVIF в Chrome уже началась. Также The Alliance for Open Media разрабатывает свободную библиотеку для работы с новым форматом. В мае прошлого года поддержка AVIF была добавлена в Windows 10.

#image #codec #optimization

https://netflixtechblog.com/avif-for-next-generation-image-coding-b1d75675fe4

Прямая трансляция конференции Я ❤︎ Фронтенд 2020 с докладами про глазные интерфейсы, семантику, ApolloClient, роутеры, картинки, BFCache, пет-проджекты и менторство. Начало в 11:00 (GMT+3) — https://youtu.be/eLlULhNNthI, программа — https://ilovefrontend.ru

Пару дней назад Себастьян Маккензи — отец Babel и Yarn — представил новый проект Rome. Джейсон Миллер сделал небольшой обзор нового инструмента — "Rome, a new JavaScript Toolchain".

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

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

Rome — экспериментальный проект, его пока не рекомендуется использовать в production. Проект очень амбициозный, но он вполне может взлететь, учитывая послужной список проектов Себастьяна.

#js #experimental #tool

https://jasonformat.com/rome-javanoscript-toolchain/
https://github.com/facebookexperimental/rome

Нашёл интересную статью Яна Моншке из Soundcloud про оптимизацию потребления памяти в Redux-приложении — "Garbage Collection in Redux Applications".

При портировании Soundcloud на Xbox One разработчики столкнулись с тем, что операционная система закрывала работающее в фоне приложение, когда потребляемая память превышала 128Мб. Проблема оказалась в Redux-сторе — данные треков, которые уже были не нужны, продолжали лежать в памяти.

Для решения проблемы удаления устаревших данных разработчики реализовали подобие алгоритма сборки мусора mark-and-sweep. В их случае фаза "mark" работает с помощью кастомного коннектора стора, который отслеживает данные, которые нужны для отображения примонтированных компонентов. Фаза "sweep" реализована как обычный редюсер, который начинает работать при получении экшена, который сигнализирует о запросе начать повторное формирование стора на основе информации собранных на этапе "mark". В конце процесса получается новый стор, в котором лежат только актуальные объекты.

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

#statemanagement #performance #react

https://developers.soundcloud.com/blog/garbage-collection-in-redux-applications?ref=mdbootstrap.com

Сегодня в блоге v8 появилась вторая часть статьи про структуру спецификацию ECMAScript от Марьи Хёлтэ — "Understanding the ECMAScript spec, part 2".

В этой части Марья разбирает то, как в спецификации определён обход цепочки прототипов для получения значения свойства объекта. Объясняется всё в довольно доходчивой форме. Используя описанный подход, можно разобрать любую другую фичу языка на уровне спецификации. В статье дополнительно затрагивается понятие runtime semantics: грамматика спецификации определяет синтаксис языка, runtime semnatics определяет смысл этих синтаксических конструкций. В самом конце статьи есть ссылка на бонусную статью про то, почему obj.foo при передаче как аргумент, например, в console.log(obj.foo) становится AssignmentExpression.

Очень клёвая статья. Теперь жду третью часть.

#js #specification #tutorial

https://v8.dev/blog/understanding-ecmanoscript-part-2

Big news, everyone! Теперь вы можете поддержать канал на патреоне. Меня давно уже спрашивали про такую возможность, и вот вчера настроил страницу для пожертвований. Если вам нравится то, что я делаю, хотите продолжать читать канал без рекламы и хотите сделать что-то хорошее, то добро пожаловать в клуб патронов. Мне материальная поддержка, а вам большой плюс в карму.

Также ищу спонсора канала. Если вы представляете компанию и хотите проспонсировать канал, то пишите мне в личку @myshov. Все спонсорские плюшки (их много) перечислены на странице патреона.

В любом случае всем спасибо за то, что читаете канал!

#defront

https://www.patreon.com/myshov

Диего Гонзалес из команды разработки Samsung Internet рассказал про лучшие практики разработки веб сайтов для устройств с гнущимися экранами.

На данный момент по всему миру продано более одного миллиона Galaxy Fold. То есть девайсами с гнущимися экранами пользуются реальные люди. Самая большая проблема при разработке сайтов под такие устройства — доступное экранное пространство. Окно браузера в режиме многозадачности на Galaxy Fold может быть очень маленьким (229px x 187px). Диего рекомендует использовать отзывчивый дизайн с обязательной проверкой отображения в разных браузерах с маленькой шириной окна.

В статье есть упоминание полезной фичи Firefox Dev Tools — в режиме инспектора все элементы, у которых есть скролл, помечаются лейблом "scroll". Это удобно при фиксе проблем вёрстки, вызывающих двойной скролл на странице.

#mobile #ux #css

https://medium.com/samsung-internet-dev/current-web-on-galaxy-fold-ad12d7f57c26

Лукас Бомбак написал статью про то, как готовить частичную гидрацию для изоморфных приложений — "The case of partial hydration (with Next and Preact)".

Фронтенд-фреймворки, которые умеют рендерить приложение на сервере (React, Vue, Angular), должны гидрировать страницу (устанавливать обработчики событий на отрендеренную сервером вёрстку), чтобы она стала интерактивной. При таком подходе есть проблема — на клиент летит много ненужного кода, например, код неинтерактивных компонентов (заголовки, врезки, компоненты для типографики и т.п.). Поэтому команда Лукаса при работе над большим новостным порталом реализовала частичную гидрацию страницы. При таком подходе на клиент прилетает только тот код, который нужен для работы интерактивных элементов.

Идея несложная. Нужно отрендерить статичную вёрстку и отметить в ней элементы, которые нужно гидрировать. Для отметки таких элементов, ребята использовали тег <noscript type="application/hydration-marker" />. Далее клиентский скрипт находит такие элементы и гидрирует их. Таким образом на странице получается несколько независимых мини-приложений.

Статья очень полезная. Если вы разрабатываете большой проект с использованием SSR и большинство ваших компонентов неинтерактивны, то стоит обратить внимание на этот подход.

#ssr #performance #react

https://medium.com/@luke_schmuke/how-we-achieved-the-best-web-performance-with-partial-hydration-20fab9c808d5

Джеймс Снелл из команды разработки ядра Node.js написал статью про текущий статус поддержки QUIC в ноде — "A QUIC Update for Node.js".

QUIC — это транспортный протокол, который лежит в основе HTTP/3. Он решает проблему плохой утилизации канала связи в сетях с высокими задержками, ускоряет установку соединения между клиентом и сервером и решает другие проблемы. На данный момент в отдельном репозитории организации Node.js полным ходом идёт его внедрение.

Для работы с новым протоколом используется новый модуль quic; будет ли он доступен разработчикам в будущем, пока окончательно не решено. Этот модуль экспортирует одну функцию createServer, с помощью которой создаются как инстанс сервера, так и клиент. Под капотом используется библиотека ngtcp2, разрабатывающаяся рабочей группой, работающей над спецификацией QUIC.

Экспериментальная поддержка QUIC, доступная всем разработчикам, должна появиться в Node.js v14. Добавление полноценной поддержки протокола запланировано в Node.js v15.

#protocol #nodejs #net

https://www.nearform.com/blog/a-quic-update-for-node-js/
https://news.1rj.ru/str/defront/268

Зак Блум в блоге Cloudflare опубликовал статью про историю появления URL — "The History of the URL".

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

Первой сетью была ARPANET, но позже появились другие сети: COMSAT, CHAOSNET, UCLNET, INTELPOSTNET. Для того чтобы объединить их в одно целое, были разработаны протоколы интернета. Для адресации узлов новой сети существующее подход ARPANET не подходил. Список всех узлов сети хранился на центральном сервере в обычном файле. При каждом добавлении нового узла в сеть этот сервер должен был по ftp передавать всем узлам сети обновлённый файл. Решением было создание иерархической системы, в которой можно запрашивать только тот список узлов, который принадлежит определённому домену. Так появилось доменное имя.

Статья большая. В ней рассказывается про историю появления всех частей URL: протокол, порт, путь, параметры, якорь. Очень рекомендую почитать, если интересуетесь историей web'а.

#history #web

https://blog.cloudflare.com/the-history-of-the-url/

Пару дней назад в чате @defrontchat спросили про преимущества Styled Components. Я как фронтендер-пенсионер сказал, что не понимаю хайпа вокруг CSS-in-JS библиотек. И вот сегодня нашёл довольно хороший пост Санил Пая про преимущества CIJ-библиотек.

Стили, написанные с использованием CIJ можно проанализировать статически: если в имени класса есть опечатка TS/Flow про это скажут. При использовании CIJ-библиотек не надо волноваться про append-only стили. Удалил компонент — удалил стили. Контроль над селекторами делает простым извлечение критического CSS. Так как стили в CIJ это код, начинают работать оптимизации, использующиеся для JS (code splitting, dead code elimination). Ещё одно неочевидное преимущество касается того, что в SPA-приложениях, в которых используется асинхронная загрузка стилей и скриптов нельзя гарантировать порядок загрузки ассетов, что приводит к использованию !important.

The facebook codebase has thousands of !important statements, despite being written by competent engineers with solid engineering practices and deep relationships with design teams.

В общем, рекомендую почитать статью всем, у кого есть вопросы к CSS-in-JS. Многое встаёт на свои места.

#cssinjs #musings

https://gist.github.com/threepointone/731b0c47e78d8350ae4e105c1a83867d

Бенг Ю и Джонатан Империоси из Google рассказали, как добавление http-заголовка stale-while-revalidate повлияло на бизнес-метрики — "How Google improved ads performance with stale-while-revalidate".

Google Ad Manager для показа рекламы использует скрипт gpt.js. Этот скрипт находится в кеше браузера не более 15 минут. Как только проходит 15 минут запись в кеше устаревает и браузер делает синхронный запрос для получения свежей версиии gpt.js. В Chrome 75 появилась поддержка stale-while-revalidate. Команда разработки Ad Manager добавила к gpt.js http-заголовок

cache-control: private, max-age=900, stale-while-revalidate=3600

Он говорит о том, что если файл запрашивается между 15 и 60 минутами, после того как он попал в кеш, тогда будет использоваться устаревшая версия файла, но в фоне скрипт будет обновлён и закеширован для использования в будущем. Добавление заголовка ускорило начальную загрузку скрипта на 2% и на 0.5% увеличилио доход от показанной рекламы.

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

#performance #cache

https://web.dev/ads-case-study-stale-while-revalidate/

Чарльз Клермон опубликовал статью про влияние производительности на бизнес-метрики SPA-приложения — "The Impact of Web Performance".

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

Для измерения производительности пользователи были разделены на группы по разным категориям устройств. Для разделения пользователей по типу iPhone использовались значения device.screenResolution и device.mobileDeviceBranding (980x1000 это iPhone X/Xr). Измерялось количество отрендеренных браузером фреймов в течении первой секунды после клика (60 — отличный показатель, 0 — плохой).

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

#performance #mobile

https://simplified.dev/performance/impact-of-web-performance#ref-iphone-categories

Райан Аткинсон рассказал, почему он выбрал Svelte для большого проекта — "Why Svelte is our choice for a large web project in 2020".

В статье Райан рассказывает про объективные преимущества Svelte относительно других фреймворков (скорость работы, гибкость компилятора, встроенная поддержка создания производительных анимаций), так и субъективные (приятно работать, легко изучать, синтаксис и семантика). В недостатках усложнение процесса сборки (компилятор должен выполнять больше работы в отличии от компиляции JSX или Vue-компонентов), новый синтаксис для новичков, реактивный синтаксис работает только с компонентами, рендеринг блокирует основной поток. Ещё есть проблемы, вызванные молодостью проекта: скромная экосистема инструментов (плагины для редакторов, поддержка TypeScript), лучшие практики ещё не устоялись, молодая экосистема библиотек, с ростом количества компонентов может значительно вырасти объём бандла (решается с помощью code splitting), мало вакансий на сегодняшний день, на данный момент у проекта нет финансовой поддержки.

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

P.S. Спасибо @oleg_log за ссылку на статью.

#svelte

https://github.com/feltcoop/why-svelte