Defront — про фронтенд-разработку и не только

Валерий Карпов написал статью, посвящённую Symbol — "A Practical Guide to Symbols in JavaScript".

Symbol — это новый тип данных, который появился в ES2015. Символы могут использоваться в качестве ключа объекта. Они создаются с помощью функции Symbol() и Symbol.for(), которые принимают на вход стоку-описание.

При создании символов с помощью Symbol() они гарантировано будут разными. Благодаря этой особенности можно отчётливо разграничивать пользовательские и программные данные. Например, в ES2015 символ Symbol.iterator используется для задания функции, которая будет вызываться при использовании for...of. При создании такого итератора его никто не сможет изменить по ошибке. При использовании Symbol.for('name') создаваемый символ сохраняется в глобальный реестр и становится доступен из разных мест программы при повторном вызове Symbol.for('name').

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

#js #es2015

http://thecodebarbarian.com/a-practical-guide-to-symbols-in-javascript.html

В блоге WebKit появилась статья про проблему повышенного энергопотребления web-контентом — "How Web Content Can Affect Power Usage".

Повышенное энергопотребление очень критично для мобильных устройств. Основные потребители энергии — экран, CPU, GPU и сеть. Экран потребляет энергию предсказуемо, чего нельзя сказать про CPU, GPU и сеть. Энергопотребление CPU, GPU и сети напрямую зависят от текущей выполняемой задачи (парсинг страницы, рендеринг, выполнение JavaScript).

Когда страница переходит в неактивный режим (переключение на другую вкладку) браузеры могут приостановить выполняемый на странице код. В Safari на iOS работа внутри вкладки при первой возможности полностью останавливается. Тем не менее такие "замороженные" вкладки могут вызывать потребление CPU, если на странице работают таймеры, установленные с помощью setTimeout и setInterval или происходит работа с сетью. С помощью Page Visibility API и события blur можно отслеживать, когда страница перестаёт быть видимой или становится неактивной и, например, ставить на паузу обновление UI или отключать анимации.

Статья хорошая. Она рассказывает про особенности работы WebKit на Apple-устройствах, но тем не менее большая часть статьи актуальна для всех браузеров.

#webkit #mobile

https://webkit.org/blog/8970/how-web-content-can-affect-power-usage/

Недавно в блоге v8 Бенедикт Мойрер и Матиас Байненс написали пост про расследование причин деградации производительности в React — "The story of a V8 performance cliff in React".

В декабре прошлого года разработчики React столкнулись со странным поведением v8. Если было запущено профилирование, то падала производительность кода во время фазы commit. Как оказалось, проблема заключалась в следующем коде:

class FiberNode {
  constructor() {
    this.actualStartTime = 0;
    Object.preventExtensions(this);
  }
}

const node1 = new FiberNode();
const node2 = new FiberNode();

V8 внутри использует разные представления для чисел. Для 32-битных целых чисел используется small integer (Smi), для чисел с плавающей запятой — HeapNumber и MutableHeapNumber. Для создаваемых объектов v8 применяет оптимизации для снижения потребления памяти. Одна из таких оптимизаций гарантирует эффективное переиспользование памяти, если создаются похожие друг на друга объекты.

В коде класса FiberNode, который работал во время профилирования, значение поля объекта, на котором был применён preventExtensions, менялось со Smi на HeapNumber. Этот кейс не был учён в v8, и движок начинал аллоцировать дополнительную память. Видимая просадка производительности происходила из-за того, что в реальном React-приложении создаётся десятки тысяч объектов такого типа.

Баг был исправлен в v8, но разработчики React смогли устранить проблему раньше на своей стороне. Для этого они стали инициализировать поле объекта HeapNumber'ом (this.actualStartTime = NaN). В конце статьи Бенедикт и Матиас рекомендуют инициализировать поля объекта такими значениями, внутреннее представление которых не будет меняться со временем.

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

#v8 #internals #performance

https://v8.dev/blog/react-cliff

Вчера вышла новая версия TypeScript. Команда разработчиков рассказала о том, что появилось нового в этом релизе — "Announcing TypeScript 3.6".

Были переработаны типы Iterator и IteratorResult. Улучшена типизация генераторов. Теперь для них есть выделенный тип Generator. Его появление позволяет статически определять возвращаемый тип, yield-тип, и тип, который может принимать next.

Появилась поддержка хелпера __spreadArrays для более корректного представления результата преобразования spread-оператора. Улучшили подсказки при работе с промисами: теперь TS может подсказать про забытый await. Улучшили поддержку Unicode-символов в идентификаторах. get и set теперь разрешено использовать в ambient contexts (declare и d.ts-файлы). Декларирование функций-классов, которые инстанцируют объекты с оператором new и обычным вызовом, теперь более интуитивно — ambient классы и функции могут сливаться.

Улучшили тулинг. Теперь TS понимает тип модульной системы при автоматическом импорте. Не вставляет точки с запятыми в тех файлах, где они не используются. Было добавлено новое API для инкрементальной сборки, что позволит сборщикам и таск-раннерам использовать результаты предыдущей сборки, ускоряя сборку проекта. Был переделан playground — теперь на сайте используется форк популярного плейграунда Артёма Тюрина.

#typescript #release

https://devblogs.microsoft.com/typescript/announcing-typescript-3-6/

Упоминание iframe часто вызывает негативные ассоциации с рекламой и отслеживанием пользователей. И это плохо, потому что те возможности, которые они предоставляют, могут быть полезны при разработке web-приложений. Дениэл Брайн из PayPal написал статью с мыслями о том, как разработчики браузеров могут улучшить iframe — "Iframes are just terrible. Here’s how they could be better".

PayPal для обхода ограничений iframe создал библиотеку zoid, с помощью которой можно облегчить работу при создании кросс-доменных компонентов. Но эта библиотека не решает и не решит всех проблем. Например, угон кликов (clickjacking), может быть предотвращён только на уровне браузеров, если в них будет реализована проверка прозрачности iframe и обнаружение перекрытых элементов. Также сейчас невозможно без использования инструментов разработчика определить ресурс, который отображается внутри в iframe. С точки зрения безопасности пользователей это большая проблема. Ещё в статье затрагивается сложность получения ссылки на объект window, проблемы при работе с cookie и низкий приоритет загрузки содержимого.

Статью прочитать стоит, если вам интересно узнать про ограничения использования iframe в современном web'е.

#musgins #web

https://medium.com/@bluepnume/iframes-are-just-terrible-heres-how-they-could-be-better-974b731f0fb4

Фараз Келини написал хорошую статью про BigInt — предложение добавления в стандарт JavaScript — "The Essential Guide To JavaScript’s Newest Data Type: BigInt".

BigInt — новый тип в языке. Его планируют добавить в стандарт из-за того, что размерности Number недостаточно, если необходимо работать с большими числами. Если Number выходит за пределы Number.MAX_SAFE_INTEGER и Number.MIN_SAFE_INTEGER, то число округляется, приводя к багам в программе. Например, 9007199254740992 === 9007199254740993 будет true.

BigInt-числа выглядят как обычные, но с суффиксом n в конце — 10000n. В арифметических выражениях BigInt и Number, нельзя смешивать между собой (будет TypeError ), так как возникает дихотомия в интерпретации результата. Если хочется использовать разные типы в одном выражении, то их надо привести явно к одному типу: 1000n + BigInt(1). При сравнении чисел BigInt и Number нельзя использовать строгое сравнение, так как это разные типы ( 10n === 10 // false ), но можно использовать нестрогое.

На данный момент пропозал BigInt находится на stage 3. Его поддержка есть в Chrome, Firefox и последней версии Edge. Создать полноценный полифилл для BigInt невозможно, поэтому в статье предлагается использовать библиотеку JSBI для поддержки старых версий браузеров.

В общем, рекомендую почитать статью. Скорее всего BigInt попадёт в следующую версию стандарта.

#js #proposal

https://www.smashingmagazine.com/2019/07/essential-guide-javascript-newest-data-type-bigint/

Филип Уолтон написал про свою идею использования нативных модулей в качестве выходного формата бандла — "Using Native JavaScript Modules in Production Today".

На данный момент самый популярный бандлер Webpack не поддерживает нативные модули в качестве выходного формата. Если вы посмотрите внутрь бандла, то увидите вместе с кодом модуля бойлерплейт-код для его инициализации. У менее популярного бандлера Rollup есть поддержка esm в качестве выходного формата. Использование нативных модулей даёт несколько преимуществ: выходной бандл получается меньше в объёме и нативные модули можно эффективно загружать с помощью хинта modulepreload (только в Chrome).

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

#performance #rollup #esm

https://philipwalton.com/articles/using-native-javascript-modules-in-production-today/

Сегодня меня занесло в 2015-ый год. Прочитал статью Джека Арчибальда про старые баги браузеров с планированием микрозадач — "Tasks, microtasks, queues and schedules".

Если выполнить такой код:

console.log('script start');
setTimeout(() => console.log('setTimeout'), 0);
Promise.resolve().then(() => console.log('promise'));
console.log('script end');

то в консоль будет выведено: "script start", "script end", "promise", "setTimeout". Такой порядок объясняется тем, что очередь микрозадач (куда попадают выполнение коллбеков MutationObserver и коллбеки промисов) опустошается до выполнения следующей задачи, которая в данном случае создаётся с помощью setTimeout.

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

Проверил примеры — браузеры уже пофиксили описанные проблемы. Но всё равно рекомендую почитать статью, если она прошла мимо вас.

#async #history

https://jakearchibald.com/2015/tasks-microtasks-queues-and-schedules/

Tproger вчера запостил (https://t.me/tproger_web/193) awesome-список, посвящённый мобильной web-разработке, который я веду больше года. Там есть разные статьи, книги и инструменты, которые могут помочь в создании быстрого mobile-friendly сайта. Рекомендую посмотреть подборку всем web-разработчикам, так как пользователей интернета сейчас больше всего именно на мобильных платформах.

#mobile #list

https://github.com/myshov/awesome-mobile-web-development

Лин Кларк на Mozilla Hacks опубликовала большую статью, посвящённую новому пропозалу в WebAssembly — "WebAssembly Interface Types: Interoperate with All the Things!"

На данный момент WebAssembly без использования glue-кода может общаться с внешним миром только числами (значения, смещения, адреса). Пропозал "WebAssembly Interface Types" позволит работать со сложными типами напрямую (строки, объекты, структуры и т.п.) Это открывает двери таким возможностям как работа с Web API непосредственно из WebAssembly без привлечения JavaScript, общение wasm-модулей, скомпилированных из разных языков, между собой, использование одного и того же модуля без перекомпиляции в совершенно разных окружениях, например, Node.js, Python, WASI-рантаймах и т.п.

В статье очень детально разбирается, как это всё работает. От описания высокоуровневой проблемы до примеров реализации того, как будут представлены интерфейсные типы в коде wasm-модулей. Экспериментальная поддержка предложения есть в рантайме Wasmtime, Rust-тулчейне и wasm-bindgen.

Что сказать... очень крутая новость. Пойду ещё разок задоначу в Mozilla Foundation.

#webassembly #proposal

https://hacks.mozilla.org/2019/08/webassembly-interface-types/

Прочитал интересную историю переезда с Angular на Preact от Джорджа Фу — "Optimizing for the mobile web: Moving from Angular to Preact".

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

Команда решила, что с этим надо что-то делать и для начала избавилась от больших библиотек: moment, lodash и core-js. После этого начался перевод листовых Angular-компонентов. Для интеропа с ангуляром был использован специальный компонент "angular-preact-bridge". Это позволило не останавливать разработку и переводить проект на Preact постепенно. В процессе переезда им очень помогал TypeScript. После всей работы (в статье не говорится о количестве затраченного времени, но у них был дедлайн в 4 месяца), размер приложения уменьшился в два раза, время загрузки снизилось до 3-4 секунд.

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

#jsframeworks #experience #migration

https://bytes.grubhub.com/optimizing-for-the-mobile-web-moving-from-angular-to-preact-f09ca61ea27c#8f83

В бете Chrome 77 за экспериментальным флагом #native-file-system-api появилась поддержка Native File System API.

С помощью этого API можно создавать приложения, которые имеют прямой доступ на чтение и запись файлов, например, полноценный текстовый или графический редактор, IDE и т.п. Много внимания уделяется безопасности нового API. Оно будет доступно только на тех сайтах, которые работают по https. Открытие окна выбора файлов возможно только со стороны пользователя, то есть программно вызвать это окно нельзя. Тем не менее появление доступа к файловой системе открывает новые возможности для атак на данные пользователей.

Native File System API является частью проекта capabilities, цель которого сделать возможным разработку таких типов web-приложений, которые доступны только на нативных платформах. Интересно наблюдать, как браузер постепенно превращается в полноценную платформу для запуска серьёзных приложений.

#future #chrome #experimental

https://developers.google.com/web/updates/2019/08/native-file-system

Вчера вышла новая версия Node.js 12.9.0.

В новом релизе V8 был обновлён до версии 7.6. С новой версией движка в Node.js появилась поддержка Promise.allSettled, улучшена поддержка BigInt, ускорена работа JSON.parse().

В модуле fs были добавлены fs.writev, fs.writevSync и filehandle.writev, с помощью которых можно записывать в файл массив buffer'ов. Этот API будет полезен при оптимизации записи файлов на диск.

В модуле crypto появилась новая опция oaepHash для асимметричного шифрования, с помощью которой можно указать хэш-функцию при использовании optimal asymmetric encryption padding (OAEP).

В модуле http были добавлены недостающие "streamlike" свойства к OutgoingMessage.prototype: writableObjectMode, writableLength и writableHighWaterMark. В модуле stream добавлены новые свойства readableEnded и writableEnded, которые показывают текущее состояние завершения чтения или записи стрима.

#release #nodejs

https://nodejs.org/en/blog/release/v12.9.0/

Иногда заполнение и отправка web-формы превращается в проблему: например, непонятно, к какому полю относится лейбл или сообщение валидации говорит, что есть ошибка, но не говорит, где именно и т.п. Адам Силвер написал статью о том, чего лучше всего избегать при проектировании форм и чего стоит придерживаться — "Form design: from zero to hero all in one blog post".

Вот несколько интересных моментов. Следует избегать форм с многоколоночной раскладкой, так как более 10% пользователей, не могут заполнить такие формы правильно. В поля ввода, которые отвечают за ввод грамматически неправильных данных (например, email'ов), следует добавить атрибуты autocapitalize="none", autocorrect="off" и spellcheck="false", чтобы браузер автоматически не изменял вводимые данные. Используйте <select> только в самой безвыходной ситуации, потому что им неудобно пользоваться. Вместо него лучше всего использовать radio-кнопки или <select> с автодополнением для очень большого списка опций.

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

#ux #forms

https://adamsilver.io/articles/form-design-from-zero-to-hero-all-in-one-blog-post/

После прочтения статьи "Responsible JavaScript" я рефлексировал на тему того, что было бы здорово иметь такой источник информации, в котором бы детально разбирались типы рендеринга и то как они влияют на метрики производительности web-приложений. Сегодня увидел твит от Эдди Османи, в котором он поделился ссылкой на статью, посвящённой этой теме — "Rendering on the Web".

В статье разбираются все виды рендеринга страниц: Server Rendering, SSR, SSR with Rehydration, CSR with Prerendering, Full CSR. Даётся оценка того, как они влияют на метрики приложения и даются советы, в каком случае лучше использовать тот или иной подход. Например, авторы статьи не рекомендуют использовать SSR с гидрированием, так как метрики производительности, собранные с реальных сайтов, использующих этот подход, говорят не в его пользу. Из статьи я впервые узнал про "Trisomorphic Rendering". Это такой подход, когда для рендеринга страниц используются сервис воркеры.

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

#performance #web #rendering

https://developers.google.com/web/updates/2019/02/rendering-on-the-web#top_of_page

Деструктуризация — удобное средство для доступа к свойствам объектов и элементам массивов, но оно не ограничивается только этими сценариями. Дмитрий Павлютин написал статью с описанием неочивидных подходов с использованием этой фичи — "5 Interesting Uses of JavaScript Destructuring".

1. С помощью деструктуризации можно обменивать значения переменных таким же образом, как это можно сделать в python: [a, b] = [b, a];.
2. Можно легко получить первый элемент массива с подстановкой дефолтного значения, если этого элемента нет: const [firstColor = 'white'] = colors;.
3. Комбинируя деструктуризацию с rest-оператором, можно отбросить первый элемент массива: const [, ...lastNumbers] = numbers;.
4. Деструктуризация работает для всех объектов, которые имплементируют протокол итерирования (строки, массивы, Map, Set). Например, таким образом можно получить первую букву в строке: const [firstChar] = 'cheese';.
5. Используя динамические свойства объектов, можно получить заранее неизвестное свойство объекта: const { [nameProp]: name = 'Unknown' } = obj;.

Я пересказал содержимое всей статьи, но всё равно в ней есть более развёрнутые примеры. Советую посмотреть.

https://dmitripavlutin.com/5-interesting-uses-javascript-destructuring/

#js #es2015 #list

Пару недель назад количество подписчиков Defront перевалило за тысячу. Хочу сказать вам спасибо, за то что читаете и пишете в личку, если видите какую-то неточность или опечатки. И хочу сказать спасибо всем каналам, которые меня поддерживают или из которых я черпаю информацию для канала:

@juliarderity — информация из первых рук про новинки в web-стандартах, рекапы встреч комитета TC39 и многое другое (Сергей Рубанов — создатель канала — участвует в разработке стандарта ECMAScript)
@oleg_log — отличный канал Олега Ковалёва, в котором он делится своим богатым опытом разработки. Пишет про Go, DevOps, бэкенды и всё что с ними связано, не избегает тем про JavaScript
@webstandards_ru — один из самых известных телеграм-каналов, посвящённых web-разработке, который ведёт Вадим Макеев
@forwebdev — канал Андрея Романова, в котором публикуются ссылки на полезные статьи и инструменты, у автора есть личный блог в tg, на который я тоже подписан — @andrew_r_notes
@breakfastjs — подборки статей из мира фронтенд-разработки от Дмитрия Мананникова
@iamakulov_channel — заметки от Ивана Акулова про производительность в web'е и другая годнота
@smart_dev — канал с ссылками на интересные статьи, авторские переводы
@amorgunov — канал моего коллеги из Яндекса — Александра Моргунова, пишет про JS и жизнь
@ufostation — канал Сергея Ufocoder про фронтенд и фп
@jabascript — хороший телеграм-блог Виктора Турского
@we_use_js — канал, с хорошими ссылкам на статьи, новые инструменты и т.п.
@tproger_web — канал про web-разработку проекта tproger

Партрик Вентузело — независимый эксперт в области ИБ — опубликовал статью про анализ WebAssembly модуля Google Keep — "Analysis of Google Keep WebAssembly module​".

Сначала Патрик пытался выяснить, за что отвечает загружаемый WebAssembly модуль. Для этого он извлёк информацию о сборке. В ней содержались сведения о wasm-тулчейне (emscripten-wasm), использованной системе сборки (Bazel), имя сервера и путь до результата сборки. Название "sketchology", которое находилось в пути, дало подсказку о том, что модуль отвечает за создание векторных изображений в заметках Google Keep.

Далее в статье рассказывается, какую ещё информацию можно достать из модуля. Например, в секции данных модуля находились бинарные данные protobuf. Их можно проанализировать с помощью protobuf-inspector. В той же секции находились абсолютные пути скомпилированных файлов, сообщения об ошибках, имена функций и констант. С помощью этой информации можно восстановить дерево скомпилированного проекта. При большом количестве времени и упорстве возможно декомпилировать wasm-модуль в C-код.

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

#webassembly #security #re

https://webassembly-security.com/google-keep-webassembly-module-analysis/

Два дня назад Матиас Байненс в блоге v8 написал статью про пропозал "Subsume JSON a.k.a. JSON ⊂ ECMAScript".

"Subsume JSON" делает JSON полноценным подмножеством JavaScript. Раньше строковые литералы не могли содержать незаэскейпленные символы U+2028 LINE SEPARATOR и U+2029 PARAGRAPH SEPARATOR. Их присутствие приводило к SyntaxError. Это проблема, потому что JSON может их содержать. Чтобы в коде ничего не взорвалось, надо было писать дополнительную пост-обработку вставляемого в скрипт результата работы JSON.stringify(). Новая фича избавила разработчиков от этого неудобства.

Но от пост-обработки нельзя отказаться в том случае, когда происходит сериализация пользовательских данных, которые вставляются на страницу. В статье есть пример XSS-атаки, в которой используется символ U+2028.

Subsume JSON уже попал в последнюю версию стандарта — ES2019. Поддержка новой фичи есть во всех актуальных версиях браузеров.

#js #unicode #security #es2019

https://v8.dev/features/subsume-json

Я никогда не задумывался о том, как работает двухфакторная аутентификация. Когда мы сканируем QR-код в 2FA приложении и видим одноразовый пароль или получаем его в смс, под капотом работают алгоритмы, описанные в RFC6238 и RFC4226. Александр Ховановский разобрался со всем этим и опубликовал на хабре статью про OTP (one time password) — "Генерируем одноразовые пароли для 2FA в JS с помощью Web Crypto API".

Существуют два вида одноразовых паролей: HMAC-based One Time Password (HTOP) и Time-based OTP (TOTP). HMAC расшифровывается как Hash-based Message Authentication Code. В нём используется счётчик, который должен синхронизироваться между клиентом и сервером. В Time-based OTP счётчиком выступает интервал времени. Он получается делением Unix-времени на окно валидности пароля (обычно это знакомые нам 30 секунд). Затем происходит процесс преобразования исходных данных в одноразовый пароль с участием алгоритма SHA-1 (использовался Web Crypto API).

Статья хорошая. С большим количеством примеров и кода. Хочу перечитать её ещё разок и написать свою реализацию просто ради интереса.

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

#js #cryptography #security