Пару недель назад была большая новость о том, что в Chrome 74 в экспериментальном режиме включили поддержку built-in модуля для нового асинхронного key-value хранилища:

import {storage, StorageArea} from 'std:kv-storage';

Новое API разрабатывается с прицелом на то, чтобы улучшить developer experience при работе с данными в браузере. Проблема в том, что нативное API IndexedDB не очень тривиально, а localStorage из-за синхронного API, который блокирует главный поток, влияет на производительность приложения.

kv-storage – первая ласточка в будущем наборе built-in модулей. Основное преимущество API, поставляемых с помощью встроенных модулей, (они начинаются с префикса std:) – снижение потребления ресурсов системы. Браузеру в этом случае не надо загружать в память API, чтобы предоставить к нему доступ через глобальный скоуп.

Для использования новой фичи в тех браузерах, которые её не поддерживают, разработчики Google предлагают использовать progressive enhancement подход с использованием ещё одной экспериментальной фичи – import maps и полифилла для kv-storage.

#builtinmodule #kvstorage #chrome #future

https://developers.google.com/web/updates/2019/03/kv-storage

Гириш Пунтахил из IBM опубликовал статью "Easily identify problems in Node.js applications with Diagnostic Report", посвящённую новой экспериментальной функции в Node.js v11.8 – Diagnostic Report.

На самом деле эта фича существовала и раньше как отдельный пакет (`npm i node-report`). Команда Node.js решила поставлять её как часть дистрибутива, потому что это незаменимый инструмент при диагностике проблем: утечек памяти, повышенного потребления CPU, крэшей и т.п.

Diagnostic Report генерирует отчёт в виде JSON'а. В отчёте содержится исчерпывающая информация об окружении, в котором было запущено приложение, и обо всех интересующих аномалиях, если запустить node с соответствующими флагами. В статье есть несколько примеров того, как работать с этим инструментом и интерпретировать его результат.

Я считаю, что Diagnostic Report полезная фича, но попадёт ли она в стабильный релиз, пока неизвестно.

#nodejs #troubleshooting #experimental

https://developer.ibm.com/articles/easily-identify-problems-in-your-nodejs-apps-with-diagnostic-report/

Николас Закас – автор нескольких книг по JS и оригинальный автор eslint – в январе написал статью про то, почему он решил не использовать дефолтные экспорты в своих модулях. Статья называется "Why I've stopped exporting defaults from my JavaScript modules".

Для меня самое полезное в статье (как это ни странно) не причины, из-за которых автор отказался от дефолтных экспортов, а принципы, которыми он руководствуется при разработке и которые ценно вспоминать время от времени:
1. явное лучше неявного;
2. имена должны быть консистентны во всех файлах;
3. выкидывайте исключений как можно раньше и чаще;
4. меньшее количество решений - более быстрая разработка;
5. необходимость переключать контекст (side trips) замедляет разработку;
6. избыточная когнитивная нагрузка замедляет разработку.

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

#javanoscript #modules #esm #musings

https://humanwhocodes.com/blog/2019/01/stop-using-default-exports-javanoscript-module/

Послушал подкаст с Ричардом Фельдманом (автор книги “Elm in Action” и директор по технологиям NoRedInk), в котором он рассказал про общее положение дел в мире Elm.

Последняя версия языка 0.19 вышла в августе 2018 года. В этой версии был переписан компилятор, что драматически снизило время сборки проекта. Так же при переписывании компилятора упор делался на таком коде, который будет эффективно сжиматься uglify.js и Google Closure Compiler.

Ведущие подкаста задали вопрос про потенциальную опасность для проекта, если Эван Чаплицкий (создатель языка и основной разработчик компилятора) перегорит и бросит всё. Ричард ответил, что для Эвана сложнее всего работать не с кодом, а с сообществом, поэтому они в NoRedInk ему с этим очень сильно помогают. И если всё-таки случится так, что Эван захочет уйти работать на ферму выращивать бобы, то это будет очень большая потеря для проекта.

Ещё Ричарда спросили про то, когда выйдет Elm 1.0. Он ответил, что в будущем ожидаются мажорные изменения языка, которые будут ломать совместимость с предыдущими версиями, поэтому в ближайшее время не планируется выпуск версии 1.0. Разработчики Elm не хотят идти по пути Angular, который кардинально изменил подход к разработке приложений при переходе с первой на вторую версию. Для Elm выпуск версии 1.0 будет означать то, что мажорных изменений в языке не будет очень долго. При этом текущая версия 0.19 является production-ready. На данный момент в NoRedInk весь фронтенд (300 тысяч строк кода) написан на Elm.

#elm #podcast #interview

https://dev.to/jsjabber/jsj-354-elm-with-richard-feldman

Пару дней назад Эрик Мейер написал небольшую статью про восьмичисленные шестнадцатиричные коды цветов "Color Me FACE1E55".

Исторически шестнадцатиричные коды, которые похожи на обычные английские слова (DEADBEEF, DEAD10CC и т.п.), использовались (и используются), например, для обозначения определённых участков памяти или типов исключений в отчётах об ошибках. Эрик в статье приводит примеры того, каким цветам соответствуют эти коды и ещё до кучи придумывает парочку своих.

Новый формат цветов описывается в стандарте CSS Color Module Level 4 – его формат #RRGGBBAA. Два последних числа – это альфа-канал. Его значениям соответствуют числа от 00 для полностью прозрачного цвета до FF для непрозрачного. Ещё существует сокращённая запись таких цветов - #RGBA, то есть теперь можно раскрашивать div'ы в цвет #CAFE или #F00D.

Восьмичисленные цвета поддерживается уже во всех современных браузерах, кроме IE/Edge.

#css #colors

https://meyerweb.com/eric/thoughts/2019/04/01/color-me-face1e55/

Вчера Эдди Османи из Google написал в своём блоге про новый экспериментальный атрибут для ленивой загрузки изображений и iframe'ов – loading.

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

Раньше задачу отложенной загрузки можно было решить только с помощью JavaScript, например, используя библиотеку lazysizes. Сейчас в Chrome 73 с помощью флага можно включить поддержку нового атрибута loading. У атрибута есть три возможных значения: lazy (ленивая загрузка), eager (загрузка изображения сразу же), auto (будет ли изображение загружаться лениво, решает браузер):

<img src="img1.jpg" loading="lazy" />
<img src="img2.jpg" loading="eager" />
<img src="img3.jpg" loading="auto" />

Loading – это экспериментальный атрибут, стандарт которого находится на стадии черновика. Поддержка loading без флага должна появиться в Chrome 75.

#html #lazy #future #chrome

https://addyosmani.com/blog/lazy-loading/

Сейчас занимаюсь написанием документации про юнит-тесты в Яндекс Маркете. Искал подходящие статьи по теме и наткнулся на очень большой блог-пост Виталия Зайдмана "An Overview of JavaScript Testing in 2019", в котором он рассматривает инструменты для всех видов тестирования в JavaScript.

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

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

#testing #js #overview

https://medium.com/welldone-software/an-overview-of-javanoscript-testing-in-2019-264e19514d0a

Вчера в блоге v8 в статье "Code caching for JavaScript developers" Лесджек Свирски рассказал про то, как работает кэширование кода на уровне JS-движка.

Есть два подхода к кэшированию кода в v8:
1. Isolate кэш, который находится в памяти в рамках одного процесса (вкладки браузера).
2. On-disk кэш, в котором находится скомпилированный код, использующийся разными вкладками.

Если скомпилированный JS-код находится в кэше, браузер не тратит время на повторную компиляцию. Это хорошо сказывается на времени запуска приложения. Поэтому Лесджек советует делать всё возможное, чтобы файлы менялись как можно реже, не менять url, по которым они доступны (url используется в качестве ключа для хэша, в котором лежит скомпилированный код) и отдавать 304-ый код для скриптов, которые не были изменены.

При этом можно сделать так, чтобы определённый код попал в кэш. Например, файлы меньше 1kb не попадают в кэш, поэтому можно объединить несколько таких файлов в один бандл. Также можно позаботиться о том, чтобы кэш не инвалидировался лишний раз и вынести весь библиотечный код в один бандл, а бизнес-логику в другой. Есть и другие трюки, например, с сервис воркерами, но при этом не гарантируется, что эвристика, определяющая необходимость в кэшировании, будет стабильна и что перечисленные хаки из статьи будут работать в будущем.

#v8 #performance

https://v8.dev/blog/code-caching-for-devs

Сегодня прочитал статью Дрю Маклиллана в Smashing Magazine "Understanding Subresource Integrity".

Вы скорее всего видели, что на cdnjs и подобных сайтах при копировании ссылки на скрипт, можно скопировать тег <noscript> с атрибутом integrity. В этом атрибуте находится хэш исходного кода скрипта. Перед тем как выполнить скрипт браузер подсчитывает его хэш и сверяет с тем хэшом, который записан в атрибуте integrity. Если они не совпадают, то скрипт не будет выполнен. Таким образом браузер защищает сайты, использующие скрипты с общедоступных cdn, от компрометации скриптов, которые раздаются этими cdn. Этот механизм называется Subresource Integrity (SRI).

Подобный механизм можно использовать и для тех скриптов, которые хостятся на ваших серверах. Это добавляет ещё один уровень защиты от потенциальных атак. Для добавления хэшей к вашим скриптам можно воспользоваться webpage-subresource-integrity (для Webpack) или gulp-sri-hash (для gulp). Или в крайнем случае можно запустить команду:

cat FILENAME.js | openssl dgst -sha384 -binary | openssl base64 -A

и вставить полученный хеш в html-страницу руками. Subresource Integrity проверку точно также можно добавить и к CSS-файлам.

По-большому счёту я только что пересказал вам всю статью, так что можете её не читать.

#security #cdn #sri

https://www.smashingmagazine.com/2019/04/understanding-subresource-integrity/

Тай Люис из Lucidchart написал хорошую статью про base64 "Base64 Encoding: A Visual Explanation".

На сегодняшний день base64 используется при внедрении ресурсов в страницы с помощью протокола data:, в source map'ах и там, где необходимо передавать бинарные данные по текстовому протоколу.

В статье описывается работа алгоритма base64 с хорошей визуализацией. В цикле верхнего уровня входной поток данных делится на группы по 24 бита (input groups), которые обрабатываются вложенным циклом. Во вложенном цикле каждая входная группа бьётся на группы по 6 битов. Каждой комбинации битов соответсвует определённый символ, которым кодируется полученная группа. При необходимости во внешнем цикле input group искусственно расширяется до 24 битов с помощью символа =. Именно поэтому в конце base64 последовательности данных можно часто видеть =.

В статье Тай рассказал ещё про пасхалку в Chrome, про которую я не знал. Если ввести в адресную строку chrome://dino, то во весь вьюпорт браузера запустится игра с динозавром, которая доступна в обычном режиме тогда, когда нет доступа к сети (не забудьте нажать пробел). Эта игра хранит все свои ресурсы: изображение и звуки — в base64.

#base64 #algorithm #egg

https://www.lucidchart.com/techblog/2017/10/23/base64-encoding-a-visual-explanation/

Джеймс Лонг — создатель Prettier — два года назад написал хорошую статью про то, что помогло ему в карьере программиста "How I Became a Better Programmer".

- Ищите людей, которые вас вдохновляют, но не идеализируйте их
- Цените то, что вы создаёте
- Не стоит работать круглыми сутками
- Игнорируйте "мишуру" и фокусируйтесь на фундаментальных концепциях и знаниях
- Прежде чем реализовывать свою идею проведите исследование
- Беритесь за большие проекты и выходите из зоны комфорта. В этом разделе ещё перечисляется то, что можно сделать: изучите C, напишите компилятор, изучите макросы, прочитайте SICP, разберитесь в continuations, пробуйте новые языки программирования.

В начале статьи Джеймс говорит про то, что перечисленный список — это всего лишь его мнение и то, что работало для него, может не работать для других. Ищите свой путь. Не сомневайтесь в себе и продолжайте творить.

#musings #career #programming

https://jlongster.com/How-I-Became-Better-Programmer

Сегодня прочитал статью 2012 года Люка Вагнера "Optimizing JavaScript variable access". В статье Люк написал про то, каким образом он оптимизировал доступ к переменным в SpiderMonkey (js-движок в Firefox).

Начинается статья с описания оптимизации наихудшего случая, когда скоуп расширяется в рантайме с помощью eval. Поиск значения переменной в этом случае осуществляется с помощью итеративного алгоритма, к которому применяется те же техники оптимизации, которые используются при получении свойства объекта. Затем разбирается быстрый доступ к локальным переменным. В этом случае доступ оптимизируется очень хорошо, так как запись или получение значения из стека сводится к одной команде CPU. Последним пунктом разбирается быстрый доступ к нелокальным переменным. В этом случае не нужно поддерживать динамический хэш как в первом примере, так как вся информация о переменных уже доступна во время запуска js-кода и код может быть скомплирован JIT-компилятором.

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

#spidermonkey #optimization #js

https://blog.mozilla.org/luke/2012/10/02/optimizing-javanoscript-variable-access/

Сегодня нашёл в твиттере хороший доклад Андерса Хайлсберга (основной автор TypeScript) "TypeScript: Static types for JavaScript".

В 2010 году, перед тем как принять решение о создании нового языка, разработчики хотели открыть исходный код инструмента ScriptSharp, который переводил исходный код из C# в JS и который уже использовался командой Outlook.com. Но в итоге решили пойти другим путём и создать новый язык, который бы устранял ошибки в JavaScript и добавлял новые фичи, которых не хватало в JS (типы, классы, декораторы и т.п.). Так появился TypeScript.

В докладе Андерс рассказывает про разные возможности TypeScript. Объясняет, почему они ограничили вывод типов локально. Это было сделали из-за неявности, которую могут нести системы типов с нелокальным выводом типов. Больше про вывод типов Андерс не рассказывал, но мне хотелось бы услышать про эту фичу побольше. В самом конце рассказывает про то, как в обычном JS можно улучшить себе жизнь, используя тулинг TypeScript. Например, VSCode подтягивает файлы определений типов для библиотек и таким образом для них начинает работать автодополнение. Ещё в любой JS-файл можно добавить комментарий // @ts-check и TypeScript будет подсвечивать ошибки при неправильном использовании функций или если в коде есть опечатки.

В общем, доклад не хардкорный, но хороший, советую посмотреть.

#typenoscript #talk

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

На прошлой неделе разработчики Edge написали пост про грядущие изменения в браузере после перехода на кодовую базу Chromium – "What to expect in the new Microsoft Edge Insider Channels".

В статье рассказывается, над чем в первую очередь будет идти работа. Команда Edge хочет уделить много внимания доступности Chromium: запланирована поддержка новых API, будут работать над high-contrast CSS Media query, реализуют возможность удобной работы с браузером с помощью клавиатуры. Начиная с версии Chromium 73 вместе с Google работают над поддержкой архитектуры ARM64. Ещё планируют улучшить прокрутку и юзабилити при работе на тач-устройствах. Продолжают работать над стандартами. Запланировали реализовать предложение HTML Modules. UA-string нового браузера будет включает токен "Edg":

Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/74.0.3729.48 Safari/537.36 Edg/74.1.96.24

На данный момент для Windows 10 доступна Canary-версия и Developer-версия. Developer-версия более стабильна. В будущем новый Edge будет доступен на Windows 7, Windows 8.1 и macOS.

#chromium #edge

https://blogs.windows.com/msedgedev/2019/04/08/microsoft-edge-preview-channel-details/

В прошлый вторник Владимир Клепов из Яндекс.Почты написал хороший пост про то как они адаптируют письма к тёмной теме – "Как создать тёмную тему и не навредить. Опыт команды Яндекс.Почты".

В статье рассматриваются три подхода:
1. Переопределение стилей. Самый простой и понятный подход, но с большим недостатком – все красивости в письме пропадают.
2. CSS-фильтр с инвертированием цветов. Находчивое решение, но у него очень большие проблемы с производительностью.
3. Преобразование стилей. Этот метод и используется в почте. Он гораздо сложнее в реализации, но результат самый лучший. Его суть заключается в том, что в динамике проверяются все значения цветов в формате HSL. Если яркость (L) выше (для текста) или ниже (для фона) порога, то ничего не меняется, так как письмо и так уже в нужной цветовой палитре. Если это условие неверно, то проводится адаптация цвета (h, s, l) => (h, s, 1 - l).

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

#css #colors #hsl #yandex

https://habr.com/ru/company/yandex/blog/446780/

Google в рамках проекта Fugu, который нацелен на устранением разрыва между нативными и web-приложениями, работает над добавлением имплементации чернового стандарта WebHID API для работы с HID-устройствами в Chromium. Робат Вильямс в статье "Upcoming WebHID API - access Bluetooth/USB HID devices in web applications" рассказывает о пользе этого API.

HID-протокол позволяет организовать работу с целыми классами устройств, избавляя от необходимости писать код для взаимодействия с разными устройствами. Например, код, использующий WebHID API для включения индикатора связи на гарнитуре, будет работать со всеми гарнитурами разных производителей, которые работают с этим протоколом.

В статье также разбирается работа с новым API, которое доступно с помощью navigator.hid. Есть пара примеров использования API. В них ничего необычного нет: подготовка устройства, считывание данных и отправка данных. В общем, web-платформа стремительно развивается. Скоро мы сможем делать с её помощью ещё более продвинутые приложения.

https://blog.scottlogic.com/2019/04/03/upcoming-webhid-api.html

#chromium #webplatform #future

Smashing Magazine опубликовал хорошую статью Павла Померанцева про управление z-index'ами "Managing Z-Index In A Component-Based Web Application".

Павел рассказывает, что такое контекст наложения (stacking context) и почему именно он является основной проблемой некорректного наложения элементов страницы друг на друга. Затем делится своей стратегией использования z-index, которая может помочь при управлении наложением в приложениях с большим количеством компонентов:
1. Все компоненты должны создавать свой собственный контекст наложения. Если внутри компонента нет элементов с z-index, то этот шаг необязателен.
2. Внутри CSS-файлов компонентов поддерживайте z-index'ы так как вам удобно. Предпочтительно использовать z-index только для тех элементов, которые не являются потомками других элементов.
3. Если возникает проблема с неправильным наложением, надо найти первый общий предок-компонент проблемных элементов и внутри этого компонента поменять z-index'ы корректным образом.

Автор также показывает пример, в котором этот подход может перестать работать. Но такие ситуации могут быть только в очень сложных приложениях, и в этом случае проблемный элемент можно выносить в конец body и ставить ему очень большой z-index (но надо учитывать, что это может быть не очень хорошее решение для скринридеров).

#css #layout

https://www.smashingmagazine.com/2019/04/z-index-component-based-web-application/

Вчера Матиас Байненс из команды v8 написал статью про то, как написать полифилл для globalThis, который будет работать во всех окружениях.

Несколько лет назад в TC39 появилось предложение унифицировать название глобального объекта, который бы был доступен в браузере, на сервере (node.js) и других окружениях. Так появился globalThis, который уже поддерживается нативно в Chrome 71, Firefox 65, Safari 12.1 и iOS Safari 12.2.

Написание полифилла для globalThis нетривиальная задача, так как скрипт может быть запущен в браузере, в web-воркере браузера, в расширениях, node.js, должен работать в strict-режиме и в sloppy-режиме и т.п. Матиас в статье поэтапно рассказывает как написать такой полифилл. В итоге приходит к решению, которое модифицирует прототип объекта, для получения доступа к глобальному объекту.

Object.defineProperty(Object.prototype, '__magic__', {
  get: function() {
    return this;
  },
  configurable: true
});
var globalThis = __magic__;
delete Object.prototype.__magic__;

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

#js #polyfill #proposal

https://mathiasbynens.be/notes/globalthis

Прочитал небольшую статью Тори Волкера "The Pitfalls of Async/Await in Array Loops" про использование async/await в циклах.

По ходу статьи Тори рассказывает как добиться того, чтобы три промиса были выполнены по порядку с использованием циклов. В начале он показывает неправильно работающий пример с использованием forEach и объясняет, почему он не работает так как нужно (в комментариях есть больше подробностей). Потом показывает уже работающее решение с использованием map. В этом примере почти всё работает как ожидается, но промисы не ждут друг друга. В последнем примере используется for...of, с которым всё ок – каждый промис ждёт выполнения предыдущего.

Статья небольшая, но вполне адекватная. Если у вас в проекте используется async/await, то статья может быть вам полезна.

#js #async

https://medium.com/dailyjs/the-pitfalls-of-async-await-in-array-loops-cf9cf713bfeb

Сергей Ufocoder опубликовал на ДевШахте очень прикольную статью "Анонимные функции в JavaScript".

Анонимная функция может легко ввести в заблуждение. Это доказывает опрос, который проводил Сергей у себя в твиттере. Анонимная ли эта функция?

const myFunc = function (a) {
return a + 42;
}

Анонимная. Если после function есть идентификатор, то это именованная функция, во всех остальных случаях анонимная. Но при этом у примера выше myFunc.name === 'myFunc'. Почему это именно так, а не иначе, в статье разбирается на уровне спецификации языка. В общем, статья интересная, советую почитать.

#js #specification #function

https://medium.com/devschacht/anonymous-functions-in-javanoscript-ff6b9ba85de0

Майкл Дроэтбум неделю назад в статье "Pyodide: Bringing the scientific Python stack to the browser" рассказал про новую разработку Mozilla. Pyodite — это экспериментальный проект для запуска полноценного python data science стека в браузере. Цель проекта — развитие data science экосистемы JavaScript.

Pyodite использует WebAssembly для запуска python-кода в браузере. Из кода на python доступна вся web-платформа: результат работы python-библиотек можно обрабатывать в JavaScript, отображать в canvas и т.п. В статье есть подробное объяснение того, как разработчики достигли интероперабельности между Python и JavaScript, какие были альтернативы и почему они не подошли. Так как проект экспериментальный, ещё остаётся простор для развития, например, многопоточность, которой в Pyodite пока нет.

Сейчас в Pyodite доступны библиотеки NumPy, Scipy, Matoplib, Pandas, но в будущем разработчики планируют интегрировать PyPI (основной репозиторий python-библиотек и программ), таким образом будут доступны ещё более 50000 пакетов.

#webassembly #datascience #python

https://hacks.mozilla.org/2019/04/pyodide-bringing-the-scientific-python-stack-to-the-browser/